New submission from Nickolai Zeldovich:
Modules/_sre.c relies on pointer overflow in 5 places to check that the
supplied offset does not cause wraparound when added to a base pointer; e.g.:
SRE_CODE prefix_len;
GET_ARG; prefix_len = arg;
GET_ARG;
/* Here comes the prefix string */
if (code+prefix_len < code || code+prefix_len > newcode)
FAIL;
however, pointer wraparound is undefined behavior in C, and gcc will optimize
away (code+prefix_len < code) to (true), since prefix_len is an unsigned value.
This will happen with -O2 and even with -fwrapv:
nickolai@sahara:/tmp$ cat x.c
void bar();
void
foo(int *p, unsigned int x)
{
if (p + x < p)
bar();
}
nickolai@sahara:/tmp$ gcc x.c -S -o - -O2 -fwrapv
...
foo:
.LFB0:
.cfi_startproc
rep
ret
.cfi_endproc
...
nickolai@sahara:/tmp$
On a 32-bit platform with the development version of cpython, prefix_len seems
to end up being an 'unsigned int', so I suspect that supplying a large
prefix_len value (perhaps 0xffffffff) could lead to the subsequent loop writing
garbage all over memory, or worse (but I have not tried to construct a concrete
input that triggers this bug, so maybe there are some checks that make it
difficult to trigger the bug).
In any case, this might be worth fixing -- the attached patch provides one
proposed fix. Another option might be to add -fno-strict-overflow to the gcc
flags, which may be a reasonable additional measure to take, to avoid such
problems biting Python in the future, but I would suggest doing this in
addition to fixing the code (since not all compilers support such a flag to
disable certain optimizations).
----------
components: None
files: pp.patch
keywords: patch
messages: 180403
nosy: Nickolai.Zeldovich
priority: normal
severity: normal
status: open
title: _sre: avoid relying on pointer overflow
type: security
versions: Python 3.5
Added file: http://bugs.python.org/file28804/pp.patch
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue17016>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
