[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
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: 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: 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: 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
[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
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
[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
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
[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: > 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
[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
[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: 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: 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: 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: 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
[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
[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
[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; x <http://bugs.python.org/issue2595> __ ___ 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
[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
[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
[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: 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
[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
[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
[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
[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
[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
[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
[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
[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
[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