Justin Ferguson [EMAIL PROTECTED] added the comment:
i pulled the Macros out of pymem.h in a Vanille 2.5.2?
--
components: +None
versions: +Python 3.0
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2620
Justin Ferguson [EMAIL PROTECTED] added the comment:
sorry didnt mean to change components and version-- I'm typing this from
my phone and its being uncooperative at the moment
--
components: +Library (Lib)
__
Tracker [EMAIL PROTECTED]
http
Justin Ferguson [EMAIL PROTECTED] added the comment:
just fixing the modifications my phone made earlier tonight
--
components: -Library (Lib), None
versions: -Python 3.0
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2620
Justin Ferguson [EMAIL PROTECTED] added the comment:
Additionally-- the PyMem_NEW()/PyMem_New() macro's need to be fixed:
231 static
232 PyUnicodeObject *_PyUnicode_New(Py_ssize_t length)
233 {
234 register PyUnicodeObject *unicode;
235
236 /* Optimization for empty strings
New submission from Justin Ferguson [EMAIL PROTECTED]:
174 static
175 int unicode_resize(register PyUnicodeObject *unicode,
176 Py_ssize_t length)
177 {
[...]
201
202 oldstr = unicode-str;
203 PyMem_RESIZE(unicode-str, Py_UNICODE, length + 1);
[...]
209
Changes by Justin Ferguson [EMAIL PROTECTED]:
Added file: http://bugs.python.org/file10012/python-2.5.2-unicode_resize-utf8.py
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2620
Changes by Justin Ferguson [EMAIL PROTECTED]:
Added file:
http://bugs.python.org/file10013/python-2.5.2-unicode_resize-utf16.py
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2620
Justin Ferguson [EMAIL PROTECTED] added the comment:
What I was originally thinking was if offset was larger than buf_len,
that would cause the check at 1561 to fail due to the subtraction. That
said, I'm not sure what type its being compared against so I need to
check this further, let me get
Justin Ferguson [EMAIL PROTECTED] added the comment:
Yes, excuse me-- this should be 32-bit specific as I believe Python will
not let me get a string long enough to overflow the integer on 64-bit.
It's a big string, the only realistic scenario I can see is XML parsing
or similar.
theory
Justin Ferguson [EMAIL PROTECTED] added the comment:
The use of signed integers in Python is (imho) the single largest threat
to the security of the interpreter. I'm probably preaching to the choir
there though.
I really dislike have to return values and indicate error in the return
value, its
Justin Ferguson [EMAIL PROTECTED] added the comment:
While I think its a mistake that will cause security concerns in Python
for quite some time to come, thats fair enough.
I will refile all the places that this messes up individually
__
Tracker [EMAIL PROTECTED
Justin Ferguson [EMAIL PROTECTED] added the comment:
Actually, I'm not sure things are any better today- even the same
operating system but different versions have inconsistencies, for
instance on some versions of RHEL the vsnprintf() can fail during
unicode conversion. MSVCRT still returns -1
Justin Ferguson [EMAIL PROTECTED] added the comment:
Do I need to create proof of concepts for each of these bugs, or can I
reference this ticket?
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2587
Justin Ferguson [EMAIL PROTECTED] added the comment:
Yep, that works for me.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2588
__
___
Python-bugs-list mailing list
Justin Ferguson [EMAIL PROTECTED] added the comment:
Okay, so I'm not sure whose point of view takes precedence here?
Also, to answer the question asked, I'm doing this manually.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2587
Justin Ferguson [EMAIL PROTECTED] added the comment:
1. If you change PyString_FromStringAndSize, you should change
PyBytes_FromStringAndSize and PyUnicode_FromStringAndSize for
consistency.
Okay, if we don't patch the API call itself, I will look at the users of
those two API calls as well
New submission from Justin Ferguson [EMAIL PROTECTED]:
The zlib module in multiple places fails to adequately check the sanity
of its arguments resulting in memory corruption, please see two attached
PoCs.
--
components: Extension Modules
files: python-2.5.2-zlib-unflush
Changes by Justin Ferguson [EMAIL PROTECTED]:
Added file:
http://bugs.python.org/file9984/python-2.5.2-zlib-unflush-signedness.py
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2586
New submission from Justin Ferguson [EMAIL PROTECTED]:
The PyString_FromStringAndSize() function takes a pointer and signed
integer as input parameters however it fails to adequately check the
sanity of the integer argument. Because of the failure to check for
negative values and because it sums
New submission from Justin Ferguson [EMAIL PROTECTED]:
The PyOS_vsnprintf() contains the caveat that the length parameter
cannot be zero, however this is only enforced via assert() which is
compiled out. As a result if the length parameter is zero then the
function will underflow and write
Changes by Justin Ferguson [EMAIL PROTECTED]:
--
components: +Interpreter Core -Distutils
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2588
__
___
Python-bugs-list
New submission from Justin Ferguson [EMAIL PROTECTED]:
On architectures that do not have a vsnprintf() in their standard
library Python attempts to emulate it. When doing so, the implementation
ambitiously allocates more memory than requested without verifying the
sanity of the summed value
New submission from Justin Ferguson [EMAIL PROTECTED]:
The S_unpack_from() function in Modules/_struct.c does not adequately
validate its arguments, potentially causing an out-of-bounds read
access. It should be noted that the check at line 1561 is inadequate for
obscene values of offset
New submission from Justin Ferguson [EMAIL PROTECTED]:
I don't think any of these SGI modules even get used, but they're really
buggy-- you guys might want to consider just dropping them all together.
When printing errors larger than 128 bytes a stack based overflow occurs.
44 static void
New submission from Justin Ferguson [EMAIL PROTECTED]:
Please see bug 2591 for a suggestion on what to do with these SGI modules.
(sorry I don't have any pocs/repros I dont have an sgi box handy atm)
Integer overflow/invalid allocation at 768, write to memory at 773
716 static PyObject *
717
Justin Ferguson [EMAIL PROTECTED] added the comment:
The problem with assert()'s is they require debugging to be enabled,
obviously, who compiles it that way?
You may not even want to worry about the second check, when you pass it
into the allocator it gets converted to an unsigned int which
Justin Ferguson [EMAIL PROTECTED] added the comment:
I can generally agree with that, and I admit I haven't verified all of
the code paths here- theres several hundred of them leading into this
function, are you positive all of them are safe? (seems like it would be
easier to just move the check
Justin Ferguson [EMAIL PROTECTED] added the comment:
Adding a poc from 2586 to demonstrate my point, this causes a call to
the allocator requesting zero bytes.
Added file:
http://bugs.python.org/file9985/python-2.5.2-zlib-unflush-misallocation.py
__
Tracker
New submission from Justin Ferguson [EMAIL PROTECTED]:
You guys should probably just remove the SGI modules, the code looks
like it hasn't been touched in some time and hasn't gone through the
same security checks as other pieces of code. Sorry I have no
repro's/pocs, I don't have an irix box
Justin Ferguson [EMAIL PROTECTED] added the comment:
Just so you know, the scripts actually do two different things-- the
bugs are both related to negative values though. One causes
PyString_FromStringAndSize() to try an allocate zero bytes (the -24
one), the other causes like 22 bytes to get
New submission from Justin Ferguson [EMAIL PROTECTED]:
The imgfile module contains multiple integer overflows, this module is
only used on SGI boxes and is likely mostly unused and thus is fairly
low priority imho-- no repros, no poc, no sgi box :/
I'm only going to post one to give you
Justin Ferguson [EMAIL PROTECTED] added the comment:
I'm not going to file a different bug for rgbimgmodule.c, it has the
same types of issues.
Sorry, I don't mean to drop a ton of bugs, I'm prepping up to do a talk
on attacking the metadata in scripting languages (i.e. the python call
stack
Justin Ferguson [EMAIL PROTECTED] added the comment:
As an addemdum, consider the following code (theres no assert, but it
wouldnt have helped you outside of debug builds anyways):
488 static PyObject *PySSL_SSLread(PySSLObject *self, PyObject *args)
489 {
490 PyObject *buf;
491
Justin Ferguson [EMAIL PROTECTED] added the comment:
I do agree with your point about snprintf(..., sizeof(x), ...)-- my
single biggest point (and maybe i'm just not seeing it), is that there
appears to be no good reason for having this caveat and in turn its
essentially just code waiting
34 matches
Mail list logo
