Re: Python, was: Re: only days left to ports lock (4.4 release)
Hi, On Wed, 06.08.2008 at 13:27:31 +1000, Damien Miller [EMAIL PROTECTED] wrote: On Tue, 5 Aug 2008, Damien Miller wrote: Applied (though only exploitable on amd64) - new diff attached. Ok, this has been committed - thanks to everyone who tested and especially Toni Mueller and Valery Masiutsin for their great help in extracting the patches from Python's inscrutable release branch. thanks, but I have to pass all honours to Matthias Klose because he, or at least not me, successfully toured upstream's repository. I only culled from his work. Kind regards, --Toni++
Re: Python, was: Re: only days left to ports lock (4.4 release)
On Tue, 5 Aug 2008, Damien Miller wrote: Applied (though only exploitable on amd64) - new diff attached. Ok, this has been committed - thanks to everyone who tested and especially Toni Mueller and Valery Masiutsin for their great help in extracting the patches from Python's inscrutable release branch. -d
Re: Python, was: Re: only days left to ports lock (4.4 release)
Ok, here is a patch for lang/python/2.5.
It tests OK (passes regress) on i386, and I'm yet to do sparc64 and zaurus.
Tests on other platforms and testing with your favourite apps is welcome.
-d
Index: Makefile
===
RCS file: /cvs/ports/lang/python/2.5/Makefile,v
retrieving revision 1.23
diff -u -p -r1.23 Makefile
--- Makefile25 Jul 2008 19:32:21 - 1.23
+++ Makefile5 Aug 2008 08:34:09 -
@@ -2,7 +2,7 @@
VERSION= 2.5
PATCHLEVEL=.2
-PKG_PATCHLEVEL=p3
+PKG_PATCHLEVEL=p4
SHARED_LIBS= python2.5 1.0
# PSUBDIR= python/${VERSION}
Index: patches/patch-Include_pymem_h
===
RCS file: patches/patch-Include_pymem_h
diff -N patches/patch-Include_pymem_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-Include_pymem_h 5 Aug 2008 08:34:09 -
@@ -0,0 +1,59 @@
+$OpenBSD$
+--- Include/pymem.h.orig Thu Feb 14 22:26:18 2008
Include/pymem.hTue Aug 5 18:18:52 2008
+@@ -67,8 +67,12 @@ PyAPI_FUNC(void) PyMem_Free(void *);
+for malloc(0), which would be treated as an error. Some platforms
+would return a pointer with no memory behind it, which would break
+pymalloc. To solve these problems, allocate an extra byte. */
+-#define PyMem_MALLOC(n) malloc((n) ? (n) : 1)
+-#define PyMem_REALLOC(p, n) realloc((p), (n) ? (n) : 1)
++/* Returns NULL to indicate error if a negative size or size larger than
++ Py_ssize_t can represent is supplied. Helps prevents security holes. */
++#define PyMem_MALLOC(n) (((n) 0 || (n) PY_SSIZE_T_MAX) ?
NULL \
++ : malloc((n) ? (n) : 1))
++#define PyMem_REALLOC(p, n) (((n) 0 || (n) PY_SSIZE_T_MAX) ? NULL \
++ : realloc((p), (n) ? (n) : 1))
+ #define PyMem_FREEfree
+
+ #endif/* PYMALLOC_DEBUG */
+@@ -77,24 +81,31 @@ PyAPI_FUNC(void) PyMem_Free(void *);
+ * Type-oriented memory interface
+ * ==
+ *
+- * These are carried along for historical reasons. There's rarely a good
+- * reason to use them anymore (you can just as easily do the multiply and
+- * cast yourself).
++ * Allocate memory for n objects of the given type. Returns a new pointer
++ * or NULL if the request was too large or memory allocation failed. Use
++ * these macros rather than doing the multiplication yourself so that proper
++ * overflow checking is always done.
+ */
+
+ #define PyMem_New(type, n) \
+- ( assert((n) = PY_SIZE_MAX / sizeof(type)) , \
++ ( ((n) PY_SSIZE_T_MAX / sizeof(type)) ? NULL : \
+ ( (type *) PyMem_Malloc((n) * sizeof(type)) ) )
+ #define PyMem_NEW(type, n) \
+- ( assert((n) = PY_SIZE_MAX / sizeof(type)) , \
++ ( ((n) PY_SSIZE_T_MAX / sizeof(type)) ? NULL : \
+ ( (type *) PyMem_MALLOC((n) * sizeof(type)) ) )
+
++/*
++ * The value of (p) is always clobbered by this macro regardless of success.
++ * The caller MUST check if (p) is NULL afterwards and deal with the memory
++ * error if so. This means the original value of (p) MUST be saved for the
++ * caller's memory error handler to not lose track of it.
++ */
+ #define PyMem_Resize(p, type, n) \
+- ( assert((n) = PY_SIZE_MAX / sizeof(type)) , \
+- ( (p) = (type *) PyMem_Realloc((p), (n) * sizeof(type)) ) )
++ ( (p) = ((n) PY_SSIZE_T_MAX / sizeof(type)) ? NULL : \
++ (type *) PyMem_Realloc((p), (n) * sizeof(type)) )
+ #define PyMem_RESIZE(p, type, n) \
+- ( assert((n) = PY_SIZE_MAX / sizeof(type)) , \
+- ( (p) = (type *) PyMem_REALLOC((p), (n) * sizeof(type)) ) )
++ ( (p) = ((n) PY_SSIZE_T_MAX / sizeof(type)) ? NULL : \
++ (type *) PyMem_REALLOC((p), (n) * sizeof(type)) )
+
+ /* PyMem{Del,DEL} are left over from ancient days, and shouldn't be used
+ * anymore. They're just confusing aliases for PyMem_{Free,FREE} now.
Index: patches/patch-Lib_test_seq_tests_py
===
RCS file: patches/patch-Lib_test_seq_tests_py
diff -N patches/patch-Lib_test_seq_tests_py
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-Lib_test_seq_tests_py 5 Aug 2008 08:34:09 -
@@ -0,0 +1,22 @@
+$OpenBSD$
+--- Lib/test/seq_tests.py.orig Tue Nov 13 07:04:41 2007
Lib/test/seq_tests.py Tue Aug 5 18:18:52 2008
+@@ -307,11 +307,13 @@ class CommonTest(unittest.TestCase):
+ self.assertEqual(id(s), id(s*1))
+
+ def test_bigrepeat(self):
+-x = self.type2test([0])
+-x *= 2**16
+-self.assertRaises(MemoryError, x.__mul__, 2**16)
+-if hasattr(x, '__imul__'):
+-self.assertRaises(MemoryError, x.__imul__, 2**16)
++import sys
++if sys.maxint = 2147483647:
++x = self.type2test([0])
++x *= 2**16
++self.assertRaises(MemoryError, x.__mul__, 2**16)
++
Re: Python, was: Re: only days left to ports lock (4.4 release)
Hi, On Tue, 05.08.2008 at 18:36:34 +1000, Damien Miller [EMAIL PROTECTED] wrote: Ok, here is a patch for lang/python/2.5. thank you very much for the effort. Unfortunately, there's some more stuff which should probably make it (code execution problems included). I found these just today, assuming that everything up to CVE-2008-2315 is already covered: CVE-2008-3144 CVE-2008-3143 CVE-2008-3142 CVE-2008-2316 I don't know which of these are already covered, but the first is labelled medium, the other high in the CVE database. Kind regards, --Toni++
Re: Python, was: Re: only days left to ports lock (4.4 release)
* [EMAIL PROTECTED] wrote: I am no Python user myself but because some people here realy care for it and because I read about this today I wanted to mention that there are more issues to fix propably. Gentoo reports about multiple integer/buffer overflows. http://bugs.gentoo.org/show_bug.cgi?id=230640 http://bugs.gentoo.org/show_bug.cgi?id=232137 And some where patched by Apple http://svn.python.org/view?rev=65335view=rev As I said I don 't use Python (not actively) but I hope those infos may still help to improve the port. If you really want to help, please provide patches. Kind regards, Sebastian
Re: Python, was: Re: only days left to ports lock (4.4 release)
On Mon, 4 Aug 2008, Toni Mueller wrote: Hi, On Tue, 29.07.2008 at 21:32:18 -0600, Theo de Raadt [EMAIL PROTECTED] wrote: Perhaps whoever the maintainer is will merge this in time. I hope so. Unfortunately, I feel unable to do this myself, but I also wanted to avoid this getting lost, as I had not seen anything in the CVS. Damien was kind enough to send the desired message. I'm not going to be able to work on it for a few more days and this will increase the chance that the patches will miss the 4.4 cutoff. If anyone want to help out, I'll repeat: Want to help? Then you can cherrypick the patches from the python 2.5 branch that close the vulnerabilities and post them to the list (as links to the svn changesets in the python webcvs/viewvc) matched against CVE numbers. -d
Re: Python, was: Re: only days left to ports lock (4.4 release)
On 2008/08/04 21:50, Damien Miller wrote: Want to help? Then you can cherrypick the patches from the python 2.5 branch that close the vulnerabilities and post them to the list (as links to the svn changesets in the python webcvs/viewvc) matched against CVE numbers. stringobject and zlib are easy enough, imageop less so. CVE-2008-1721 http://bugs.python.org/issue2586 Python zlib module is prone to a remote buffer-overflow vulnerability because the library fails to properly sanitize user-supplied data. An attacker can exploit this issue to execute arbitrary code with the privileges of the user running an application that relies on the affected library. Failed exploit attempts will result in a denial-of-service condition. Fix zlib crash from zlib.decompressobj().flush(val) when val was not positive. It tried to allocate negative or zero memory. That fails. http://svn.python.org/view/python/trunk/Lib/test/test_zlib.py?p2=%2Fpython%2Ftrunk%2FLib%2Ftest%2Ftest_zlib.pyp1=python%2Ftrunk%2FLib%2Ftest%2Ftest_zlib.pyr1=62235r2=62234rev=62235view=diffmakepatch=1diff_format=h http://svn.python.org/view/python/trunk/Modules/zlibmodule.c?p2=%2Fpython%2Ftrunk%2FModules%2Fzlibmodule.cp1=python%2Ftrunk%2FModules%2Fzlibmodule.cr1=62235r2=62234rev=62235view=diffmakepatch=1diff_format=h CVE-2008-1887 http://bugs.python.org/issue2587 Issue #2587: In the C API, PyString_FromStringAndSize() takes a signed size parameter but was not verifying that it was greater than zero. Values less than zero will now raise a SystemError and return NULL to indicate a bug in the calling C code. Python 2.5.2 and earlier allows context-dependent attackers to execute arbitrary code via multiple vectors that cause a negative size value to be provided to the PyString_FromStringAndSize function, which allocates less memory than expected when assert() is disabled and triggers a buffer overflow. http://svn.python.org/view/python/branches/release25-maint/Objects/stringobject.c?p2=%2Fpython%2Fbranches%2Frelease25-maint%2FObjects%2Fstringobject.cp1=python%2Fbranches%2Frelease25-maint%2FObjects%2Fstringobject.cr1=62262r2=62261rev=62262view=diffmakepatch=1diff_format=h CVE-2007-4965 CVE-2008-1679 http://bugs.python.org/issue1179 Multiple integer overflows in imageop.c in Python before 2.5.3 allow context-dependent attackers to cause a denial of service (crash) and possibly execute arbitrary code via crafted images that trigger heap-based buffer overflows. Looks like it's only partially fixed in their tree. http://bugs.python.org/file8592/python-2.5.CVE-2007-4965-int-overflow.patch http://bugs.python.org/file9975/python-2.5-int-overflow-2.patch http://svn.python.org/view/python/branches/release25-maint/Modules/imageop.c http://svn.python.org/view/python/branches/release25-maint/Modules/rgbimgmodule.c
Re: Python, was: Re: only days left to ports lock (4.4 release)
Hello. What about issues in #2588, #2599, #2620 ? As far as i see from reading svn log of release25-maint, there are also so called apple security fixes and commit related to openbsd fcntl handling. I've cherrypicked those patches, built python, it passes make regress, and works fine for me, is there any point to send the diff, at this point of time ? Regards Valery.
Re: Python, was: Re: only days left to ports lock (4.4 release)
On 2008/08/04 16:32, Valery Masiutsin wrote:
Hello.
What about issues in #2588, #2599, #2620 ?
Oh... Are python users supposed to tramp through the tickets just
to identify the security problems?
It would be nice if there was somewhere official to find these.
Like http://www.python.org/news/security/, but actually maintained.
As far as i see from reading svn log of release25-maint, there are
also so called
apple security fixes and commit related to openbsd fcntl
handling. I've cherrypicked those patches, built python, it passes
make regress, and works fine for me,
is there any point to send the diff, at this point of time ?
It might not go into the release, it's pretty late for that now,
but you may as well send it along rather than just hold onto it.
Ok, here it is. I think it could suite as a starting point for
post-release activity.
#2588, #2589 - PyOS_vsnprintf() issues, i think they are unrelated to
us, false alarm, so i skipped them.
URL= http://svn.python.org/projects/python/branches/release25-maint
1. #2620 - Multiple buffer overflows in unicode processing.
svn diff -r65234:65261 $URL
2. apple security patches
svn diff -r65261:65334 $URL
3. OpenBSD fcntl.ioctl handling on 64-bit OpenBSD.
svn diff -r65461:65466 $URL
I removed the bits applied to Misc/News file, i did not apply fixes
mentioned earlier, i am ready to do this, if it needs so.
Tested on amd64.
Regards Valery.
Index: patches/patch-Include_pymem_h
===
RCS file: patches/patch-Include_pymem_h
diff -N patches/patch-Include_pymem_h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-Include_pymem_h 4 Aug 2008 15:17:15 -
@@ -0,0 +1,59 @@
+$OpenBSD$
+--- Include/pymem.h.orig Thu Feb 14 13:26:18 2008
Include/pymem.hMon Aug 4 21:12:55 2008
+@@ -67,8 +67,12 @@ PyAPI_FUNC(void) PyMem_Free(void *);
+for malloc(0), which would be treated as an error. Some platforms
+would return a pointer with no memory behind it, which would break
+pymalloc. To solve these problems, allocate an extra byte. */
+-#define PyMem_MALLOC(n) malloc((n) ? (n) : 1)
+-#define PyMem_REALLOC(p, n) realloc((p), (n) ? (n) : 1)
++/* Returns NULL to indicate error if a negative size or size larger
than ++ Py_ssize_t can represent is supplied. Helps prevents
security holes. */ ++#define PyMem_MALLOC(n) (((n) 0 ||
(n) PY_SSIZE_T_MAX) ? NULL \ ++ :
malloc((n) ? (n) : 1)) ++#define PyMem_REALLOC(p, n) (((n) 0 || (n)
PY_SSIZE_T_MAX) ? NULL \ ++ :
realloc((p), (n) ? (n) : 1))
+ #define PyMem_FREEfree
+
+ #endif/* PYMALLOC_DEBUG */
+@@ -77,24 +81,31 @@ PyAPI_FUNC(void) PyMem_Free(void *);
+ * Type-oriented memory interface
+ * ==
+ *
+- * These are carried along for historical reasons. There's rarely a
good +- * reason to use them anymore (you can just as easily do the
multiply and +- * cast yourself).
++ * Allocate memory for n objects of the given type. Returns a new
pointer ++ * or NULL if the request was too large or memory allocation
failed. Use ++ * these macros rather than doing the multiplication
yourself so that proper ++ * overflow checking is always done.
+ */
+
+ #define PyMem_New(type, n) \
+- ( assert((n) = PY_SIZE_MAX / sizeof(type)) , \
++ ( ((n) PY_SSIZE_T_MAX / sizeof(type)) ? NULL : \
+ ( (type *) PyMem_Malloc((n) * sizeof(type)) ) )
+ #define PyMem_NEW(type, n) \
+- ( assert((n) = PY_SIZE_MAX / sizeof(type)) , \
++ ( ((n) PY_SSIZE_T_MAX / sizeof(type)) ? NULL : \
+ ( (type *) PyMem_MALLOC((n) * sizeof(type)) ) )
+
++/*
++ * The value of (p) is always clobbered by this macro regardless of
success. ++ * The caller MUST check if (p) is NULL afterwards and deal
with the memory ++ * error if so. This means the original value of (p)
MUST be saved for the ++ * caller's memory error handler to not lose
track of it. ++ */
+ #define PyMem_Resize(p, type, n) \
+- ( assert((n) = PY_SIZE_MAX / sizeof(type)) , \
+- ( (p) = (type *) PyMem_Realloc((p), (n) * sizeof(type)) ) )
++ ( (p) = ((n) PY_SSIZE_T_MAX / sizeof(type)) ? NULL : \
++ (type *) PyMem_Realloc((p), (n) * sizeof(type)) )
+ #define PyMem_RESIZE(p, type, n) \
+- ( assert((n) = PY_SIZE_MAX / sizeof(type)) , \
+- ( (p) = (type *) PyMem_REALLOC((p), (n) * sizeof(type)) ) )
++ ( (p) = ((n) PY_SSIZE_T_MAX / sizeof(type)) ? NULL : \
++ (type *) PyMem_REALLOC((p), (n) * sizeof(type)) )
+
+ /* PyMem{Del,DEL} are left over from ancient days, and shouldn't be
used
+ * anymore. They're just confusing aliases for PyMem_{Free,FREE} now.
Index: patches/patch-Lib_test_seq_tests_py
===
RCS file: patches/patch-Lib_test_seq_tests_py
diff -N patches/patch-Lib_test_seq_tests_py
--- /dev/null 1 Jan 1970 00:00:00 -
+++
Re: Python, was: Re: only days left to ports lock (4.4 release)
On Mon, Aug 4, 2008 at 12:41 PM, Valery Masiutsin [EMAIL PROTECTED] wrote: On 2008/08/04 16:32, Valery Masiutsin wrote: Hello. What about issues in #2588, #2599, #2620 ? Oh... Are python users supposed to tramp through the tickets just to identify the security problems? It would be nice if there was somewhere official to find these. Like http://www.python.org/news/security/, but actually maintained. As far as i see from reading svn log of release25-maint, there are also so called apple security fixes and commit related to openbsd fcntl handling. I've cherrypicked those patches, built python, it passes make regress, and works fine for me, is there any point to send the diff, at this point of time ? It might not go into the release, it's pretty late for that now, but you may as well send it along rather than just hold onto it. Ok, here it is. I think it could suite as a starting point for post-release activity. ... It appears that a lot of the work to pick the right patches has been done in this thread. Has someone familiar with python double checked Valery's work? Also extensive testing should be done by those that use it. It seems like enough people consider it important for the release, so let's get it done.
