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)
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)
* [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=65335&view=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 Tue, 5 Aug 2008, Toni Mueller wrote:
>
> 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
Already in my patchset
> CVE-2008-3143
This is already fixed in 2.5.2
> CVE-2008-3142
Already in my patchset
> CVE-2008-2316
Applied (though only exploitable on amd64) - new diff attached.
-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 11:06:58 -
@@ -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 11:06:58 -
@@ -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 11:06:58 -
@@ -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(
Re: Python, was: Re: only days left to ports lock (4.4 release)
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=65335&view=rev As I said I don 't use Python (not actively) but I hope those infos may still help to improve the port. Kind regards, Sebastian
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)
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*
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.
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/n
Python patches, was: Re: only days left to ports lock (4.4 release)
Hi,
On Wed, 30.07.2008 at 11:16:04 +1000, Damien Miller <[EMAIL PROTECTED]> wrote:
> > CVE-2007-2052
>
> fixed in python-2.5.1
>
> > CVE-2007-4965
>
> ditto
thanks!
> > CVE-2008-1679 CVE-2008-1721 CVE-2008-1887
>
> These are present in 2.5.2 and we should fix them prior to release.
> I'll look at it.
I can "easily" loot patches for these problems from Debian (2.5.2-10,
ie. "latest"):
CVE-2007-4965 CVE-2008-1679 CVE-2008-2315
But I (yet) don't know about the others, and a quick glance into
upstream's SVN is... confusing, and in their tracker, I also don't find
what I'm looking for. But then, it may be me - I'm unfamiliar with
their setup and procedures. :(
I've attached the three mentioned patches, but (of course) can't vouch
for them.
Kind regards,
--Toni++
diff -Naur Modules/imageop.c Modules/imageop.c
--- Modules/imageop.c 2006-09-27 21:17:32.0 +0200
+++ Modules/imageop.c 2008-04-15 12:11:38.0 +0200
@@ -78,7 +78,7 @@
char *cp, *ncp;
short *nsp;
Py_Int32 *nlp;
- int len, size, x, y, newx1, newx2, newy1, newy2;
+ int len, size, x, y, newx1, newx2, newy1, newy2, nlen;
int ix, iy, xstep, ystep;
PyObject *rv;
@@ -90,13 +90,19 @@
PyErr_SetString(ImageopError, "Size should be 1, 2 or 4");
return 0;
}
- if ( len != size*x*y ) {
+ if (( len != size*x*y ) ||
+( size != ((len / x) / y) )) {
PyErr_SetString(ImageopError, "String has incorrect length");
return 0;
}
xstep = (newx1 < newx2)? 1 : -1;
ystep = (newy1 < newy2)? 1 : -1;
+nlen = (abs(newx2-newx1)+1)*(abs(newy2-newy1)+1)*size;
+if ( size != ((nlen / (abs(newx2-newx1)+1)) / (abs(newy2-newy1)+1)) ) {
+ PyErr_SetString(ImageopError, "String has incorrect length");
+ return 0;
+ }
rv = PyString_FromStringAndSize(NULL,
(abs(newx2-newx1)+1)*(abs(newy2-newy1)+1)*size);
if ( rv == 0 )
@@ -132,7 +138,7 @@
char *cp, *ncp;
short *nsp;
Py_Int32 *nlp;
- int len, size, x, y, newx, newy;
+ int len, size, x, y, newx, newy, nlen;
int ix, iy;
int oix, oiy;
PyObject *rv;
@@ -145,12 +151,18 @@
PyErr_SetString(ImageopError, "Size should be 1, 2 or 4");
return 0;
}
- if ( len != size*x*y ) {
+ if ( ( len != size*x*y ) ||
+ ( size != ((len / x) / y) ) ) {
+ PyErr_SetString(ImageopError, "String has incorrect length");
+ return 0;
+ }
+nlen = newx*newy*size;
+ if ( size != ((nlen / newx) / newy) ) {
PyErr_SetString(ImageopError, "String has incorrect length");
return 0;
}
- rv = PyString_FromStringAndSize(NULL, newx*newy*size);
+ rv = PyString_FromStringAndSize(NULL, nlen);
if ( rv == 0 )
return 0;
ncp = (char *)PyString_AsString(rv);
@@ -190,7 +202,8 @@
PyErr_SetString(ImageopError, "Size should be 1 or 4");
return 0;
}
- if ( maxx*maxy*width != len ) {
+ if ( ( maxx*maxy*width != len ) ||
+ ( maxx != ((len / maxy) / width) ) ) {
PyErr_SetString(ImageopError, "String has incorrect length");
return 0;
}
@@ -240,7 +253,8 @@
if ( !PyArg_ParseTuple(args, "s#iii", &cp, &len, &x, &y, &tres) )
return 0;
- if ( x*y != len ) {
+ if ( ( x*y != len ) ||
+ ( x != len / y ) ) {
PyErr_SetString(ImageopError, "String has incorrect length");
return 0;
}
@@ -281,7 +295,8 @@
if ( !PyArg_ParseTuple(args, "s#ii", &cp, &len, &x, &y) )
return 0;
- if ( x*y != len ) {
+ if ( ( x*y != len ) ||
+ ( x != len / y ) ) {
PyErr_SetString(ImageopError, "String has incorrect length");
return 0;
}
@@ -320,7 +335,8 @@
if ( !PyArg_ParseTuple(args, "s#ii", &cp, &len, &x, &y) )
return 0;
- if ( x*y != len ) {
+ if ( ( x*y != len ) ||
+ ( x != len / y ) ) {
PyErr_SetString(ImageopError, "String has incorrect length");
return 0;
}
@@ -358,7 +374,8 @@
if ( !PyArg_ParseTuple(args, "s#ii", &cp, &len, &x, &y) )
return 0;
- if ( x*y != len ) {
+ if ( ( x*y != len ) ||
+ ( x != len / y ) ) {
PyErr_SetString(ImageopError, "String has incorrect length");
return 0;
}
@@ -404,7 +421,8 @@
if ( !PyArg_ParseTuple(args, "s#ii", &cp, &len, &x, &y) )
return 0;
- if ( x*y != len ) {
+ if ( ( x*y != len ) ||
+ ( x != len / y ) ) {
PyErr_SetString(ImageopError, "String has incorrect length");
return 0;
}
@@ -443,7 +461,11 @@
if ( !PyArg_ParseTuple(args, "s#", &cp, &len, &x, &y, &v0, &v1) )
return 0;
- nlen = x*y;
+nlen = x*y;
+ if ( x != (nlen / y) ) {
+ PyErr_SetString(ImageopError, "String has incorrect length");
+ return 0;
+ }
if ( (nlen+7)/8 != len ) {
PyErr_SetString(ImageopError, "String has incorrect length");
return 0;
@@ -481,6 +503,10 @@
return 0;
nlen = x*y;
+ if ( x != (nlen / y) ) {
+ PyErr_SetString(ImageopError, "String has incorrect length");
+ return 0;
+ }
if ( (nlen+3)/4 != len ) {
PyErr_SetString(ImageopError, "String has incorrect length");
return 0;
@@ -517,6 +543,10 @@
return 0;
nlen = x*y;
+ if ( x != (nlen / y) ) {
+ PyErr_S
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.
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 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.py&p1=python%2Ftrunk%2FLib%2Ftest%2Ftest_zlib.py&r1=62235&r2=62234&rev=62235&view=diff&makepatch=1&diff_format=h http://svn.python.org/view/python/trunk/Modules/zlibmodule.c?p2=%2Fpython%2Ftrunk%2FModules%2Fzlibmodule.c&p1=python%2Ftrunk%2FModules%2Fzlibmodule.c&r1=62235&r2=62234&rev=62235&view=diff&makepatch=1&diff_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.c&p1=python%2Fbranches%2Frelease25-maint%2FObjects%2Fstringobject.c&r1=62262&r2=62261&rev=62262&view=diff&makepatch=1&diff_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)
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: only days left to ports lock (4.4 release)
Hi, On Thu, 31.07.2008 at 16:32:02 +0200, Sebastian Rother <[EMAIL PROTECTED]> wrote: > Well maybe the issue is that, except of the developers, nobody knows how > you do make a release or what a gigantic work it is? you imho have a point in that the pain is probably not as visible in OpenBSD as it might be in other projects, but I can assure you that making a "quality OS release" is a *HUGE* effort, no matter, how you look at it. Kind regards, --Toni++
Python, was: Re: only days left to ports lock (4.4 release)
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. > Would you rather have a good release that has good quality > integration between packages > > or > > One that has the latest python? > > You can't always have both. I primarily wanted to not see OpenBSD ship packages with known security problems, two of them seemed like a good match for "high profile". I was unaware about the state of Python in OpenBSD prior to Damien's message. FWIW, the list was taken from a recent DSA, but you already knew that. Other than that (this is more a general QA question): Are there any known methods to (formally/automatically?) check for package integration wrt. Python? I mean, something like a "system-wide" test suite? Kind regards, --Toni++
Re: only days left to ports lock (4.4 release)
On Thu, 31 Jul 2008, Sebastian Rother wrote: > I wont piss off anybody, it will be a gigantic task and I can imagine it > (hopefully) because of some projects as well but except to tell anybody > "you can't have both" a "we do not have the manpower to do this" would be > more truthly? It's no shame to admit there not enough res. available to do > things. 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. As has been said countless times before, chatter on mailing lists will not yield progress; someone has to actually do the work. -d
Re: only days left to ports lock (4.4 release)
"Sebastian Rother" <[EMAIL PROTECTED]> writes: > I wont piss off anybody, it will be a gigantic task and I can imagine it > (hopefully) because of some projects as well but except to tell anybody > "you can't have both" a "we do not have the manpower to do this" would be > more truthly? It's no shame to admit there not enough res. available to do > things. 9 women don't give birth to one child in one month. //art
Re: only days left to ports lock (4.4 release)
On 2008-07-31, Sebastian Rother <[EMAIL PROTECTED]> wrote: > Theo wrote: >>Yes, and sometimes tough love is required. >> >>Perhaps whoever the maintainer is will merge this in time. >> >>Perhaps not. >> >>Let me pose a question: >> >>Would you rather have a good release that has good quality >>integration between packages >> >>or >> >>One that has the latest python? > > Let me pose a counter question: > > Who needs "working" ports or a good quality integration between packages > f.e. for python if each kid from ghana could crash your webapplication or > whatever you build with python. Could you explain what exactly your problem is with Ghanaian children? I'm sure most children from Ghana are focused on real problems rather than writing bullshit on mailing lists. Jona
Re: only days left to ports lock (4.4 release)
On Thu, Jul 31, 2008 at 04:32:02PM +0200, Sebastian Rother wrote: > > Look, I'm going to side with Theo on that one. > > > > There are lots of *big* issues to fix each release. It doesn't look like > > it from outside, but we have show-stoppers. > > > > Each release, we refine the process. > > > > This release, we cut down on the number of non-critical commits right up > > to the lock. > > > > So that the release goes smoother. > > So that things go faster. > > You can help by testing the snapshots, telling what does not work, etc. > > > > As soon as the release is past, it will be `business as usual', and of > > course, a lot of `minor' patches are going to happen. > > > Seriously, the release work is gigantic. There are choices to be made. > > If you don't like the current choices, tough. > > Well maybe the issue is that, except of the developers, nobody knows how > you do make a release or what a gigantic work it is? 17 arches, 4000 ports yeah piece of cake. > > I wont piss off anybody, it will be a gigantic task and I can imagine it Too late; you as usual took a giant dump on the development process without any knowledge of what is happening behind the scenes. > (hopefully) because of some projects as well but except to tell anybody > "you can't have both" a "we do not have the manpower to do this" would be > more truthly? It's no shame to admit there not enough res. available to do > things. You can't have it both ways. Stabilizing an OS isn't a piece of cake. > > Anyway I wont argue and I thank you very much for any effort! (and I > seriously mean it). :) Maybe you should not say those things then. > > And this is offtopic but: In case pcc gets "productiv" do you think this > may would speed things up. Except manpower what else is the bottleneck > currently (related to the ports)? > > > Kind regards, > Sebastian >
Re: only days left to ports lock (4.4 release)
> Look, I'm going to side with Theo on that one. > > There are lots of *big* issues to fix each release. It doesn't look like > it from outside, but we have show-stoppers. > > Each release, we refine the process. > > This release, we cut down on the number of non-critical commits right up > to the lock. > > So that the release goes smoother. > So that things go faster. > You can help by testing the snapshots, telling what does not work, etc. > > As soon as the release is past, it will be `business as usual', and of > course, a lot of `minor' patches are going to happen. > Seriously, the release work is gigantic. There are choices to be made. > If you don't like the current choices, tough. Well maybe the issue is that, except of the developers, nobody knows how you do make a release or what a gigantic work it is? I wont piss off anybody, it will be a gigantic task and I can imagine it (hopefully) because of some projects as well but except to tell anybody "you can't have both" a "we do not have the manpower to do this" would be more truthly? It's no shame to admit there not enough res. available to do things. Anyway I wont argue and I thank you very much for any effort! (and I seriously mean it). :) And this is offtopic but: In case pcc gets "productiv" do you think this may would speed things up. Except manpower what else is the bottleneck currently (related to the ports)? Kind regards, Sebastian
Re: only days left to ports lock (4.4 release)
> Theo wrote: > >Yes, and sometimes tough love is required. > > > >Perhaps whoever the maintainer is will merge this in time. > > > >Perhaps not. > > > >Let me pose a question: > > > >Would you rather have a good release that has good quality > >integration between packages > > > >or > > > >One that has the latest python? > > Let me pose a counter question: > > Who needs "working" ports or a good quality integration between packages > f.e. for python if each kid from ghana could crash your webapplication or > whatever you build with python. > > Some of us do have internet Theo... > > >You can't always have both. > > You are right but we could try? You've had 5 months to try. Fine, I can postpone the 4.4 release to next year. Thanks for talking.
Re: only days left to ports lock (4.4 release)
On Thu, Jul 31, 2008 at 12:28:27PM +0200, Sebastian Rother wrote: > Theo wrote: > >Yes, and sometimes tough love is required. > > > >Perhaps whoever the maintainer is will merge this in time. > > > >Perhaps not. > > > >Let me pose a question: > > > >Would you rather have a good release that has good quality > >integration between packages > > > >or > > > >One that has the latest python? > > Let me pose a counter question: > > Who needs "working" ports or a good quality integration between packages > f.e. for python if each kid from ghana could crash your webapplication or > whatever you build with python. > > Some of us do have internet Theo... > > >You can't always have both. > > You are right but we could try? > OpenBSD isn't bug free either but you still try to do your best (and you > do pretty good! all of you developers do a very excellent job!). > > The last sentence with the "you can't always have both" reminds me more to > Linus then to you Theo... The point is that if you try to do too much during relese time, you end up having accomplished nothing. -Otto
Re: only days left to ports lock (4.4 release)
Look, I'm going to side with Theo on that one. There are lots of *big* issues to fix each release. It doesn't look like it from outside, but we have show-stoppers. Each release, we refine the process. This release, we cut down on the number of non-critical commits right up to the lock. So that the release goes smoother. So that things go faster. You can help by testing the snapshots, telling what does not work, etc. As soon as the release is past, it will be `business as usual', and of course, a lot of `minor' patches are going to happen. Seriously, the release work is gigantic. There are choices to be made. If you don't like the current choices, tough.
Re: only days left to ports lock (4.4 release)
Theo wrote: >Yes, and sometimes tough love is required. > >Perhaps whoever the maintainer is will merge this in time. > >Perhaps not. > >Let me pose a question: > >Would you rather have a good release that has good quality >integration between packages > >or > >One that has the latest python? Let me pose a counter question: Who needs "working" ports or a good quality integration between packages f.e. for python if each kid from ghana could crash your webapplication or whatever you build with python. Some of us do have internet Theo... >You can't always have both. You are right but we could try? OpenBSD isn't bug free either but you still try to do your best (and you do pretty good! all of you developers do a very excellent job!). The last sentence with the "you can't always have both" reminds me more to Linus then to you Theo... I personaly wont face stack corruptions because I listen to a mp3 (or a streaming radio?) and the lame-port is outdated but "works very well with the also outdated &next_thing_wich_is_brocken_here". The main problem OpenBSD has and wich affects the ports-situation propably too is the lack of menpower. Even I can't support the Maintainers by sending updated ports to them I can still remind them to take a look if I do notice it's outdated. One solution may would be if at least all @openbsd-Maintainers would take a look at their ports (again) like 1-2 weeks before the tree gets closed. Just an idea but it takes time too (wich is the main problem I guess). Ok now start calling me a whiner or whatever. I can stand it so far. But it's a fact that a secure OS wont help you if your PHP/Python/&anything_else_here crashes 24/7 because of a lame autorooter-Script wich hits your webservers or a damn e-Mail worm or &anything_else_here. The weakest link breaks, always... Sure we all could run -current but then making "stable ports" would be a joke anyway. :-) Kind regards, Sebastian
Re: only days left to ports lock (4.4 release)
> On Mon, 28.07.2008 at 17:24:01 -0700, Peter Valchev <[EMAIL PROTECTED]> wrote: > > We are in release mode, with 4.4 just around the corner. This means > > that from now, no more commits to ports unless they are VERY urgent - > > such as fixing a broken dependency, high impact security issue, etc, > > I'd like to point at some problems in Python 2.5.2, which I became > aware of just two days ago: > > CVE-2007-2052 CVE-2007-4965 CVE-2008-1679 CVE-2008-1721 CVE-2008-1887 > > The latter two are claimed to result in the execution of arbitrary > code. Yes, and sometimes tough love is required. Perhaps whoever the maintainer is will merge this in time. Perhaps not. Let me pose a question: Would you rather have a good release that has good quality integration between packages or One that has the latest python? You can't always have both.
Re: only days left to ports lock (4.4 release)
On Wed, 30 Jul 2008, Toni Mueller wrote: > > Hi, > > On Mon, 28.07.2008 at 17:24:01 -0700, Peter Valchev <[EMAIL PROTECTED]> wrote: > > We are in release mode, with 4.4 just around the corner. This means > > that from now, no more commits to ports unless they are VERY urgent - > > such as fixing a broken dependency, high impact security issue, etc, > > I'd like to point at some problems in Python 2.5.2, which I became > aware of just two days ago: > > CVE-2007-2052 fixed in python-2.5.1 > CVE-2007-4965 ditto > CVE-2008-1679 CVE-2008-1721 CVE-2008-1887 These are present in 2.5.2 and we should fix them prior to release. I'll look at it. -d
Re: only days left to ports lock (4.4 release)
Hi, On Mon, 28.07.2008 at 17:24:01 -0700, Peter Valchev <[EMAIL PROTECTED]> wrote: > We are in release mode, with 4.4 just around the corner. This means > that from now, no more commits to ports unless they are VERY urgent - > such as fixing a broken dependency, high impact security issue, etc, I'd like to point at some problems in Python 2.5.2, which I became aware of just two days ago: CVE-2007-2052 CVE-2007-4965 CVE-2008-1679 CVE-2008-1721 CVE-2008-1887 The latter two are claimed to result in the execution of arbitrary code. Kind regards, --Toni++
Re: only days left to ports lock (4.4 release)
> We really need the tree to stabilise and ask people to spend their > energy on testing snapshots and finding real bugs at this point. Stability of the ports tree (ie. that all the packages work together correctly) is more important than small niggly fixes to a particular port. That is the major viewpoint to take from this. If people can start testing for stupid errors in the combined ports, and simple solutions that will solve any such problems... that is the ideal path to go. > I want to strongly emphasize that if you have any doubts about whether > to suggest a patch for inclusion, then it can wait until after the > release. In a few days, we'll actually lock the tree (zero commits) > and final release builds will commence. Until then, we want to focus > on showstoppers and not routine changes/additions.
only days left to ports lock (4.4 release)
We are in release mode, with 4.4 just around the corner. This means that from now, no more commits to ports unless they are VERY urgent - such as fixing a broken dependency, high impact security issue, etc, and they must be explicitly approved. Every commit from now on must have an OK by pvalchev@, espie@ or naddy@ - email all 3 of us and describe why you think your patch must make it in the release. If you don't have a strong argument and are hesitant, please just wait until after the release. We really need the tree to stabilise and ask people to spend their energy on testing snapshots and finding real bugs at this point. I want to strongly emphasize that if you have any doubts about whether to suggest a patch for inclusion, then it can wait until after the release. In a few days, we'll actually lock the tree (zero commits) and final release builds will commence. Until then, we want to focus on showstoppers and not routine changes/additions.
