This is a confidential pre-notification of a security alert for xorg/xfree. Please *do not forward* any part of this to anyone or discuss these problems in a public setting. The public announcement is not until Nov 03 2004 14:00 UTC, and we'd like to keep this information embargoed until then. -------------------------------------------------------------------------------- We are asking that the following devs test a patched version of $PN which I will be attaching shortly. And then you devs need to comment here if said ebuild can be put in the tree and marked stable at the same time on $DATE. We are not asking for you to mark any ebuilds as stable or add anything to the tree at this time. Only calling for security testing. -------------------------------------------------------------------------------- From: Thomas Biege <thomas@suse.de> To: vendor-sec@lst.de Cc: Matthieu Herrb <matthieu.herrb@laas.fr>, xorg_security@x.org Subject: [vendor-sec] [matthieu.herrb@laas.fr: Re: libXpm patch] Date: Fri, 8 Oct 2004 09:13:07 +0200 Hello, one of our maintainers found a signed integer problem that was not fixed in the libxpm patch. I contacted Matthieu Herrb about that problem and he told me that even more was wrong. Below is his latest answer. Patch attached. ----- Forwarded message from Matthieu Herrb <matthieu.herrb@laas.fr> ----- Date: Thu, 07 Oct 2004 23:19:30 +0200 From: Matthieu Herrb <matthieu.herrb@laas.fr> User-Agent: Mozilla Thunderbird 0.5 (X11/20040715) To: Thomas Biege <thomas@suse.de> Cc: Matthieu Herrb <matthieu.herrb@laas.fr> Subject: Re: libXpm patch Thomas Biege wrote: >Hello. > >On Wed, Oct 06, 2004 at 11:26:44PM +0200, Matthieu Herrb wrote: > >>Yes, it seems there are 2 places (one in create.c, one in parse.c) in >>libXpm which are vulnerable to this. >>I think the easiest patch is to make char1 an unsigned int. >> >>BTW, I was also made aware that there's a potential memory leak in the >>previous patch, and some people get annoyed by the gcc warnings on 64bit >>arches where the tests for integer overflows are always false. So >>there are a couple of reasons to issue an updated patch. > > >Do you have more details. I would like to make a better patch for >our maintainers. Here are the diffs I currently have, against X.Org's cvs HEAD (which should be the same as R6.8.1 and XFree86 HEAD). The 1st memory leak problem in create.c was reported by Antony Fountain <af@ist.co.uk>. I found the 2nd when looking if the pattern spotted by Anthony could be found at other places. The fixes for LP64 warnings come from Matthias Scheler. -------------------------------------------------------------------------------- Lots of chatter about the patches then today Biege posted some new patches. ... From: Thomas Biege <thomas@suse.de> To: vendor-sec@lst.de@suse.de Subject: [vendor-sec] new libXpm patch Date: Fri, 22 Oct 2004 10:12:36 +0200 Hello, I spent the last days reviewing the libXpm code. The result is attached. (xpm-secfix-thomas.diff, xpm-secfix-imakefile-thomas.diff) RPM-based distributions can apply these patches in the following way: [...] cd extras/Xpm %patch52 -p0 cd ../.. %patch53 -p0 ln -s ../../extras/Xpm/lib/s_popen.c lib/Xpm/s_popen.c [...] (Matthieu Herrb received a copy of this patch yesterday.) The patch is based on XFree86-4.3-branch_03-08-13 code with all known security fixes (including xpm-sec5.diff, which I sent around some days ago) applied. It fixes several integer issues that result in endless loops and buffer overflows. It also fixes a one-byte buffer overflow, stack-based overflows (sprintf(), string functions), replaces popen() with s_popen(), path traversal issues, buffer underruns, memory leaks (missing free(), found by Egbert Eich)... Some issues seem not to be fixable in an easy way, therefore I just commented them. So far we did not make any functional testing based on packages including this patch. Handle it with *care*. With the presence of this patch I would like to push back the next coordinated libXpm release for at least one week (3rd November, 14:00 UTC). Please test it, squeeze it, bash it, improve it! :) Bye, Thomas
Created attachment 42414 [details, diff] xpm-secfix-imakefile-thomas.diff (SuSe) patch #1
Created attachment 42416 [details, diff] xpm-secfix-thomas.diff (SuSe) Patch #2
I'll look at this soon. Looks like I've got a little time, at least (8 days). I'm debating whether to bump 6.8.0 to -r3 from -r1 and to -r4 from -r2 (hard-masked), or to move the current -r2 to -r3, and move -r1 to -r2. Just wanted to give you guys an update.
From: Matthieu Herrb <matthieu.herrb@laas.fr> To: Thomas Biege <thomas@suse.de> Cc: vendor-sec@lst.de, xorg_security@x.org Subject: Re: [vendor-sec] new libXpm patch Date: Sat, 23 Oct 2004 11:50:41 +0200 Thomas Biege wrote: > Hello, > I spent the last days reviewing the libXpm code. > > The result is attached. > (xpm-secfix-thomas.diff, xpm-secfix-imakefile-thomas.diff) [...] > > (Matthieu Herrb received a copy of this patch yesterday.) Hi, sorry for not having aswervered before. I got a really busy week, complicated by a cold. Things are not really better for the coming days, but I'll try to help anyways. I've a few remarks on this patch: * This is missing from xc/lib/Xpm/Imakefile to build libXpm as part of the X tree: --- Imakefile~ Sat Oct 23 10:32:53 2004 +++ Imakefile Sat Oct 23 11:24:29 2004 @@ -105,6 +105,7 @@ LinkSourceFile(Info.c,$(XPMLIBDIR)) LinkSourceFile(RdFToBuf.c,$(XPMLIBDIR)) LinkSourceFile(WrFFrBuf.c,$(XPMLIBDIR)) +LinkSourceFile(s_popen.c,$(XPMLIBDIR)) LinkSourceFile(xpm.h,$(XPMLIBDIR)) * Could you specify the license (MIT or BSD style, GPL is not acceptable for X.Org) to s_popen.c ? * Not all systems supported by X.Org provide snprintf(). Something needs to be done about it. Providing a local XpmSnprintf symbol and using a define snprintf XpmSnprintf on these systems seem the only approach that doensn't break binary compatibility too much. The other approach is to leave those systems in the cold with some potential overflows, normally the code is taking care of providing large enough buffers to sprintf(), except when there's a bug. * You cannot change the PutPixels*() functions prototypes (int x,y -> unsigned int). Although those functions are local, they are used to initialize the members of an XImage (defined in Xlib) structure. I'm not sure if I'll have time over the weekend to prepare a patch for these issues, so anyone feel free to do it. -- Matthieu
But no new patches have been posted.
spyderous: what are your plans about this ? Do you plan to issue a new x.org / xfree with this patch ? Can it be posted here for arch testing before the public release date so that we are not too late ?
Created attachment 42845 [details, diff] xpm-secfix-imakefile-thomas.diff updated patch
Created attachment 42846 [details, diff] xpm-secfix-thomas.diff From: Thomas Biege <thomas@suse.de> To: vendor-sec@lst.de Subject: Re: [vendor-sec] new libXpm patch Date: Tue, 26 Oct 2004 09:29:22 +0200 Hi, attached you can find a new iteration of the patch. The PutPixel*() functions are not changed anymore, symbolic link is not necessary, and some integer overflow test are improved (thanks to Jacques A. Vidrine). Bye, Thomas -- Thomas Biege <thomas@suse.de>, SUSE LINUX AG, Security Support & Auditing Patch seems to be approved by Matthieu Herrb
Plan is to put out an xorg -r3, based on -r1, and an -r4, based on -r2. Also an xfree bump to -r8. (I'm really starting to hate supporting xfree.) I've got no problem posting such ebuilds -- maybe I can get to it later today. But there wasn't a decent patch until a few hours ago to do it with. Only the xorg -r3 and xfree -r8 will need testing -- -r4 will be hard-masked, ~x86 only as -r2 is now.
I thought you were done with xfree. Is it not time to p.mask xfree to begin the removal process?
Supporting xfree til 20050101.
Created attachment 42989 [details, diff] xpm-secfix-thomas.diff, fixed filepaths, 4 rejects Fixed a few things, still have to resolve some rejects -- doesn't apply clean to anything of ours, including xfree 4.3.
Created attachment 42990 [details] xorg-x11-6.7.0-r3.ebuild
Created attachment 42991 [details] xorg-x11-6.8.0-r3.ebuild
Created attachment 42992 [details] xfree-4.3.0-r8.ebuild
BTW, if anyone makes the patch apply before I do, make sure to combine it with the imakefile patch into a patch with the name xpm-secfix-thomas.diff, as that's what the ebuilds expect -- 1 patch.
Created attachment 43077 [details, diff] xpm-sec6.diff From: Matthieu Herrb <matthieu.herrb@laas.fr> To: xorg_security@x.org, vendor-sec@lst.de, Thomas Biege <thomas@suse.de> Subject: [vendor-sec] xpm-sec6.diff Date: Mon, 01 Nov 2004 16:58:01 +0100 Hi, I found an additional problem in Thomas latest patch, in CreateColors in CrDatFrI.c. The attached patch is a compilation of what have been reported so far: - my original xdm-sec5.diff - Thomas patches - the fix for popen->fopen - a license in s_popen.c - reverting the directory traversal patch in OpenReadFile - the fix for the snprintf() buffer size in CrDatFrI.c - support for building a local version on snprintf() on systems that miss it. I'm still pretty buzy with other things these days, so I didn't spend as much time as I would have wanted to test this patch. I hope other people have been runnning their favourite applications with it. -- Matthieu
> I think it's safe to say that 2004-11-03 is going to be a bit premature as > our deadline, I'm thinking we should probably set it for 2004-11-17 now, > since I'm sure there will be more fixes in the very near future. I'd appreciate it if we could push back as well and the 17th suits us. -- Tom --------------------------------------- Changing whiteboard date to the 17th
Huge sigh of relief on that -- this week is crazy for me.
Created attachment 43705 [details, diff] xpm-sec6-1.diff
Just removed a small section that didn't apply -- it contained a comment mentioning Thomas reviewed the code.
Anyone who cares to test, go ahead and save the patch from comment #20 into ${FILESDIR}, named xpm-secfix-thomas.diff, and use the ebuilds from comments #13-15.
Anybody from the security team had a chance to test these?
Calling specific testers for pretesting phase: - lv for amd64 - kloeri for alpha - SeJo for ppc - corsair for ppc64 - fmccor for sparc This is a confidential bug, the ebuilds cannot be published until the release date. We just need you to test and indicate if they look suitable to be committed as stable/~ (same keyword as the current revision) on your arch directly on publication date. Thanks in advance :)
Created attachment 44000 [details] error output while compiling on ppc64. this happens for me on ppc64.
forgot to mention: xorg-x11-6.8.0-r1 works fine here and we want to mark 6.8.0 stable on ppc64 with this -r3.
Preliminary indication for sparc, xorg-x11-6.8.0-r3.ebuild, xpm-sec6-1.diff saved as files/xpm-secfix-thomas.diff: 1. Patch installs, but 2. the file s_popen.c is created in the base ...work/xc directory (xc/s_popen.c) and so the build fails early on: 3. No rule to make target ../../extras/Xpm/lib/s_popen.c Solution to this seems to be: =================================== --- xpm-secfix-thomas.diff- 2004-11-15 17:50:35.000000000 +0000 +++ xpm-secfix-thomas.diff 2004-11-15 17:51:48.000000000 +0000 @@ -1532,7 +1532,7 @@ RCS file: s_popen.c diff -N s_popen.c --- /dev/null Sat Aug 30 18:16:59 1997 -+++ s_popen.c Mon Nov 1 15:50:32 2004 ++++ extras/Xpm/lib/s_popen.c Mon Nov 1 15:50:32 2004 @@ -0,0 +1,181 @@ +/* + * Copyright (C) 2004 The X.Org fundation ==================================================== (At least, with this change, libXpm compiles without problem.) So, with the patch as modified, this looks good so far, but it will take me until Tuesday evening to get a live test: I need to build and install on a system currently running xorg-x11-6.8.0-r1, and a full build/cycle for that will take until then. Preliminary: Patch needs a mod, but with the correct location for s_open.c, libXpm as modified builds without incident.
And, just for your information: When -r2 ==> -r4 comes out, that gets a free test on sparc, because -r2 is mostly what I am running (as modified as described elsewhere), no matter how it is currently masked.
Created attachment 44005 [details, diff] xpm-sec6-2.diff Updated to fix s_popen.c error and prefix all paths with xc/ to ensure epatch works.
I'll be sticking the -r4 in myself after the embargo date -- it's hard-masked, so it can be ignored for the initial security announcement. Three ebuilds to test are enough.
Patch is backwards: Should be extras/Xpm/lib/s_popen.c, not extras/lib/Xpm
Oops, was confusing the quasi-parallel structures in xc/extras/Xpm/lib and xc/lib/Xpm.
For xorg-x11-6.8.0-r3 on sparc, looks good: IF--- 1. Take ebuild as above; 2. Take xpm-sec6-2.diff; 3. Fix xpm-sec6-2.diff as needed to get s_popen.c into the correct directory: =============================================== --- xpm-sec6-2.diff- 2004-11-16 03:26:27.000000000 +0000 +++ xpm-sec6-2.diff 2004-11-16 03:26:52.000000000 +0000 @@ -1532,7 +1532,7 @@ RCS file: s_popen.c diff -N s_popen.c --- /dev/null Sat Aug 30 18:16:59 1997 -+++ xc/extras/lib/Xpm/s_popen.c Mon Nov 1 15:50:32 2004 ++++ xc/extras/Xpm/lib/s_popen.c Mon Nov 1 15:50:32 2004 @@ -0,0 +1,181 @@ +/* + * Copyright (C) 2004 The X.Org fundation =================================== 4. Install xpm-sec6-2.diff as ${FILESDIR}/xpm-secfix-thomas.diff THEN-- 5. Build is clean (For me, with xorg-x11-6.8.0-r[1,3], this means with USE='hardened bitmap-fonts insecure-drivers -doc') 6. Install is clean; 7. Seems to run fine. ( Tue Nov 16 03:19:33 2004 --> x11-base/xorg-x11-6.8.0-r3) At least one application (xosview) claims to be using libXpm, for what that's worth. I verified by looking at the build as it was running that s_popen.c was properly installed and compiled. Beyond that, I cannon comment on the patch. Regards, Ferris
Created attachment 44038 [details, diff] xpm-sec6-3.diff Fixed the stupid mistake. This should be usable as-is.
tested xorg-x11-6.7.0-r3 emerged xosview launched xorg, ran xosview without problems... xorg-x11-6.8.x isn't stable on ppc and will not be stable on ppc untill ati problems are resolved (behn was working on that one?) greetings
Created attachment 44071 [details] patch for xorg-x11-6.8.0-r3 (ppc64) If the ebuild for 6.8.0-r3 gets submittet to portage, can the person who does that please first apply this patch, because thos lines are obsolete in xorg-x11 >=6.8?
For sparc: --- ----- 1. xorg-x11-6.8.0-r3 + xpm-sec6-3.diff builds, installs, and runs (kernel 2.4.xx version and 2.6.xx version). (This message is generated by mozilla under xorg-x11-6.8.0-r3, kernel 2.4.26.) Given the time constraints, extended testing is necessarily limited. Suffice it to say that it seems fine to me. xorg-x11-6.8.0-r3 is good for sparc. 2. xorg-x11-6.7.0-r3 + xpm-sec6-3.diff builds on sparc (SS20) without incident. I am not in a position to test it further, but my guess is that 6.7.0-r2 has never been used on sparc (we went from 6.7.0-r1 to 6.8.0-r1 directly). Based on the fact that 6.7.0-r2 is ~sparc and my inspection of the change, I think that 6.7.0-r3 is good for ~sparc (but not for sparc). 3. xfree has not been supported for sparc for some time, and xfree-4.3.0-r8 must carry on that tradition (of no sparc keyword at all). Summary: xorg-x11-6.8.0-r3 builds & and I am running it on a couple systems; 6.7.0-r3 builds fine. If you need anything more from sparc before going public, please let me know. Regards, Ferris
Status update : lv for amd64 (needs 6.8.0-r3 stable): no news. Calling blubb for pretesting. kloeri for alpha (needs 6.8.0-r3 stable): no news. SeJo for ppc (needs 6.7.0-r3 stable, 6.8.0-r3 ~): confirmed 6.7.0-r3 good for ppc. I suppose 6.8.0-r3 is good for ~ppc corsair for ppc64 (needs 6.7.0-r3 stable and 6.8.0-r3 ~, wants 6.8.0-r3 stable): 6.8.0-r3 is OK with patch from comment #36. fmccor for sparc (needs 6.8.0-r3 stable): confirmed 6.8.0-r3 good for sparc, 6.7.0-r3 good for ~sparc This should be public today. We'll open a new bug to handle the final steps.
All three versions looks good on alpha.
my gcc+glibc are slightly non-gentoo-standard at the moment, so the ebuild would probably require editing (enabling the propolice thing only if symbols are found in libc or libgcc) to compile+work here... i'll make the necessary changes and start compiling before work, and give an update at lunch or after work. another amd64 dev might be able to get to this more quickly, however.
...that took a -lot- less time than i thought it would. 6.8.0-r3 is good to go on amd64. 6.8.0-r1 is already stable on amd64 and we dont have ati drivers, so we dont need to worry about 6.7. also, xfree isnt even keyworded so we dont need to worry about that either.
Ok great.. Are we ready to go live? 1400UTC passed us about 40 mins ago.
If you confirm it's now public, then it's public. Due to confidential nature of some emails here, maybe another bug should be created to handle the remaining chores openly. spyderous should commit the ebuilds to the tree with already-gained arch keywords and we'll call for testing on remaining ones + draft the GLSA.
Bad news. http://sourceforge.net/mailarchive/forum.php?thread_id=5969758&forum_id=7177 SUSE will neithertheless proceed with todays planned release (1400 UTC) if they have not already. The existing code gnetoo code base should be fine and should not prevent us from doing a new release of xorg.
Committed with following KEYWORDS: xorg-x11-6.7.0-r3.ebuild:KEYWORDS="x86 ppc ~sparc alpha" xorg-x11-6.8.0-r3.ebuild:KEYWORDS="x86 ~ppc sparc ppc64 alpha amd64" xfree-4.3.0-r8.ebuild:KEYWORDS="x86 alpha" Please update as necessary.
Ignore the whining about file size of the patch for now. I'll move it into a tarball later.
Ferris, xorg-x11-6.8.0-r4.ebuild:KEYWORDS="~x86" Go ahead and test. To anyone else, -r4 is hard-masked, in development and moves /usr/X11R6/lib to /usr/lib. There are no known problems with it at present, but I'm playing it safe for now.
X.Org just sent out a security advisory to its members on this. Full text follows. The patch doesn't yet seem to exist at the specified locations. X.Org Foundation Security Advisory For X Window System Versions X11R6.8.0 and X11R6.8.1 17 November 2004 - - - - - - - - - - - - - - - - - - - - - Brookline MA, November 17, 2004 - The X.Org Foundation today announced the release of a patch for the X Window System, which addresses the security vulnerability first announced on September 15, 2004, with the release of source patch CAN-2004-0687-0688.patch. X.Org was made aware of additional security vulnerability in libXpm, the X Pixmap library, which is shipped as part of the X Window System. The affected library is used in many popular application for image viewing and manipulation. This library was subject of recent security advisories (CAN-2004-0687 and CAN-2004-0688). 1. Description libXpm is a library for manipulating pixmaps used by the X Window System. After the release of the X11R6.8.1 security release, a more extensive security audit was made. Several integer overflows and out-of-bounds memory accesses have been identified and fixed, a path traversal has been fixed and shell command execution has been made more secure. This new fix also addresses possible endless loops and memory leaks. These vulnerabilities may allow an application linking against libXpm to crash, to become unusable, or to execute other code of a user running an application linked against libXpm. 2. CVE Information The Common Vulnerabilities and Exposures (CVE) project has assigned the name CAN-2004-0914 to these issues. This is a candidate for inclusion in the CVE list (http://cve.mitre.org), which standardizes names for security problems. You may check: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0914 3. Affected versions All X.Org release up to and including R6.8.1 are vulnerable. Products like XFree86, lesstif and OpenMotif, which include libXpm are likely to be affected. 4. Available patch. A source patch is available for: X.Org Release 6.8.0 under: http://www.x.org/pub/X11R6.8.0/patches/xorg-680-CAN-2004-0914.patch and X.Org Release 6.8.1 under: http://www.x.org/pub/X11R6.8.1/patches/xorg-681-CAN-2004-0914.patch and from X.Org mirror sites world-wide. 5. Acknowledgments The X.Org Foundation would like to thank Petr Mladek for identifying the vulnerabilities and providing a patch, and Thomas Biege for systematically reviewing the libXpm code and fixing additional possible vulnerabilities. The X.Org Foundation would also thank Matthieu Herrb and Jacques A. Vidrine for their help in auditing the code, reviewing the patch and suggesting additional fixes.
Re 6.8.0-r4 --- thanks, I'll upgrade and keep testing. On my systems, it is running (as) flawlessly (as X11 can on sparc). Otherwise, I am putting out a heads-up note to sparc@gentoo.org.
Note the mention of lesstif/openmotif in the advisory.
I was just about done with the patches for the X.Org advisory when I received your email. I will integrate this one, rebuild the patches and send them for inclusion on the X.Org web page. Unfortunately the freedesktop site is currently not available for distributing as it was hacked last weekend. I've written an advisory which I will attach for review. Thomas has looked it over and said it was OK. Please check and tell me if you see any issues. Egbert. Matthieu Herrb writes: > Hi, > > I found an additional problem in Thomas latest patch, in CreateColors in > CrDatFrI.c. The attached patch is a compilation of what have been > reported so far: > > - my original xdm-sec5.diff > - Thomas patches > - the fix for popen->fopen > - a license in s_popen.c > - reverting the directory traversal patch in OpenReadFile > - the fix for the snprintf() buffer size in CrDatFrI.c > - support for building a local version on snprintf() on systems that > miss it. > > I'm still pretty buzy with other things these days, so I didn't spend as > much time as I would have wanted to test this patch. I hope other people > have been runnning their favourite applications with it. X.Org Foundation SECURITY ADVISORY ================================== Brookline MA, November 17, 2004 - X.Org has been made aware of additional security vulnerability in libXpm, the X Pixmap library, which is shipped as part of the X Window System. The affected library is used in many popular application for image viewing and manipulation. This library has been subject of recent X.Org security advisories (CAN-2004-0687 and CAN-2004-0688). Several integer overflows and out-of-bounds memory accesses have been identified and fixed, a path traversal has been fixed and shell command execution has been made more secure. Furthermore the fix addresses possible endless loops and memory leaks. These vulnerabilities may allow to crash or make an application linking against libXpm unusable or execute code under the account of the user running an application linked against libXpm. The CVE number for this vulnerabilities is CAN-2004-0914. Please check also: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0914 This advisory affects all known versions and releases of the X Window System shipping versions of libXpm, whether from X.Org or other vendors. Therefore users are strongly recommended to upgrade. A fix is provided for X.Org Release 6.8.0 under: http://www.x.org/pub/X11R6.8.0/patches/xorg-680-CAN-2004-0914.patch and X.Org Release 6.8.1 under: http://www.x.org/pub/X11R6.8.1/patches/xorg-681-CAN-2004-0914.patch The X.Org Foundation would like to thank Petr Mladek for identifying the vulnerabilities and providing a patch, and Thomas Biege for systematically reviewing the libXpm code and fixing additional possible vulnerabilities. The X.Org Foundation would also thank Matthieu Herrb and Jacques A. Vidrine for reviewing the patch and suggesting additional fixes.
Solar, could you please update xpm-secfix-thomas.diff in xfree and xorg-x11 FILESDIR to reflect that and test to make sure it patches cleanly? I'm at work now, so I won't be able to do much for about 8 hours.
http://www.x.org/pub/X11R6.8.1/patches/xorg-681-CAN-2004-0914.patch now exists.
Nevermind that, solar. It sounds like we've already got that fix, since it was posted here earlier: comment #17.
I see that SuSE and Ubuntu, at least, have gone ahead with announcing this. Is there anything still holding us back?
Created public bug to handle the last remaining tasks. Thanks everyone, please followup on bug 71642 if you need.
