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 <rep...@bugs.python.org> <http://bugs.python.org/issue17016> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com