X Strike Force XFree86 SVN commit: r2042 - in trunk/debian: . patches
Author: branden
Date: 2004-12-02 21:46:41 -0500 (Thu, 02 Dec 2004)
New Revision: 2042
Modified:
trunk/debian/CHANGESETS
trunk/debian/changelog
trunk/debian/patches/087_SECURITY_libXpm_vulnerabilities.diff
Log:
Update patch annotation to describe fixes to CAN-2004-0914.
Add changelog entry for CAN-2004-0914 security fix, and increment upload
urgency to high.
Modified: trunk/debian/CHANGESETS
===================================================================
--- trunk/debian/CHANGESETS 2004-12-03 02:39:58 UTC (rev 2041)
+++ trunk/debian/CHANGESETS 2004-12-03 02:46:41 UTC (rev 2042)
@@ -317,7 +317,7 @@
Update debian/patches/087_SECURITY_libXpm_vulnerabilities.diff to include
the latest security fixes and rediff 200_alpha_xpm_get_long64.diff.
- 2035
+ 2035, 2042
Sync debian/rules install-server target with install and make binary-server
target work again.
Modified: trunk/debian/changelog
===================================================================
--- trunk/debian/changelog 2004-12-03 02:39:58 UTC (rev 2041)
+++ trunk/debian/changelog 2004-12-03 02:46:41 UTC (rev 2042)
@@ -1,5 +1,8 @@
-xfree86 (4.3.0.dfsg.1-8+SVN) unstable; urgency=low
+xfree86 (4.3.0.dfsg.1-8+SVN) unstable; urgency=high
+ * Security update release. Resolves CAN-2004-0914 (several Xpm library
+ vulnerabilities).
+
Changes by Branden Robinson:
* Update Danish debconf template translations (thanks, Claus Hindsgaul).
@@ -274,8 +277,14 @@
* Sync debian/rules install-server target with install and make
binary-server work again.
- -- Branden Robinson <branden@debian.org> Wed, 17 Nov 2004 18:00:21 -0500
+ Changes by Fabio M. Di Nitto and Branden Robinson:
+ * Update patch #087 to include fruits of Xpm source code security audit by
+ Thomas Beige. Resolves CAN-2004-0914: memory leak, improper use of signed
+ integers, and overflows in the Xpm library. Resync offset in patch #200.
+
+ -- Branden Robinson <branden@debian.org> Thu, 2 Dec 2004 21:43:03 -0500
+
xfree86 (4.3.0.dfsg.1-8) unstable; urgency=high
Changes by Denis Barbier:
Modified: trunk/debian/patches/087_SECURITY_libXpm_vulnerabilities.diff
===================================================================
--- trunk/debian/patches/087_SECURITY_libXpm_vulnerabilities.diff 2004-12-03 02:39:58 UTC (rev 2041)
+++ trunk/debian/patches/087_SECURITY_libXpm_vulnerabilities.diff 2004-12-03 02:46:41 UTC (rev 2042)
@@ -1,7 +1,8 @@
$Id$
Fix several security flaws in the Xpm library. Resolves CAN-2004-0687 (libXpm
-stack overflows) and CAN-2004-0688 (libXpm integer overflows).
+stack overflows), CAN-2004-0688 (libXpm integer overflows), and
+CAN-2004-0914 (more integer overflows).
The following text is by Chris Evans.
@@ -60,8 +61,60 @@
8192 bytes). The user gets to choose how many bytes to put into this
buffer via the "number of bytes per pixel" XPM value.
-This patch by Matthieu Herrb.
+The discovery of the above flaws prompted a code review of the Xpm library
+by Thomas Biege and several more fixes, including:
+* More rigorously declare variables as unsigned integers where appropriate.
+* Compare user-supplied image data to UINT_MAX, not SIZE_MAX, when the
+ internal corresponding variable used is an unsigned integer. (This is
+ also more correct on LP64 systems.)
+* Add checks for invalid negative values in user-supplied image data.
+* Change internal functions WritePixels(), WriteExtensions(),
+ CreatePixels(), and CreateExtensions() to take an additional argument,
+ data_size, to avoid buffer overflows (making the functions less like
+ sprintf and more like snprintf). Update calls to these functions
+ accordingly.
+* Make macro definitions of compound statements more correct (see Section
+ 3.10.3, "Swallowing the Semicolon", of the GNU C Preprocessor Manual).
+* Add checks for user-supplied data causing integer overflows when summed
+ together.
+* Add tons of checks for integer overflows generally; even user-data that
+ is legal can become implausible after internal routines manipualte it;
+ return an out-of-memory condition if an overflow is thus caused.
+* Use snprintf() instead of sprintf() to avoid buffer overflows.
+* Don't be fooled by XPM images whose image geometry is absurdly huge.
+* Initialize static buffers with a null byte to prevent string-copying
+ routines from going haywire if the buffers are never populated.
+* Change some internal functions to return unsigned ints rather than ints.
+* Add checks for invalid out-of-bounds values in user-supplied data.
+* Provide private implementation of popen(), intended to be secure, called
+ s_popen(). If the system does not define NO_ZPIPE (only Win32 systems
+ do define it), this is used; otherwise, the system's popen() call is
+ used. Use fclose() instead of pclose() on the file handle thus created.
+* Use correct data type for size field of a stat structure, instead of
+ casting it to an int.
+* Use size_t for variables assigned the return value of strlen, not int.
+* Do not attempt to open image files that have zero-length filenames, or
+ are directories.
+* Use initializers with static character arrays so that they begin with a
+ null byte if not later reassigned.
+* Use strncpy() instead of strcpy() to avoid buffer overflows.
+* Set the final byte of a static character array to null after
+ copying another string into it with strncpy().
+* When opening an image file for writing, do not open a file specification
+ that is zero-length, begins or ends with '/', or has '../' anywhere
+ within it.
+* Use XDestroyImage() and XpmFree() to deallocate resources when bailing
+ out during certain error conditions.
+* Add many comments suggesting possibilities for further code review and
+ development.
+
+Petr Mladek was also responsible for some of the above changes. The
+vulnerabilties found during the above-mentioned source code audit are
+collectively referred to as CAN-2004-0914.
+
+This patch by Matthieu Herrb and others.
+
diff -urN xc-old/extras/Xpm/lib/Attrib.c xc/extras/Xpm/lib/Attrib.c
--- xc-old/extras/Xpm/lib/Attrib.c 1999-01-11 13:23:09.000000000 +0000
+++ xc/extras/Xpm/lib/Attrib.c 2004-11-19 10:54:10.000000000 +0000
Reply to: