[issue17016] _sre: avoid relying on pointer overflow
Nickolai Zeldovich added the comment: I just submitted the contributor form -- thanks for the reminder. -- ___ 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
[issue17016] _sre: avoid relying on pointer overflow
Nickolai Zeldovich added the comment: I get an HTTP error when trying to upload another patch through Rietveld, so here's a revised patch that avoids the need for Py_uintptr_t (thanks Serhiy). -- Added file: http://bugs.python.org/file29379/pp-3.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
[issue17016] _sre: avoid relying on pointer overflow
Nickolai Zeldovich added the comment: Sorry for the delay. Attached is an updated patch that should fix all of the issues mentioned in this bug report. -- Added file: http://bugs.python.org/file29368/pp-2.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
[issue17016] _sre: avoid relying on pointer overflow
Nickolai Zeldovich added the comment:
Lines 2777 and 3111 do indeed look suspect, because gcc can compile (ptr +
offset ptr) into (offset 0):
nickolai@sahara:/tmp$ cat x.c
void bar();
void
foo(char* ptr, int offset)
{
if (ptr + offset ptr)
bar();
}
nickolai@sahara:/tmp$ gcc x.c -S -o - -O2
...
foo:
.LFB0:
.cfi_startproc
testl %esi, %esi
js .L4
rep
ret
.p2align 4,,10
.p2align 3
.L4:
xorl%eax, %eax
jmp bar
.cfi_endproc
...
nickolai@sahara:/tmp$
Lines 658, 678, 1000, 1084 are potentially problematic -- I don't know of
current compilers that will do something unexpected, but it might be worth
rewriting the code to avoid undefined behavior anyway.
--
___
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
[issue17016] _sre: avoid relying on pointer overflow
Nickolai Zeldovich added the comment: For an unsigned int offset, see my original bug report: gcc eliminates the check altogether, since offset = 0 by definition. -- ___ 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
[issue17016] _sre: avoid relying on pointer overflow
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 0x) 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
