Bugzilla – Bug 49296
VUL-0: CVE-2004-0084: XFree: >= 3.0 buffer overflow to gain local root
Last modified: 2021-10-02 08:57:15 UTC
Hi Stefan, iDEFENSE reported a bufer overflow in XFree86 that leads to local root. I will attach the emails and patchinfo files ASAP.
<!-- SBZ_reproduce --> -
Created attachment 15852 [details] emails
Created attachment 15853 [details] dirfile.diff the attachement
Created attachment 15854 [details] patchinfo-box.xfree
Created attachment 15856 [details] patchinfo.xfree
Created attachment 15857 [details] patchinfo.xf86
Created attachment 15858 [details] patchinfo-box.xf86
Were you able to reproduce the security problem with the mentioned exploit? I can't.
I can't get the Xserver crashing. The according line in fonts.alias simply does not work. For example: /usr/X11R6/lib/X11/fonts/misc/fonts.alias: [...] 5x7 <the string mentioned in the exploit (more than 1024 chars)> sndirsch@shannon:~> xset fp rehash sndirsch@shannon:~> xterm -fn "5x7" xterm: unable to open font "5x7", trying "fixed".... Then I restored original fonts.alias file sndirsch@shannon:~> xset fp rehash sndirsch@shannon:~> xterm -fn "5x7" (works fine)
Yes I can. open@Lothlorien:~> uname -a Linux Lothlorien 2.4.21-186-default #1 Sat Jan 31 17:19:10 UTC 2004 i686 i686 i386 GNU/Linux open@Lothlorien:~> cat /etc/SuSE-release SuSE Linux 9.0 (i586) VERSION = 9.0 open@Lothlorien:~> rpm -q XFree86 XFree86-4.3.0.1-43 open@Lothlorien:~> open@Lothlorien:~> X :1 -fp $PWD This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to XFree86@XFree86.Org and patches submitted to fixes@XFree86.Org. Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs). XFree86 Version 4.3.0.1 Release Date: 9 May 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: SuSE Linux [ELF] SuSE Build Date: 02 October 2003 Before reporting problems, check http://www.XFree86.Org/ to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/XFree86.1.log", Time: Wed Feb 4 10:52:39 2004 (==) Using config file: "/etc/X11/XF86Config" *** If unresolved symbols were reported above, they might not *** be the reason for the server aborting. Fatal server error: Caught signal 11. Server aborting When reporting a problem related to a server crash, please send the full server output, not just the last messages. This can be found in the log file "/var/log/XFree86.1.log". Please report problems to http://www.suse.de/feedback. Abgebrochen
What have you done before? What about the fonts, fonts.dir and fonts.alias in $PWD?
Just as described in the mail. I'll attach them.
Created attachment 15860 [details] fonts.alias
Created attachment 15861 [details] fonts.dir
Sorry, but this cannot work, what you're doing. The font is probably missing the fixed and cursor alias are missing and so on. And this is what I get: $ X :1 -fp $PWD This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to XFree86@XFree86.Org and patches submitted to fixes@XFree86.Org. Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs). XFree86 Version 4.3.99.902 (4.4.0 RC 2) Release Date: 18 December 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: SuSE Linux [ELF] SuSE Current Operating System: Linux shannon 2.6.1-5-default #1 Fri Jan 30 17:50:49 U TC 2004 i686 Build Date: 01 February 2004 Changelog Date: 27 January 2004 Before reporting problems, check http://www.XFree86.Org/ to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/XFree86.1.log", Time: Wed Feb 4 13:08:29 2004 (==) Using config file: "/etc/X11/XF86Config" (EE) Failed to load module "rfbmouse" (module does not exist, 0) (EE) Failed to load module "rfbkeyb" (module does not exist, 0) (II) Initializing extension GLX Could not init font path element /suse/sndirsch/tmp, removing from list! Fatal server error: could not open default font 'fixed'
1.) it is not designed to work, it is designed to create a SEGV, and that does work 2.) you use a very different XFree86 version (4.3.99.902 vs. 4.3.0.1) If we use 4.3.99.902 in STABLE then it seems to be fixed there, but 4.3.0.1 is the official version from SL9.0 (and I bet a beer that older version are affected too)
This is surprising as the security fix is not yet in our STABLE XFree86 version. Indeed, it happens on a SuSE 9.0 system. Just checked. Looks like the security bug was fixed by accident in CVS. :-)
If the code is still in there we should fix it too. Maybe due to some more sanity checks this dirty example didn't get to the vulnerable code.
Yes, I think so. I'll wait until David commited the patch.
You mean David Dawes <dawes@XFree86.Org>, right? At the moment this bug is private till iDEFENSE mades it public. Nevertheless, waiting for an official patch in their CVS is too late to be ready for a coordinate release. The patch is simple: switch (token) { case NAME: - strcpy(alias, lexToken); + strncpy(alias, lexToken, sizeof(alias)-1); + alias[sizeof(alias)-1] = '\0'; Or are there more strcpy's and strcat's in the code?
I want to avoid using another patch than in XFree86 4.4.0. BTW, you've sent me another patch. I don't think we're in a hurry now. Testing and approving the update will need some weeks as usual anyway. Index: dirfile.c =================================================================== RCS file: /home/x-cvs/xc/lib/font/fontfile/dirfile.c,v retrieving revision 3.16 diff -u -r3.16 dirfile.c --- dirfile.c 7 Apr 2003 16:23:31 -0000 3.16 +++ dirfile.c 4 Feb 2004 00:19:49 -0000 @@ -291,6 +291,10 @@ status = AllocError; break; case NAME: + if (strlen(lexToken) >= sizeof(alias)) { + status = BadFontPath; + break; + } strcpy(alias, lexToken); token = lexAlias(file, &lexToken); switch (token) {
Ah yes. Use this one. If you submit the packages fast, the QA team can start testing early and we have the packages ready for the coordinate release date. We really should meet this date to avoid bad press.
My update plan: Sources /work/src/done/<dir> ----------------------------------------------------------------------- /work/SRC/old-versions/7.2/all/xf86 SLES7 /work/SRC/old-versions/7.2/arch/s390/xf86 ??? (7.2-s390) /work/SRC/old-versions/7.2/arch/sles-s390x/xf86 SLES7-s390x /work/SRC/old-versions/7.3/arch/ppc/xf86 SLES7-PPC /work/SRC/old-versions/8.0/all/xf86 8.0 /work/SRC/old-versions/8.1/UL/all/xf86 8.1 /work/SRC/old-versions/8.1/SLEC/all/XFree86 SLEC /work/SRC/old-versions/8.2/all/XFree86 8.2 /work/SRC/old-versions/9.0/all/XFree86 9.0
There is no common setuid/setgid Xserver for s390/s390x available as these beasts don't have any graphics hardware. I need to adjust the patchinfo files for this. Here's my new udpate plan. Sources /work/src/done/<dir> ----------------------------------------------------------------------- /work/SRC/old-versions/7.2/all/xf86 SLES7 /work/SRC/old-versions/7.3/arch/ppc/xf86 SLES7-PPC /work/SRC/old-versions/8.0/all/xf86 8.0 /work/SRC/old-versions/8.1/UL/all/xf86 8.1 /work/SRC/old-versions/8.1/SLEC/all/XFree86 SLEC /work/SRC/old-versions/8.2/all/XFree86 8.2 /work/SRC/old-versions/9.0/all/XFree86 9.0
*scratch chin* So s390 dont have a X server at all, right?
Only "virtual" Xservers like Xvfb, Xnest, Xvnc. :-)
Do they run with root privileges?
No. It isn't required as they don't access any hardware.
Ah ok. :)
Fixed. Updated packages are now below /work/src/done (see comment #24) and patchfiles in /work/src/done/PATCHINFO. Assigning to Thomas now, so he cares about that the security update will be tested and (hopefully) approved.
Thanks Stefan! note: CAN-2004-0083
another note for me: CAN-2004-0084
David found a new bug in dirfile. I'll attach the diff and reject the packages. :(
Created attachment 15925 [details] dirfile2.diff
Looks like we still can use the same changelog for the package and the same description for the patchinfo. I just will append the new patch to the old one therefore.
Ok. Can you add a newline or space to the old patchinfos to get a new MD5 sum. It will improve the ability to track this new one.
I'll replace font.alias with fonts.alias in the description. :-) font.alias is simply wrong.
*sigh* David reported more problem in dirfile... *grrml* I will not reject the packages that are currently in autobuild and will do a audit of dirfile on my own today.
# /suse/bin/tel sndirsch [...] Vacation : Mi 11.02. - Fr 13.02. I'll be back on monday.
Ok, it looks like I need to reject the packages again. *sigh* I will be back with a quick source code review of directory xc/lib/font/fontfile
Created attachment 15938 [details] dirfile.c.diff includes all three bugfixes
Created attachment 15939 [details] fontfile.c.diff includes some more sanity checks
patch makes problems: fontfile.c: In function `FontFileOpenBitmapNCF': fontfile.c:504: error: `scalable' undeclared (first use in this function) fontfile.c:504: error: (Each undeclared identifier is reported only once fontfile.c:504: error: for each function it appears in.) fontfile.c: In function `FontFileGetInfoBitmap': fontfile.c:538: error: `scalable' undeclared (first use in this function) Will submit packages tomorrow...
Created attachment 15947 [details] fontfile-sec_bufferoverflows.diff hopefully final patch
submitted: - 8.0 - 8.1 - 8.2 - 9.0 - SLES8 - SLES7 - SLES7-PPC ------------------------------------------------------------------- Thu Feb 12 11:52:46 CET 2004 - thomas@suse.de - fixed more buffer overflows in fontfile/ direc (#34296) - put together old and new bugs in fontfile-sec_bufferoverflows.diff
What about SLEC sources? BTW, 8.1 and SLES8 sources are exactly the same.
Will submit SLEC packages in a few minutes.
Date: Sat, 14 Feb 2004 08:58:09 +0000 (GMT) From: Dr Andrew C Aitchison <A.C.Aitchison@dpmms.cam.ac.uk> To: iDefense Labs <labs@iDefense.com> Cc: bugs@securitytracker.com, bugtraq@securityfocus.com Subject: Re: iDEFENSESecurityAdvisory02.10.04: XFree86FontInformationFileBufferOverflow On Tue, 10 Feb 2004, iDefense Labs wrote: > - - - From XFree86-4.2.1/xc/lib/font/fontfile/dirfile.c: > > ReadFontAlias(char *directory, Bool isFile, FontDirectoryPtr *pdir) > { > char alias[MAXFONTNAMELEN]; > switch (token) { > case NAME: > strcpy(alias, lexToken); > > If lexToken is longer than MAXFONTNAMELEN (1024 chars) an overflow > occurs. I note that this code also ocurs in Xvnc, and that ReadFontAlias is essentially unchanged in XFree86 CVS since version 1.1, which has the CVS id string /* $XConsortium: dirfile.c,v 1.11 94/04/17 20:17:01 gildea Exp $ */ I would expect that X servers from many vendors have the same vunerablility. -- Dr. Andrew C. AitchisonComputer Officer, DPMMS, Cambridge A.C.Aitchison@dpmms.cam.ac.uk http://www.dpmms.cam.ac.uk/~werdna
I think Andrew is speaking of XFree86 3.x based Xvnc servers. We use xf4vnc since SuSE 9.0, which uses the same font library as the XFree86 server.
packages approved.
<!-- SBZ_reopen -->Reopened by thomas@suse.de at Wed Feb 25 10:44:27 2004
We got reports that this issue is NOT FIXED. :-( I'll check this today.
Date: Tue, 24 Feb 2004 22:41:15 +0100 From: Frank Steiner <fst@bio.informatik.uni-muenchen.de> To: Thomas Biege <thomas@suse.de> Cc: suse-security@suse.de Subject: Re: [suse-security] SUSE Security Announcement: xf86/XFree86 (SuSE-SA:2004:006) Hi, Thomas Biege wrote: > Hm, did you restart the X server? Yes, even rebooted the PC to avoid any caching effect. > Does this even happen as non-root user? yes, same effect. > > > Fatal server error: > > Caught signal 4. Server aborting > > The original bug triggered a SIGSEGV (11) this one is a SIGILL (4). > Maybe it triggered just another bug. I'll verify the sources... Actually, rebooting the PC changed the signal to 11 again... It also happens on our SuSE 9.0 PCs with the updated XFree86 (as root and as any other user). And the signal is indeed caused by the font files: riemann /root# rpm -q --changelog XFree86 |head -n 5 * Thu Feb 12 2004 - thomas@suse.de - fixed more buffer overflows in fontfile/ direc (#34296) - put together old and new bugs in fontfile-sec_bufferoverflows.diff riemann /root/tmp# strace -f X :0 -fp $PWD : : open("/root/tmp/fonts.dir", O_RDONLY) = 7 fstat64(7, {st_mode=S_IFREG|0644, st_size=75, ...}) = 0 fstat64(7, {st_mode=S_IFREG|0644, st_size=75, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40022000 read(7, "1\nword.bdf -misc-fixed-medium-r-"..., 4096) = 75 read(7, "", 4096) = 0 read(7, "", 4096) = 0 close(7) = 0 munmap(0x40022000, 4096) = 0 open("/root/tmp/fonts.alias", O_RDONLY) = 7 fstat64(7, {st_mode=S_IFREG|0644, st_size=1121, ...}) = 0 fstat64(7, {st_mode=S_IFREG|0644, st_size=1121, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40022000 read(7, "00000000000000000000000000000000"..., 4096) = 1121 close(7) = 0 munmap(0x40022000, 4096) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- rt_sigaction(SIGSEGV, {SIG_IGN}, {0x8084330, [SEGV], SA_RESTORER|SA_RESTART, 0x4009caa8}, 8) = 0 ... Any more information I can send to help track down the problem (full strace, XF8Config etc.)? cu, Frank -- Dipl.-Inform. Frank Steiner mailto:fst_at_bio.informatik.uni-muenchen.de Lehrstuhl f. Bioinformatik
Sure, that XFree86-server package was updated by YOU?
Does this make a difference? I did via YOU for 9.0 and I got SIGILL ltrace -S output attached
Sure. It's a Xserver bug. Therefore XFree86-server package must be updated. SIGILL ist totally strange.
Created attachment 16168 [details] XFree86.1.log
Created attachment 16169 [details] x.ltrc.gz
buffer overflows trigger SEGVs as well as SIGILLs.
I'm still waiting for the answer of my question in comment #55.
Yes Sir! Just see comment #56, Sir!
An update was published for the package XFree86, but not for XFree86-server. This means that the package provided does not fix the problem. We need patchinfo files for the XFree86-server package. Shouldn't happen... R.
Ok, more news on this: Both the XFree86 base packages AND the XFree86-server packages have been copied to the ftp server, but the patchfile will only have the XFree86 package installed, leaving XFree86-server where it is. Is this a failure on behalf of patchinfo? Added ro@ and kukuk@ to Cc:. Roman.
for clarification: comment #64 refers to SL8.2 and 9.0. The respective 8.1 and 8.0 packages are named xloader, which are not on the ftp server either.
I'm turning in new patchinfo files now.
My fault to trust the patchinfo files I've got. We need to update XFree86-server/xloader package as well. Oops! What I forgot completely, we need to warn the nvidia users, that they need to reinstall ther driver, because during the update of XFree86-server package, the nvidia driver needs to be uninstalled. Where can I find the latest patchinfo files for the update, so I can provide new patchinfo files with this information?
~draht/Export/{XF,xl}* These two are referring to boxpatchinfo only, not the maintained products. I have just made them. Of course, the xloader package (or the XFree86-server package, respectively) must be mentioned there. The packages provided for download are useless with respect to this bug. What the maintained products is concerned, the text could be a little bit more descriptive. There used to be ------------------------------------------------ DISTRIBUTION: sles8-slec-i386 PACKAGE: XFree86 PACKAGER: sndirsch@suse.de CATEGORY: security INDICATIONS: Everyone using X should update. CONTRAINDICATIONS: CD-Produkt-Name: CD-Produkt-Version: REQUIRES: DESCRIPTION: A buffer overflow in the X server can be triggered by using a malformed fonts.alias file. This bug can be used to gain local root privilege. ------------------------------------------------ DISTRIBUTION: sles7-i386,sles7-ia64,sles7-ppc,sles8-i386,sles8-ppc,ul1-i386,ul1-ia64,ul1-x86_64 PACKAGE: xf86 PACKAGER: sndirsch@suse.de CATEGORY: security INDICATIONS: Everyone using X should update. CONTRAINDICATIONS: CD-Produkt-Name: CD-Produkt-Version: REQUIRES: DESCRIPTION: Security Fix: A buffer overflow in the X server can be triggered by using a malformed fonts.alias file. This bug can be used to gain local root privilege. -------------------------------------------------- DISTRIBUTION: 8.0-i386,8.1-i386 PACKAGE: xf86 PACKAGER: sndirsch@suse.de CATEGORY: security DESCRIPTION: Security Fix: A buffer overflow in the X server can be triggered by using a malformed fonts.alias file. This bug can be used to gain local root privilege. DESCRIPTION_DE: Sicherheits-Update: Durch eine spezielle "fonts.alias"-Datei kann ein Speicherueberlauf im X-Server ausgenutzt werden, um lokal root-Rechte zu erlangen. ------------------------------------------------a483a54ee5ada247095dea0b798871fd/patchinfo
We should fix the tmp races that still exists in the RPM postinstall script and in /etc/X11/xdm/Xsession with this update too. And yes. The strace output shows that the update package lacks the patch.
Never heard of any tmp races in /etc/X11/xdm/Xsession. Can you give me some more details or even a patch for this? Fixing tmp races in postinstall scripts needs some testing and it's unlikely that I find the time for this now. About testing, I've got the impression that the udpates weren't tested by our test team at all. Otherwise we would have seen the problem with the missing XFree86-server packge in patchinfo file a long time ago ...
Roman, the files ~draht/Export/{XF,xl}* seem to have wrong permissions. I can't read them.
postinstall: bug 49253 The other thingy is new and seems to be harder to fix. I try to provide you with a patch within the next hour.
Created attachment 16180 [details] Xsession.diff Easier then first thought. But check this please.
Stefan: permissions fixed. The postinstall issue: mktemp only creates a filename for a temporary file, it doesn't create the file. The resulting race is existent, but the potential is considerably small. It can be fixed by changing tmpfile=`mktemp /tmp/XF86Config.XXXXXXXXXX` to read tmpfile=`mktemp /root/XF86Config.XXXXXXXXXX` The Xsession issue: Currently it looks like: : ${TMPDIR=/tmp} for errfile in "$HOME/.xsession-errors" \ "$TMPDIR/xses-$USER" \ "/tmp/xses-$USER" do # # Avoid bad symbolic links # case "$errfile" in /tmp/*|$TMPDIR/*) rm -f $errfile ;; esac if (> "$errfile") 2> /dev/null ; then chmod 0600 "$errfile" exec > "$errfile" 2>&1 break fi done ------- snip --------------- This doesn't avoid anything. The gap between removing the file in /tmp and creating it again may be large enough to place a symlink in there. The suggestion is to remove the lines that contain /tmp, to make it look like this: errfile=$HOME/.xsession-errors if (> "$errfile") 2> /dev/null ; then chmod 0600 "$errfile" exec > "$errfile" 2>&1 else logger -s -p user.err "$0: $errfile is not writeable" fi --------- snip ---------------- rationale: If the HOME directory isn't writeable by the script (which runs as the authenticated user after xdm login), then we have a whole set of different oddities (such as .Xauthority file writing and such) so that it doesn't make sense any more to write the file in the first place. Roman.
Sorry, thomas, I have overridden your comment, I was too fast with the mouse.
mktemp does create the files securely. that's why the patch in comment #73 shall suffice.
Due to overload and _missing testcases_ for the packages inside PDB, there was only done a basic testing. This isn't an excuse - but don't blame QA by finger pointing! In my opinion we are all guilty- QA, Security-Team and the package-maintainer as well me as maintenance coordinator. As long as we are humans, we will make mistakes and we will make more mistakes if we are overloaded and we will make more mistakes if we are disappointed. Finger pointing is a important source for disappointment!
The "guilty" thing hasn't been an issue... Thomas and I are aware of the fact that it was our fault, because the package names were just plain wrong. :-/ Shit happens.
It was meant more this way. Does it make sense to try to fix additional security problem (tmp races), when the test team doesn't have the time to test it anyway ...
I think making mistakes is normal, but showing them to the public is stupid... or let's call it painful. :) Maybe we should install more measurements in the update process to catch simple mistakes made due to precipitance or by the lack of experience. I submitted the packages a second time because a patch was missing and Stafan was not available, and I was not aware of this package separation. To quote Roman: Shit Happens. :) QA is the best/logical part of the update process to hook such measurements, unfortunately these guys are already overloaded.
Stefan, it's always worth trying to fix it. We should stay thinking positive. ;) BTW, the QA-Team always does YOU install tests, therefore problems with the postinstall changes should be recognized. But we have no testing for box products just for maintained products...
Update: We can't afford the rebuild of all packages that depend on XFree86 (information from Thorsten). By consequence, we will have to get the tmpfile fixes checked in on another day asap, but we can't wait for them today. Means: we will provide the XFree86-server and xloader packages via (box) patchinfo today, without any further package check-in or tests. Roman.
Affirmative.
I think I have the new patchinfo files ready. Unfortunately check_patchinfo don't like them. :-( --> ~sndirsch/pkgs/XFree86.bug34296 # /work/src/bin/check_patchinfo patchinfo.XFree86-server.slec PRE has trailing space(s) Bad Line: Please note that users of the NVIDIA driver need to reinstall it after Bad Line: updating the package. Please follow the instructions in our NVIDIA Bad Line: Installer HOWTO, which can be found at the URL Bad Line: "http://www.suse.de/~sndirsch/nvidia-installer-HOWTO.html". Please fix your patchinfo file! # /work/src/bin/check_patchinfo patchinfo.XFree86-server.box PRE has trailing space(s) Bad Line: Please note that users of the NVIDIA driver need to reinstall it after Bad Line: updating the package. Please follow the instructions in our NVIDIA Bad Line: Installer HOWTO, which can be found at the URL Bad Line: "http://www.suse.de/~sndirsch/nvidia-installer-HOWTO.html". Bad Line: Beachten Sie bitte, dass Benutzer des NVIDIA Treibers diesen nach dem Bad Line: Update des Paketes neu installieren müssen. Befolgen Sie dazu bitte Bad Line: die Anweisungen in unserem NVIDIA Installer HOWTO (englisch), das Sie Bad Line: unter der folgenden URL finden. Bad Line: "http://www.suse.de/~sndirsch/nvidia-installer-HOWTO.html". Please fix your patchinfo file!
Created attachment 16183 [details] patchinfo.XFree86-server.box
Created attachment 16184 [details] patchinfo.XFree86-server.slec
The complete text in one line. Cool. I've updated my files in ~sndirsch/pkgs/XFree86.bug34296
I copied the patchinfo files to /work/src/done/PATCHINFO. I'll take care about the tmp races in RPM post scripts and /etc/X11/xdm/Xsession in Bug 49253. Assigning bug now back to Thomas to take care about this now.
The update packages are available via YOU and our ftp server, don't they? What about closing this bugreport as fixed now?
SLES and SLEC is still in QA queue.
packages approved (YOU only test).
CVE-2004-0084: CVSS v2 Base Score: 10.0 (AV:N/AC:L/Au:N/C:C/I:C/A:C)