[issue24022] Python heap corruption issue

[Roundup Robot]

Roundup Robot added the comment:

New changeset ccfea26e6582 by Benjamin Peterson in branch '3.4':
properly handle the single null-byte file (closes #24022)
https://hg.python.org/cpython/rev/ccfea26e6582

New changeset c6438a3df7a4 by Benjamin Peterson in branch '2.7':
properly handle the single null-byte file (closes #24022)
https://hg.python.org/cpython/rev/c6438a3df7a4

New changeset d2f86d9c53b9 by Benjamin Peterson in branch '3.6':
merge 3.5 (#24022)
https://hg.python.org/cpython/rev/d2f86d9c53b9

--
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24022] Python heap corruption issue

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Where are test scripts?

--
nosy: +serhiy.storchaka
versions:  -Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24022] Python heap corruption issue

[Benjamin Peterson]

Changes by Benjamin Peterson :


Added file: http://bugs.python.org/file39160/f69354561u44075.zip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24022] Python heap corruption issue

[Roundup Robot]

Roundup Robot added the comment:

New changeset 414e08c478f4 by Benjamin Peterson in branch '3.4':
do not call into python api if an exception is set (#24022)
https://hg.python.org/cpython/rev/414e08c478f4

New changeset 03b2259c6cd3 by Benjamin Peterson in branch 'default':
merge 3.4 (#24022)
https://hg.python.org/cpython/rev/03b2259c6cd3

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24022] Python heap corruption issue

[Benjamin Peterson]

New submission from Benjamin Peterson:

Reported by "Hug Bounter" to security@

Hello,

I would like to report a heap corruption issue in 
Python/Parser/tokenizer.c:922, affecting latest Python 3.4.3 (from python.org) 
and also 2.7 ( tested 2.7.9-r1 on Gentoo ). The latest version available - 
3.5.0a3 is also affected. It doesn't seem to affect 3.3 branch (tested with 
3.3.5-r1 on Gentoo).
The issue occurs when a malformed python script is executed by python binary, 
which results in a out-of-bound read access of heap and therefore a 
segmentation fault.
I couldn't confirm nor deny its exploitability, to my knowledge this would be 
more of a infoleak, if anything. Nevertheless, as Google Project Zero proved 
many times, no heap corruption issue should be treated lightheartedly. :-) 
Hence the reason why I'm reporting it to secur...@python.org

I tried to dig into the details of the bug and I have to admit the defeat - the 
Python Parser is quite a complex beast...
What I was able to determine was that given malformed script (attached), the 
infinite 'for' loop defined in tokenizer.c:900 never reaches any of the exit 
conditions, which causes a infinite incrementation of *tok->cur and thus 
reading character by character of the heap, until the heap segment boundary is 
reached and segmentation fault occurrs.

There seem to be a race condition involved as well, as the malformed script 
does not always result in crash sometimes producing the error below:

./python ~/Fuzz/crashes/python_stuff/heap_pattern.py
  File "/home/user/Fuzz/crashes/python_stuff/heap_pattern.py", line 44
SyntaxError: Non-UTF-8 code starting with '\x9e' in file 
/home/user/Fuzz/crashes/python_stuff/heap_pattern.py on line 45, but no 
encoding declared; see http://python.org/dev/peps/pep-0263/ for details

I acknowledge that attack scenario is somehow limited, because one has to be in 
a position to provide their own script for execution. Nevertheless, at the very 
least, a malicious user could crash python environment.


Depending on the particular script, ASAN detects either as a 
'heap-use-after-free' or 'heap-buffer-overflow'.

HEAP-BUFFER-OVERFLOW according to asan:

$ ./python ~/heap3.py
=
==23461==ERROR: AddressSanitizer: heap-buffer-overflow on address 
0x6251e0ff at pc 0xc90075 bp 0x7ffe53018fd0 sp 0x7ffe53018fc0
READ of size 1 at 0x6251e0ff thread T0
#0 0xc90074 in tok_nextc Parser/tokenizer.c:1021
#1 0xc9a6ef in tok_get Parser/tokenizer.c:1341
#2 0xca0640 in PyTokenizer_Get Parser/tokenizer.c:1738
#3 0xc81109 in parsetok Parser/parsetok.c:208
#4 0xa0c449 in PyParser_ASTFromFileObject Python/pythonrun.c:2356
#5 0xa0c449 in PyRun_FileExFlags Python/pythonrun.c:2126
#6 0xa15f0b in PyRun_SimpleFileExFlags Python/pythonrun.c:1606
#7 0x43a1aa in run_file Modules/main.c:319
#8 0x43a1aa in Py_Main Modules/main.c:751
#9 0x4234d3 in main Modules/python.c:69
#10 0x7efcd1cf1f9f in __libc_start_main (/lib64/libc.so.6+0x1ff9f)
#11 0x426a7c (/home/user/Fuzz/targets/Python-3.4.3_ASAN/python+0x426a7c)

0x6251e0ff is located 1 bytes to the left of 8192-byte region 
[0x6251e100,0x62520100)
allocated by thread T0 here:
#0 0x7efcd29eb7c7 in malloc 
(/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/libasan.so.1+0x577c7)
#1 0xc9997a in PyTokenizer_FromFile Parser/tokenizer.c:852

SUMMARY: AddressSanitizer: heap-buffer-overflow Parser/tokenizer.c:1021 
tok_nextc
Shadow bytes around the buggy address:
  0x0c4a7fffbbc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a7fffbbd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a7fffbbe0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a7fffbbf0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a7fffbc00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c4a7fffbc10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa[fa]
  0x0c4a7fffbc20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c4a7fffbc30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c4a7fffbc40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c4a7fffbc50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c4a7fffbc60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:   fa
  Heap right redzone:  fb
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack partial redzone:   f4
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Contiguous container OOB:fc
  ASan internal:   fe
==23461==ABORTING


Below is an example of ASAN detecting a 'use-after-free':

./python ~/heap4_asan.py