New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Heap overwrite in Python/fileutils.c:_Py_char2wchar() on 32 bit systems due to malloc parameter overflow #67354
Comments
The vulnerability described here is exceedingly difficult to exploit, since there is no straight-forward way an "attacker" (someone who controls a Python script contents but not other values such as system environment variables), can control a relevant parameter to the vulnerable function (_Py_char2wchar in Python/fileutils.c). It is, however, important that it is remediated since unawareness of this vulnerability may cause an unsuspecting author to establish a link between user and the function parameter in future versions of Python. Like I said, the vulnerability is caused by code in the _Py_char2wchar function. Indirectly this function is accessed through Objects/unicodeobject.c:PyUnicode_DecodeLocaleAndSize(), PyUnicode_DecodeFSDefaultAndSize(), PyUnicode_DecodeLocale, and some other functions. As far as I know this can only be exploited on 32-bit architectures (whose overflow threshold of its registers is 2**32). The following description sets out from the latest Python 3.4 code retrieved from https://hg.python.org/cpython . The problem lies in the computation of size of the buffer that will hold the wide char version of the input string: --
|
New changeset 1ce98e85929d by Benjamin Peterson in branch '3.2': New changeset d1af6f3a8ce3 by Benjamin Peterson in branch '3.3': New changeset d45e16b1ed86 by Benjamin Peterson in branch '3.4': New changeset 8c4fb312e15d by Benjamin Peterson in branch 'default': |
+ size_t argsize = strlen(arg) + 1; The code doesn't check for integer overflow on "+1". I suggest instead: + size_t arglen = strlen(arg); |
Presumably strlen can't return SIZE_T_MAX because the trailing '\0' has to have been allocated somewhere. |
PY_SSIZE_T_MAX is usually smaller than SIZE_T_MAX ;-) (strlen result is not signed.) |
Right, but there's still no danger of overflow. On Sun, Jan 4, 2015, at 16:50, STINNER Victor wrote:
|
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: