Enigmail: Decrypted message; UNTRUSTED Good signature from CERT Coordination Center subject: Re: Vulnerability Notification [VU#203220] from: CERT Coordination Center date: 14:39 to: Matthieu Herrb cc: CERT Coordination Center Hello Matthieu, you wrote: > > much of an inconvenience for you. An alternative to generating a new > > key is to simply add an encryption subkey to your current PGP key > > ("gpg --edit-key" then "addkey") and resend/reupload it. > > I've done that. Hope it works. It appears to have worked. Thanks for accomodating this request. Back to the problem at hand... We received a report of a buffer overflow vulnerability in the X.Org server's PCF font handler. Included at the bottom of this message is a copy of the original report and a proof-of-concept exploit. We have confirmed that this pcf file does indeed crash the X server on a system running a current X.Org distribution (xenocara in OpenBSD-current). The reporter also states that a similar bug may affect other font handlers but he hasn't investigated and we have not either. We are tracking this issue as VU#203220. Note that we have not yet established a schedule for publication and we have not yet contacted X redistributors; we would like to have an official X.Org fix available before we do so. We would appreciate it if you would *not* release fixes or details about this issue until we've had a chance to notify downstream vendors about the fix. If you have any questions or concerns, please don't hesitate to contact us. Also, I apologize for sending this to you directly but we do not currently have PGP established for anyone else at X.Org. If there is a more appropriate point of contact for reporting X.Org security issues, please let me know. We're aware of the xorg_security@x.org role but we were reluctant to send this message to that address in cleartext in the event it went to a public list or a large number of receipients. Best Regards, Chad -- Chad Dougherty Vulnerability Analysis Team __________________________________________________________ CERT(R) Coordination Center | cert@cert.org Software Engineering Institute | Hotline : +1 412.268.7090 Carnegie Mellon University | FAX : +1 412.268.6989 Pittsburgh, PA 15213-3890 | http://www.cert.org/ ========================================================== CERT and CERT Coordination Center are registered in the U.S. Patent and Trademark Office. The Software Engineering Institute is sponsored by the U.S. Department of Defense. ----- BEGIN ORIGINAL VULNERABILITY REPORT ----- [Title] Buffer Overflow Vulnerability of X.Org X Window System [Reporter Related Information] - Reporter information can be distributable to vendors - The reporter requests to add the acknowledgment in advisories when disclosed - Takuya Shiozaki, tshiozak@bsdclub.org member of CodeBlog (http://www.codeblog.org/) [Vulnerability Information] - This vulnerability was found by the reporter - Application Name: X11R6.9.0 (the reporter built and executed on NetBSD/i386 3.99.22) - Description: There is a buffer overrun vulnerability within X server process, which may crash the X server, and any code may be executed in the X server privilege. This issue can be exploited using a crafted PCF font, where the difference between "last col" and "first col" of PCF_BDF_ENCODINGS table, is more than 255. When the server opens this font, buffer overrun occurs. bdftopcf command doesn't output such an "illegal" font file; you must use some binary editor to create such a font. [Possible Impacts] - Denial-of-Service attacks from X clients - any code can be executed on X server privilege [Possible Workarounds] The reporter proposes the following two things; 1. fixing PCF font handler add some code to verify the difference between pFont->info.lastCol and pFont->info.firstCol not more than 255. (pcfReadFont() in xc/lib/font/bitmap/pcfread.c) 554 /* encoding */ 555 556 if (!pcfSeekToType(file, tables, ntables, PCF_BDF_ENCODINGS, &format, &size)) 557 goto Bail; 558 format = pcfGetLSB32(file); 559 if (!PCF_FORMAT_MATCH(format, PCF_DEFAULT_FORMAT)) 560 goto Bail; 561 562 pFont->info.firstCol = pcfGetINT16(file, format); 563 pFont->info.lastCol = pcfGetINT16(file, format); 564 pFont->info.firstRow = pcfGetINT16(file, format); 565 pFont->info.lastRow = pcfGetINT16(file, format); 566 pFont->info.defaultCh = pcfGetINT16(file, format); 567 if (IS_EOF(file)) goto Bail; 568 (pcfReadFontInfo()) 692 /* encoding */ 693 694 if (!pcfSeekToType(file, tables, ntables, PCF_BDF_ENCODINGS, &format, &size)) 695 goto Bail; 696 format = pcfGetLSB32(file); 697 if (!PCF_FORMAT_MATCH(format, PCF_DEFAULT_FORMAT)) 698 goto Bail; 699 700 pFontInfo->firstCol = pcfGetINT16(file, format); 701 pFontInfo->lastCol = pcfGetINT16(file, format); 702 pFontInfo->firstRow = pcfGetINT16(file, format); 703 pFontInfo->lastRow = pcfGetINT16(file, format); 704 pFontInfo->defaultCh = pcfGetINT16(file, format); 705 if (IS_EOF(file)) goto Bail; 706 The following check code should be at line 568 and line 706: 568 if (pFont->info.lastCol-pFont->info.firstCol > 255) goto Bail; 706 if (pFontInfo.lastCol-pFontInfo.firstCol > 255) goto Bail; (you may need to assert lastCol>=firstCol and lastRow>=firstRow also...) 2. elimination of potential vulnerability buffer overrun occurs inside Queryfont() in xc/programs/Xserver/dix/dixfonts.c. Queryfont uses fixed-length arrays(512 or 256), and buffer overrun when the difference between pFont->info.lastCol and pFont->info.firstCol. The reporter doesn't check other code except PCF font handling, there may be a possible problem inside other fonts handling code. Considering about this possibility, the more strict fix is to implement the checking in QueryFont(). Other part you should consider to add a checking code is around line 341 of doOpenFont(), where fonts are opened. [Proof-of-Concept Code] - The reporter provides a sample PCF font, attached in this message. This sample is based on timR08.bdf bundled with X11R6.8.2, transformed to PCF using bdftopcf, and modified using some binary editor. Byte 0x7f80-0x7f87 is originally 00 00 ff 00 00 00 26 00 but modified to 00 00 ff 26 00 00 00 00. This font itself is not "illegal" one, as long as libfont can treat it, but X server cannot treat it appropriately. The reporter supposes that the problem is not identified before because such a PCF font is not generated in the usual way. [Additional Information] - When exploiting charInfos[] overflow, the entry should be a pointer to xCharInfo struct on heap memory. When the heap area has no "executable" attribute, then resulted in bus error. It means, on many platforms, a simple DoS attack, no code-execution. - xfs (font server) may have some problem also. The modified PCF font forces xfs to crash. (a-1) Confirmed the report description with the following configuration. Code execution may be possible, but cannot confirmed. ------------------ FreeBSD 6.0R X.org 6.9.0 (ports x11/xorg) language: ENGLISH running on VMWare Server ------------------ (a-2) Verification 1. put modified PCF font. generate fons.dir using mkfontdir. 2. start Xorg. 3. add the prepared directory to FontPath. $ xset +fp pocfontdir/ $ xset fp rehash 4. render the font with xfontsel. Here Xorg core-dumps. (b) Comments Confirmed that Xorg crashes using the modified PCF font. chars[] array of QueryFont() (xc/programs/Xserver/dix/dixfonts.c) overflows, but exploit looks difficult. Exploiting charInfos[] array looks easier, code execution may be possible. Confirmed also that XFree86 4.3.0 crashes, which is the version before code branch from X.org. It means the later version of XFree86 may be vulnerable. ----- END ORIGINAL VULNERABILITY REPORT -----