Changes by John Leitch :
Added file: http://bugs.python.org/file44900/Py35_itertools.py
___
Python tracker
<http://bugs.python.org/issue28322>
___
___
Python-bugs-list m
New submission from John Leitch:
Python 3.5.2 suffers from a type confusion vulnerability in the
chain.__setstate__ method of the itertools module. The issue exists due to lack
of argument validation in the chain_setstate() function:
static PyObject *
chain_setstate(chainobject *lz, PyObject
John Leitch added the comment:
Of course. Attached is a new patch that includes test coverage. It crashes on
failure as there isn't any reasonable way to monitor for this kind of undefined
behavior, but it's better than nothing.
--
Added file: http://bugs.python.org
Changes by John Leitch :
Added file: http://bugs.python.org/file44828/Py35_LZMADecompressor.py
___
Python tracker
<http://bugs.python.org/issue28275>
___
___
Python-bug
New submission from John Leitch:
Python 3.5.2 suffers from a use after free vulnerability caused by the behavior
of the LZMADecompressor.decompress method. The problem exists due to a dangling
pointer created by an incomplete error path in the _lzma!decompress function.
static PyObject
Changes by John Leitch :
--
nosy: +brycedarling
___
Python tracker
<http://bugs.python.org/issue25092>
___
___
Python-bugs-list mailing list
Unsubscribe:
John Leitch added the comment:
All appears well.
--
___
Python tracker
<http://bugs.python.org/issue25021>
___
___
Python-bugs-list mailing list
Unsubscribe:
John Leitch added the comment:
Glancing over the code, I see the issues you describe. Tonight I will verify
your revised patch and report back.
--
___
Python tracker
<http://bugs.python.org/issue25
Changes by John Leitch :
Added file: http://bugs.python.org/file40401/product_setstate_Type_Confusion.py
___
Python tracker
<http://bugs.python.org/issue25021>
___
___
New submission from John Leitch:
Python 3.3, 3.4, and 3.5 suffer from a vulnerability caused by the behavior of
the product_setstate() function. When called, the function loops over the state
tuple provided and clamps each given index to a value within a range from 0 up
to the max number of
Changes by John Leitch :
--
nosy: +christian.heimes
___
Python tracker
<http://bugs.python.org/issue25019>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by John Leitch :
--
nosy: +brycedarling
___
Python tracker
<http://bugs.python.org/issue25019>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by John Leitch :
--
keywords: +patch
Added file:
http://bugs.python.org/file40395/xmlparse_setattro_Type_Confusion.patch
___
Python tracker
<http://bugs.python.org/issue25
New submission from John Leitch:
Python 3.4 and 3.5 suffer from a vulnerability caused by the behavior of the
xmlparse_setattro() function. When called, the function uses the provided name
argument in several conditional statements which assume that the name argument
is a string.
However, if
John Leitch added the comment:
First, let me begin by saying I believe this patch will fix the buffer
over-read, which is a good step forward.
However, after giving the matter more thought, and at the risk of wearing out
my welcome, I am of the belief that relying on the CRT to handle
John Leitch added the comment:
Yes, this is a user-mode read, but I disagree with the assertion that it's not
possible to use this to disclose memory. While it isn't as critical as
something that outright dumps memory, there is logic that throws exceptions
based on values encount
John Leitch added the comment:
If it's so wildly inconsistent, it's my opinion that Python should perform its
own validation to achieve better cross-platform support. The alternative is
playing a never ending game of whack-a-mole, or just accepting that format
strings may cause exc
John Leitch added the comment:
Yikes--your comment prompted me to look at the check-in, and it seems my patch
wasn't properly applied. The curly braces got tweaked, which is minor as you
stated, but more importantly the AIX code should not decref format. That could
introduce problems b
John Leitch added the comment:
Is there a way to see what style guidelines have been violated? The only thing
I can think of is the curly braces in the Windows check, but I was following
the conventions of the surrounding code.
--
___
Python
John Leitch added the comment:
I plucked the error message from the % operator:
>>> '%' % 'foo'
Traceback (most recent call last):
File "", line 1, in
ValueError: incomplete format
>>> '%z' % 'foo'
Traceback (most rece
John Leitch added the comment:
Attached is a revised patch.
--
Added file:
http://bugs.python.org/file40367/time_strftime_Buffer_Over-read_v2.patch
___
Python tracker
<http://bugs.python.org/issue24
John Leitch added the comment:
When I get a bit of slackspace (probably tomorrow afternoon/evening) I can test
on the spectrum of versions to confirm the issue is in >= 3.2. I'll also look
into improving our automation so all future reports can have the appropriate
versions
John Leitch added the comment:
It very well may apply to versions apart from 3.5. Our test environment is
quite complex and unfriendly to working with multiple versions of Python. Plus,
we're strapped for time, so we tend to file under the version we're currently
targeting and defe
John Leitch added the comment:
> I have tried the reproducer on Windows 10 with 2.6, 2.7, 3.3, 3.4, 3.5 and
> 3.6. In every case I got this.
What you are observing is due to the arrangement and contents of process
memory. With a simple repro (such as the one provided), there's a
John Leitch added the comment:
Currently, no. Would you like us to report this and future vulnerabilities to
CERT?
--
___
Python tracker
<http://bugs.python.org/issue24
Changes by John Leitch :
--
nosy: +belopolsky, lemburg
___
Python tracker
<http://bugs.python.org/issue24917>
___
___
Python-bugs-list mailing list
Unsubscribe:
John Leitch added the comment:
We based our fix on the check in write_bytes:
if (endpos > (size_t)PyBytes_GET_SIZE(self->buf)) {
if (resize_buffer(self, endpos) < 0)
return -1;
}
I see now that our casting was extraneous. As for the macro, it was suspec
Changes by John Leitch :
Added file: http://bugs.python.org/file40327/scan_eol_Buffer_Over-read.py
___
Python tracker
<http://bugs.python.org/issue24989>
___
___
Pytho
New submission from John Leitch:
Python 3.5 suffers from a vulnerability caused by the behavior of the
scan_eol() function. When called, the function gets a line from the buffer of a
BytesIO object by searching for a newline character starting at the position in
the buffer.
However, if the
John Leitch added the comment:
The "exception analysis" is output from the WinDbg !analyze command run on a
crash where access to the uninitialized memory ultimately corrupted the
instruction pointer, leading to a data execution prevention crash. That's why
the disassembly is
Changes by John Leitch :
Added file: http://bugs.python.org/file40229/time_strftime_Buffer_Over-read.py
___
Python tracker
<http://bugs.python.org/issue24917>
___
___
New submission from John Leitch:
Python 3.5 suffers from a vulnerability caused by the behavior of the
time_strftime() function. When called, the function loops over the format
string provided, using strchr to search for each instance of '%'. After finding
a '%', it con
Changes by John Leitch :
Added file: http://bugs.python.org/file40225/newblock_Uninitialized_variable.py
___
Python tracker
<http://bugs.python.org/issue24913>
___
___
New submission from John Leitch:
Python 3.5 suffers from a vulnerability caused by the behavior of the
newblock() function used by the collections.deque module. When called,
newblock() allocates memory using PyMem_Malloc() and does not initialize it:
static block *
newblock(Py_ssize_t len
John Leitch added the comment:
Attaching repro.
--
Added file: http://bugs.python.org/file40135/PyNumber_Long_Buffer_Over-read.py
___
Python tracker
<http://bugs.python.org/issue24
New submission from John Leitch:
Python suffers from a buffer over-read in PyNumber_Long() that is caused by the
incorrect assumption that buffers returned by PyObject_GetBuffer() are
null-terminated. This could potentially result in the disclosure of adjacent
memory.
PyObject
John Leitch added the comment:
Attaching repro
--
Added file:
http://bugs.python.org/file40133/PyFloat_FromString_Buffer_Over-read.py
___
Python tracker
<http://bugs.python.org/issue24
New submission from John Leitch:
Python suffers from a buffer over-read in PyFloat_FromString() that is caused
by the incorrect assumption that buffers returned by PyObject_GetBuffer() are
null-terminated. This could potentially result in the disclosure of adjacent
memory.
PyObject
John Leitch added the comment:
Attached is a patch that updates array.fromstring to throw a ValueError when
self is passed. It also updates the unit tests to cover this new behavior.
--
Added file:
http://bugs.python.org/file40023/array.fromstring-Use-After-Free.patch
John Leitch added the comment:
Oops. Here's a corrected patch.
--
Added file:
http://bugs.python.org/file40009/strop.replace_Integer_Overflow.patch
___
Python tracker
<http://bugs.python.org/is
Changes by John Leitch :
Removed file:
http://bugs.python.org/file40006/strop.replace_Integer_Overflow.patch
___
Python tracker
<http://bugs.python.org/issue24
John Leitch added the comment:
To clarify one point, passing self to array.fromstring works as expected almost
all the time in 2.7. My testing revealed anomalous behavior <1% of the time,
and it was almost always non-fatal corruption of the buffer. It stands to
reason that legacy code
John Leitch added the comment:
I understand the desire for consistency and I will create such a patch when I
get some slack space (hopefully tonight), but I believe it will constitute a
breaking change; in 2.7, passing self to array.fromstring works as expected
most of the time
New submission from John Leitch:
The Python strop.replace() method suffers from an integer overflow that can be
exploited to write outside the bounds of the string buffer and potentially
achieve code execution. The issue can be triggered by performing a large
substitution that overflows the
John Leitch added the comment:
Attaching repro.
--
Added file: http://bugs.python.org/file40007/strop.replace_Integer_Overflow.py
___
Python tracker
<http://bugs.python.org/issue24
John Leitch added the comment:
Attaching patch.
--
keywords: +patch
Added file: http://bugs.python.org/file39900/arraymodule.c.patch
___
Python tracker
<http://bugs.python.org/issue24
New submission from John Leitch:
The Python array.fromstring() method suffers from a use after free caused by
unsafe realloc use. The issue is triggered when an array is concatenated to
itself via fromstring() call:
static PyObject *
array_fromstring(arrayobject *self, PyObject *args
47 matches
Mail list logo
