[issue2620] Multiple buffer overflows in unicode processing
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 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2620] Multiple buffer overflows in unicode processing
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://bugs.python.org/issue2620 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2620] Multiple buffer overflows in unicode processing
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 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2620] Multiple buffer overflows in unicode processing
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 */
237 if (length == 0 unicode_empty != NULL) {
238 Py_INCREF(unicode_empty);
239 return unicode_empty;
240 }
241
242 /* Unicode freelist memory allocation */
243 if (unicode_freelist) {
244 unicode = unicode_freelist;
245 unicode_freelist = *(PyUnicodeObject **)unicode;
246 unicode_freelist_size--;
247 if (unicode-str) {
248 /* Keep-Alive optimization: we only upsize the buffer,
249never downsize it. */
250 if ((unicode-length length)
251 unicode_resize(unicode, length) 0) {
252 PyMem_DEL(unicode-str);
253 goto onError;
254 }
255 }
256 else {
257 unicode-str = PyMem_NEW(Py_UNICODE, length + 1);
258 }
85 #define PyMem_New(type, n) \
86 ( assert((n) = PY_SIZE_MAX / sizeof(type)) , \
87 ( (type *) PyMem_Malloc((n) * sizeof(type)) ) )
88 #define PyMem_NEW(type, n) \
89 ( assert((n) = PY_SIZE_MAX / sizeof(type)) , \
90 ( (type *) PyMem_MALLOC((n) * sizeof(type)) ) )
91
92 #define PyMem_Resize(p, type, n) \
93 ( assert((n) = PY_SIZE_MAX / sizeof(type)) , \
94 ( (p) = (type *) PyMem_Realloc((p), (n) * sizeof(type)) ) )
95 #define PyMem_RESIZE(p, type, n) \
96 ( assert((n) = PY_SIZE_MAX / sizeof(type)) , \
97 ( (p) = (type *) PyMem_REALLOC((p), (n) * sizeof(type)) ) )
It looks like much of this is reachable from modules, unicode objects,
dict objects, set objects, et cetera. Also, if a 2G string across the
network seems unrealistic consider what 2 billion A's compresses down
to.(Macros again taken from 2.5.2 vanilla)
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2620
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2620] Multiple buffer overflows in unicode processing
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 unicode-str[length] = 0;
210 unicode-length = length;
211
95 #define PyMem_RESIZE(p, type, n) \
96 ( assert((n) = PY_SIZE_MAX / sizeof(type)) , \
97 ( (p) = (type *) PyMem_REALLOC((p), (n) * sizeof(type)) ) )
The unicode_resize() function acts essentially as a wrapper to
realloc(), it accomplishes this via the PyMem_RESIZE() macro which
factors the size with the size of the type, in this case it multiplies
by two as Py_UNICODE is typedef'd to a wchar_t. When resizing large
strings, this results in an incorrect allocation that in turn leads to
buffer overflow.
This is specific to the Unicode objects, however I would not be
surprised to see that other types have this complication as well. Please
see attached proof of concepts.
--
components: Interpreter Core
files: python-2.5.2-unicode_resize-utf7.py
messages: 65379
nosy: jnferguson
severity: normal
status: open
title: Multiple buffer overflows in unicode processing
type: security
versions: Python 2.5
Added file: http://bugs.python.org/file10011/python-2.5.2-unicode_resize-utf7.py
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2620
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2620] Multiple buffer overflows in unicode processing
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 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2620] Multiple buffer overflows in unicode processing
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 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2590] S_unpack_from() Read Access Violation
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 back to you, I may have made a mistake and this may be !bug. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2590 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2620] Multiple buffer overflows in unicode processing
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$ ./python -V Python 2.5.2 theory$ cat /proc/cpuinfo | grep -i model model : 4 model name : Intel(R) Pentium(R) 4 CPU 3.00GHz theory$ ./python python-2.5.2-unicode_resize-utf7.py Segmentation fault __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2620 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2587] PyString_FromStringAndSize() to be considered unsafe
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 really unclean and causes weirdness, for instance if you
follow PyArg_ParseTuple() down and you have an integer (or maybe it was
long?) argument, you can't actually get a value of -1 because one of the
string-int conversion routines uses that to indicate failure. The check
wrapped around it was something along the lines of:
if (-1 == retval PyErr_Occurred())
In turn down the line somewhere (I didn't follow the code path), this
value got converted to 1, so for instance doing
__import__('zlib').decompressobj().flush(-1) wouldn't trigger that bug,
it would flush 1 byte, not UINT_MAX as I had expected
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2587
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2587] PyString_FromStringAndSize() to be considered unsafe
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] http://bugs.python.org/issue2587 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2588] PyOS_vsnprintf() underflow leads to memory corruption
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 on truncation, et cetera. That said, theres plenty of other implementations that manage this without the potential of underflowing a buffer __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2588 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2587] PyString_FromStringAndSize() to be considered unsafe
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 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2588] PyOS_vsnprintf() underflow leads to memory corruption
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 Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2587] PyString_FromStringAndSize() to be considered unsafe
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 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2587] PyString_FromStringAndSize() to be considered unsafe
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, I haven't gone through much of the stuff in Objects/ yet, I focused on the modules obviously and thus didn't know about those calls. 4. You have clearly identified several bugs that are not covered by unittests. If you fix them en-mass by making PyString_FromStringAndSize more forgiving, we will miss an opportunity to improve the test coverage. (If you take the SystemError approach, this does not apply.) This is a valid and good point-- I don't mind either way __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2587 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2586] Integer signedness bugs in zlib modules
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-misallocation.py messages: 65171 nosy: jnferguson severity: normal status: open title: Integer signedness bugs in zlib modules type: security versions: Python 2.5 Added file: http://bugs.python.org/file9983/python-2.5.2-zlib-unflush-misallocation.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2586 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2586] Integer signedness bugs in zlib modules
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 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2587] PyString_FromStringAndSize() to be considered unsane
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 the integer with the size of the PyStringObject structure it becomes possible for the allocator to take either of the code paths in PyObject_MALLOC()-- both of which will incorrectly allocate memory. This may not seem like a big deal, but I'm posting this instead of filing a bug for every place this screws you guys over. if (0 len || len PYSSIZE_T_MAX/sizeof(PyStringObject)) return NULL; -- components: Interpreter Core messages: 65172 nosy: jnferguson severity: normal status: open title: PyString_FromStringAndSize() to be considered unsane type: security versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2587 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2588] PyOS_vsnprintf() underflow leads to memory corruption
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 a null byte to invalid memory.
53 int
54 PyOS_vsnprintf(char *str, size_t size, const char *format, va_list va)
55 {
56 int len; /* # bytes written, excluding \0 */
57 #ifndef HAVE_SNPRINTF
58 char *buffer;
59 #endif
60 assert(str != NULL);
61 assert(size 0);
62 assert(format != NULL);
[...]
65 len = vsnprintf(str, size, format, va);
[...]
91 str[size-1] = '\0';
92 return len;
93 }
--
components: Distutils
messages: 65174
nosy: jnferguson
severity: normal
status: open
title: PyOS_vsnprintf() underflow leads to memory corruption
type: security
versions: Python 2.5
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2588
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2588] PyOS_vsnprintf() underflow leads to memory corruption
Changes by Justin Ferguson [EMAIL PROTECTED]: -- components: +Interpreter Core -Distutils __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2588 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2589] PyOS_vsnprintf() potential integer overflow leads to memory corruption on esoteric architectures
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. As a result it becomes possible (although
unlikely) for an integer overflow to occur misallocating memory and
causing a buffer overflow.
53 int
54 PyOS_vsnprintf(char *str, size_t size, const char *format, va_list va)
55 {
56 int len; /* # bytes written, excluding \0 */
[...]
60 assert(str != NULL);
61 assert(size 0);
62 assert(format != NULL);
63
[...]
67 /* Emulate it. */
68 buffer = PyMem_MALLOC(size + 512);
69 if (buffer == NULL) {
70 len = -666;
71 goto Done;
72 }
73
74 len = vsprintf(buffer, format, va);
75 if (len 0)
76 /* ignore the error */;
77
78 else if ((size_t)len = size + 512)
79 Py_FatalError(Buffer overflow in
PyOS_snprintf/PyOS_vsnprintf);
80
81 else {
82 const size_t to_copy = (size_t)len size ?
83 (size_t)len : size - 1;
84 assert(to_copy size);
85 memcpy(str, buffer, to_copy);
86 str[to_copy] = '\0';
87 }
88 PyMem_FREE(buffer);
89 Done:
[...]
91 str[size-1] = '\0';
92 return len;
93 }
--
components: Interpreter Core
messages: 65175
nosy: jnferguson
severity: normal
status: open
title: PyOS_vsnprintf() potential integer overflow leads to memory corruption
on esoteric architectures
type: security
versions: Python 2.5
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2589
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2590] S_unpack_from() Read Access Violation
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. Finally, because they're not really important
and I really don't want to type them all up-- you guys might want to go
through your code-- especially the modules and look for constructs where
an empty string will cause memory to be uninitialized-- look at the
audioop module for examples of what I mean-- the only thing that
actually saved you guys from overflows there was that the loops you
write with use the same variable.
1533 static PyObject *
1534 s_unpack_from(PyObject *self, PyObject *args, PyObject *kwds)
1535 {
1536 static char *kwlist[] = {buffer, offset, 0};
1537 #if (PY_VERSION_HEX 0x0205)
1538 static char *fmt = z#|i:unpack_from;
1539 #else
1540 static char *fmt = z#|n:unpack_from;
1541 #endif
1542 Py_ssize_t buffer_len = 0, offset = 0;
[...]
1547
1548 if (!PyArg_ParseTupleAndKeywords(args, kwds, fmt, kwlist,
1549 buffer, buffer_len,
offset))
1550 return NULL;
[...]
1558 if (offset 0)
1559 offset += buffer_len;
1560
1561 if (offset 0 || (buffer_len - offset) soself-s_size) {
[...]
1566 }
1567 return s_unpack_internal(soself, buffer + offset);
1568 }
--
components: Extension Modules
messages: 65178
nosy: jnferguson
severity: normal
status: open
title: S_unpack_from() Read Access Violation
type: security
versions: Python 2.5
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2590
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2591] ErrorHandler buffer overflow in ?unused? SGI extension module almodule.c
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
45 ErrorHandler(long code, const char *fmt, ...)
46 {
47 va_list args;
48 char buf[128];
49
50 va_start(args, fmt);
51 vsprintf(buf, fmt, args);
52 va_end(args);
53 PyErr_SetString(ErrorObject, buf);
54 }
--
components: Extension Modules
messages: 65180
nosy: jnferguson
severity: normal
status: open
title: ErrorHandler buffer overflow in ?unused? SGI extension module almodule.c
type: security
versions: Python 2.5
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2591
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2593] alp_ReadFrames() integer overflow leads to buffer overflow
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 alp_ReadFrames(alpobject *self, PyObject *args)
718 {
719 int framecount;
720 PyObject *v;
721 int size;
722 int ch;
723 ALconfig c;
724
725 if (!PyArg_ParseTuple(args, i:ReadFrames, framecount))
726 return NULL;
727 if (framecount 0) {
728 PyErr_SetString(ErrorObject, negative framecount);
729 return NULL;
730 }
[...] 732 switch (alGetSampFmt(c)) {
733 case AL_SAMPFMT_TWOSCOMP:
734 switch (alGetWidth(c)) {
735 case AL_SAMPLE_8:
736 size = 1;
737 break;
738 case AL_SAMPLE_16:
739 size = 2;
740 break;
741 case AL_SAMPLE_24:
742 size = 4;
743 break;
744 default:
745 PyErr_SetString(ErrorObject, can't
determine width);
746 alFreeConfig(c);
747 return NULL;
748 }
749 break;
750 case AL_SAMPFMT_FLOAT:
751 size = 4;
752 break;
753 case AL_SAMPFMT_DOUBLE:
754 size = 8;
755 break;
756 default:
757 PyErr_SetString(ErrorObject, can't determine format);
758 alFreeConfig(c);
759 return NULL;
760 }
761 ch = alGetChannels(c);
762 alFreeConfig(c);
763 if (ch 0) {
764 PyErr_SetString(ErrorObject, can't determine # of
channels);
765 return NULL;
766 }
767 size *= ch;
768 v = PyString_FromStringAndSize((char *) NULL, size *
framecount);
769 if (v == NULL)
770 return NULL;
771
[...]
773 alReadFrames(self-port, (void *) PyString_AS_STRING(v),
framecount);
--
components: Extension Modules
messages: 65183
nosy: jnferguson
severity: normal
status: open
title: alp_ReadFrames() integer overflow leads to buffer overflow
type: security
versions: Python 2.5
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2593
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2587] PyString_FromStringAndSize() to be considered unsane
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 will cause the allocator to either fail (32-bit) or allocate more memory than expected-- either cause it handled/benign. If you'd prefer I can file every place where this actually bites you guys, I was just trying to be nice. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2587 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2588] PyOS_vsnprintf() underflow leads to memory corruption
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 into an if than sitting down and verifying that all XXX hundred code paths are safe). In the other bug, I have verified code paths into it, for instance test the misallocation poc in 2586 as an example __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2588 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2587] PyString_FromStringAndSize() to be considered unsane
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 [EMAIL PROTECTED] http://bugs.python.org/issue2587 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2594] alp_readsamps() overflow leads to memory corruption in ?unused? SGI extension module almodule.c
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 either though ;]
integer overflow/misallocation occurs at 1071, write to bad memory at 1076
1042 alp_readsamps(alpobject *self, PyObject *args)
1043 {
1044 long count;
1045 PyObject *v;
1046 ALconfig c;
1047 int width;
1048 int ret;
1049
1050 if (!PyArg_ParseTuple(args, l:readsamps, count))
1051 return NULL;
1052
1053 if (count = 0) {
1054 PyErr_SetString(ErrorObject, al.readsamps : arg =
0);
1055 return NULL;
1056 }
1057
1058 c = ALgetconfig(self-port);
1059 #ifdef AL_405
1060 width = ALgetsampfmt(c);
1061 if (width == AL_SAMPFMT_FLOAT)
1062 width = sizeof(float);
1063 else if (width == AL_SAMPFMT_DOUBLE)
1064 width = sizeof(double);
1065 else
1066 width = ALgetwidth(c);
1067 #else
1068 width = ALgetwidth(c);
1069 #endif /* AL_405 */
1070 ALfreeconfig(c);
1071 v = PyString_FromStringAndSize((char *)NULL, width * count);
1072 if (v == NULL)
1073 return NULL;
1074
1075 Py_BEGIN_ALLOW_THREADS
1076 ret = ALreadsamps(self-port, (void *)
PyString_AsString(v), count);
1077 Py_END_ALLOW_THREADS
1078 if (ret == -1) {
1079 Py_DECREF(v);
1080 return NULL;
1081 }
1082
1083 return (v);
1084 }
--
components: Extension Modules
messages: 65188
nosy: jnferguson
severity: normal
status: open
title: alp_readsamps() overflow leads to memory corruption in ?unused? SGI
extension module almodule.c
type: security
versions: Python 2.5
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2594
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2586] Integer signedness bugs in zlib modules
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 allocated and then takes advantage of the sign-conversion when the value is assigned to the zlib structure member (the member is unsigned, the value is signed) Honestly, you guys should consider enforcing the safe downcast usage because signedness issues are all over your code base (as I'm sure you know) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2586 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2595] Multiple integer overflows in imgfile extension module lead to buffer overflow
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 the idea, there's no need for me
to (further) spam the bug database by filing a bug for each one of
these, they're all pretty much the same.
Here the variables xsize, ysize and zsize are all externally derived.
While xsize and zsize are sanity checked, ysize is not. This potentially
results in an integer overflow/misallocation at line 133 and writes to
invalid memory in the calls to getrow()
85 static PyObject *
86 imgfile_read(PyObject *self, PyObject *args)
87 {
88 char *fname;
89 PyObject *rv;
90 int xsize, ysize, zsize;
91 char *cdatap;
92 long *idatap;
93 static short rs[8192], gs[8192], bs[8192];
94 int x, y;
95 IMAGE *image;
96 int yfirst, ylast, ystep;
97
98 if ( !PyArg_ParseTuple(args, s:read, fname) )
99 return NULL;
100
101 if ( (image = imgfile_open(fname)) == NULL )
102 return NULL;
[...]
116 xsize = image-xsize;
117 ysize = image-ysize;
118 zsize = image-zsize;
119 if ( zsize != 1 zsize != 3) {
120 iclose(image);
121 PyErr_SetString(ImgfileError,
122 Can only handle 1 or 3 byte pixels);
123 return NULL;
124 }
125 if ( xsize 8192 ) {
126 iclose(image);
127 PyErr_SetString(ImgfileError,
128 Can't handle image with 8192
columns);
129 return NULL;
130 }
131
132 if ( zsize == 3 ) zsize = 4;
133 rv = PyString_FromStringAndSize((char *)NULL,
xsize*ysize*zsize);
134 if ( rv == NULL ) {
138 cdatap = PyString_AsString(rv);
139 idatap = (long *)cdatap;
[...]
150 for ( y=yfirst; y != ylast !error_called; y += ystep ) {
151 if ( zsize == 1 ) {
152 getrow(image, rs, y, 0);
153 for(x=0; xxsize; x++ )
154 *cdatap++ = rs[x];
155 } else {
156 getrow(image, rs, y, 0);
157 getrow(image, gs, y, 1);
158 getrow(image, bs, y, 2);
159 for(x=0; xxsize; x++ )
160 *idatap++ = (rs[x] 0xff) |
161 ((gs[x] 0xff)8) |
162 ((bs[x] 0xff)16);
163 }
164 }
--
components: Extension Modules
messages: 65194
nosy: jnferguson
severity: normal
status: open
title: Multiple integer overflows in imgfile extension module lead to buffer
overflow
type: security
versions: Python 2.5
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2595
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2595] Multiple integer overflows in imgfile extension module lead to buffer overflow
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 instead of the processors) and I need to have these public/patched before I talk about them. I've got a bunch more bugs, I'll file them later when some of this stuff is caught up with. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2595 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2587] PyString_FromStringAndSize() to be considered unsane
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 int count = 0;
492 int len = 1024;
[...]
496 if (!PyArg_ParseTuple(args, |i:read, len))
497 return NULL;
498
499 if (!(buf = PyString_FromStringAndSize((char *) 0, len)))
500 return NULL;
[...]
521 count = SSL_read(self-ssl, PyString_AsString(buf),
len);
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2587
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2588] PyOS_vsnprintf() underflow leads to memory corruption
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 to break; with as commonly used of a function as it is, it's really a matter of when and not so much if. While no one seems to ever use it this way, don't forget that a good alternative to asprintf() is calling sprintf() with a length of zero to get the length (in compliant implementations), allocating the memory and then calling it again. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2588 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
