JohnLeitch added the comment:
Attaching repro.
--
Added file: http://bugs.python.org/file39889/SRE_SEARCH_Integer_Underflow.py
___
Python tracker
<http://bugs.python.org/issue24
JohnLeitch added the comment:
Attaching proposed patch for unit tests to cover this issue.
--
Added file: http://bugs.python.org/file39888/test_re.py.patch
___
Python tracker
<http://bugs.python.org/issue24
New submission from JohnLeitch:
The Python 2.7 regular expression module suffers from an integer underflow in
the SRE_SEARCH function of _sre.c, which leads to a buffer over-read condition.
The issue is caused by unchecked subtraction performed while handling
SR_OP_INFO blocks:
if
JohnLeitch added the comment:
Attaching repro file.
--
Added file:
http://bugs.python.org/file39886/msilib.OpenDatabase_Type_Confusion.py
___
Python tracker
<http://bugs.python.org/issue24
New submission from JohnLeitch:
The msilib.OpenDatabase method suffers from a type confusion vulnerability
caused by the behavior of MsiOpenDatabase(), the underlying win32 function
utilized. This is due to the unorthodox handling of the szPersist parameter:
when an MSIDBOPEN_* value is
New submission from JohnLeitch:
The hotspot module suffer from a heap buffer overflow due to a memcpy in the
pack_string function at line 633:
static int
pack_string(ProfilerObject *self, const char *s, Py_ssize_t len)
{
if (len + PISIZE + self->index >= BUFFERSIZE) {
JohnLeitch added the comment:
Given my understanding of the issue, the memcmp approach seems like a viable
fix.
--
___
Python tracker
<http://bugs.python.org/issue24
New submission from JohnLeitch:
The bytearray pop and remove methods suffer from buffer over-reads caused by
memmove use under the assumption that PyByteArrayObject ob_size is less than
ob_alloc, leading to a single byte over-read. This condition can be triggered
by creating a bytearray from
New submission from JohnLeitch:
The bytearray.find method suffers from a buffer over-read that can be triggered
by passing a string equal in length to the buffer. The result is a read off the
end of the buffer, which could potentially be exploited to disclose the
contents of adjacent memory
New submission from JohnLeitch:
The audioop.lin2adpcm function suffers from a buffer over-read caused by
unchecked access to stepsizeTable at line 1436 of Modules\audioop.c:
} else if ( !PyArg_ParseTuple(state, "ii", &valpred, &index) )
return 0;
step = s
New submission from JohnLeitch:
The audioop.adpcm2lin function suffers from a buffer over-read caused by
unchecked access to stepsizeTable at line 1545 of Modules\audioop.c:
} else if ( !PyArg_ParseTuple(state, "ii", &valpred, &index) )
return 0;
step = s
New submission from JohnLeitch:
Several functions within the imageop module are vulnerable to exploitable
buffer overflows due to unsafe arithmetic in check_multiply_size(). The problem
exists because the check to confirm that size == product / y / x does not take
remainders into account
JohnLeitch added the comment:
Thank you again for the explanation of the internals at play here. Armed with
the knowledge you provided, I conducted further experimentation, and I believe
I can now demonstrate how EIP control is possible with this bug. Note that RPC
initialization is not
JohnLeitch added the comment:
Thank you for taking the time to peruse my report and explain the behavior I
observed. My understanding of Windows RPC internals is lacking, and perhaps I
jumped the gun upon catching an AV while fuzzing.
That said, after poking around to better understand the
New submission from JohnLeitch:
The Python _winreg module suffers from a type confusion vulnerability wherein
pointers can be passed directly in place of PyHKEY instances e.g.
_winreg.QueryValue(0x41414141, "")
This behavior is due to the underlying PyHKEY_AsHKEY function of _winre
15 matches
Mail list logo