iDefense has contacted xorg_security about multiple vunlerabilites they found in X's CID fonts parser. These vulnerabilites, based on integer overflows, are exploitable by a user able to connect to the X server to execute code with the X server's privileges. The affected code has not changed since XFree86 3.3.6. So all versions of X using the Type1 code are affected. In X versions after XFree86 4.4 (may be already 4.3, I'm not sure) is to only use the "freetype" module to handle Type 1 fonts. This module doesn't use the vulnerable code to parse Type 1 fonts.
Created attachment 95407 [details, diff] libXfont.diff
x11 team, please advise - I have some problems understanding this one (x.org is supposed to be vulnerable because it was forked at 4.3 and thus contains the affected code?). Is there anything in queue upstream?
Forgot to assign, sorry.
Donnie, I'm not sure you're the right one to CC (since x11 can't read restricted yet), but maybe you can help us here (or point me to somebody else)? Thanks!
Cool, another libXfont vuln (bug #144092 remains open waiting for advisory). Upstream bugs are https://bugs.freedesktop.org/show_bug.cgi?id=8000 and https://bugs.freedesktop.org/show_bug.cgi?id=8001 (both are security-restricted so you can't access them). All X versions should be vulnerable. The point at the end of comment #0 is that only CID fonts will cause the problem because they still use the Type1/ code, but typical Type 1 fonts use the FreeType parser.
Ok, thank you. So we wait for upstream. Do you have the exact embargo time, Donnie?
Latest info on the bugs indicates no date set yet, but I'm not privy to discussions on the security mail alias.
Created attachment 96088 [details] libXfont-1.2.0-r2.ebuild Here's an ebuild to test. Rename libXfont.diff to 1.2.0-cid-overflows.patch and drop it in files/.
Created attachment 96089 [details] libXfont-1.2.0-r2.ebuild Woops, that one was broken. Try this instead
I think I can try in the morning ... x86 only, I'm afraid, since my Alphas lag waay behind :P An exploit to check would be nice, though :)
Since we seem to have all we need, humbly asking sec liaisons to test and report.
looks good on ppc64. it's ok to have this marked stable on ppc64 while commiting to the tree.
Corsair, please don't commit yet, this is a prestabling request; thanks!
Created attachment 96254 [details, diff] 1.2.0-cid-overflows.patch Updated patch, changes includes around a bit. Reportedly fixes a compilation issue in module subdir.
What I meant was: When you commit then it would be ok for me to commit this streight to stable on ppc64 ^^
Created attachment 96271 [details] 1.2.0-cid-overflows.patch-6447.out 96254: 1.2.0-cid-overflows.patch doesn't work.
Created attachment 96288 [details, diff] 1.2.0-cid-overflows.patch Hrm. not sure how that happened... that was the diff between the two patches. Anyhow here's the right one.
Created attachment 96295 [details, diff] 1.2.0-cid-overflows.patch Attachment #96288 [details, diff] (1.2.0-cid-overflows.patch) fails with "No file to patch" because the paths in the patch begin with "lib/font" instead of "libXfont-1.2.0/src". The attached patch is the same as Attachment #96288 [details, diff], but it replaces "lib/font" with "libXfont-1.2.0/src".
looks good on amd64.
Appears to work correctly on x86 as well, so it can be marked when everyone else is
sparc looks fine.
looks good on ppc
looks good on hppa
Embargo time ends tomorrow. To be able to get it out we need word from - alpha - ppc64 (just say you're okay with the latest patch, too :-)
yes, latest patch okay on ppc64, too.
(In reply to comment #24) > Embargo time ends tomorrow. To be able to get it out we need word from > > - alpha Tested (with kloeri's permission) on alpha. Looks good on alpha.
That's all arches. No CVE yet? Jaervosz (Donnie?), if you're sure about the embargo date, we could proceed with GLSA.
I don't know anything further about embargo dates, there's nothing on the bugs so discussion must have taken place on lists.
The date was apparently chosen by the upstream Xorg Team and the initial report from iDEFENSE. So I guess the first public spot for this is: http://www.idefense.com/intelligence/vulnerabilities/
Upstream released, I'll bump in the tree. Here's the advisory: X.Org Security Advisory, September 12, 2006 Integer overflows in handling CID encoded Type1 fonts CVE-ID: 2006-3739, 2006-3740 Overview It may be possible for a user with the ability to set the X server font path, by making it point to a malicious font, to cause arbitrary code execution or denial of service on the X server. Vulnerability details The lack of validation of input data while parsing CID encoded Type1 fonts in the "type1" module may cause some integer overflows while computing the size of allocated data buffers when parsing a font. Arbitrary code embedded in the malicious font can then be executed by the X server. To exploit these vulnerabilities, the ability to connect to the X server in order to execute 'xset fp+' or the equivalent is required. CVE-ID 2006-3740 describes a vulnerability in the scan_cidfont() function in Type1/scanfont.c, while CVE ID 2006-3739 describes similar problems in the CIDADM() function in Type1/afm.c. Affected versions All X servers using the "type1" font module with CID font support are vulnerable to this issue. This includes all X.Org versions from 6.7.0 to 7.1 inclusive. Older versions are not supported by X.Org. Workaround If no CID-encoded Type 1 fonts are used, the "type1" module can be disabled and replaced by the "freetype" module in /etc/X11/xorg.conf. The freetype module is able to use Type1 fonts with standard (non CID) encoding as well as True Type fonts. Also, systems with memory address space randomization are less likely to be successfully compromised, as the most effective way to exploit these vulnerabilities rely on fixed address space. Fix These issues have been fixed in libXfont 1.2.1
I was wrong. First one appears to be here: https://issues.rpath.com/browse/RPL-614 Donnie just go ahead and commit the updates.
mmm, and what about xorg 6.8 ?
rerating since it's local root flaw.
(In reply to comment #32) > mmm, and what about xorg 6.8 ? http://archives.gentoo.org/gentoo-dev/msg_91800.xml
libXfont is in the tree and stabled on all tested architectures. Should be good to GLSA whenever.
Sorry, forgot to specify version -- >=1.2.2 is safe.
Thx for the version note Donnie! Security please review draft a second time.
Since the monolithic build is not supported anymore according to the -dev announce mail, I think it should either be masked or marked unstable to make that clear, to comply with policy and to make it clearer to users who don't look for such announcements.
(In reply to comment #38) > Since the monolithic build is not supported anymore according to the -dev > announce mail, I think it should either be masked or marked unstable to make > that clear, to comply with policy and to make it clearer to users who don't > look for such announcements. Sure, I'll mask it. I already added a USE flag to make it clear. Please take further discussion on this somewhere other than this bug.
Hm, this has left the building as GLSA 200609-07 ... Thanks everybody.
It would be very helpful to add this stop-gap measure to the glsa announcement from iDefence: >> V. WORKAROUND Access to the vulnerable code can be prevented by removing the entry for the Type1 font module from your Xservers configuration file, often stored in /etc/X11 and named xorg.conf or XF86Config-4. To do this, remove the following line from the 'Module' section: Load "type1" This will prevent Type 1 fonts from loading, which may affect the appearance or operation of some applications. >> This would at least let users stop the immediate threat whilst attacking the task of upgrading to modular X. A less than trivial job that will very likely require network access for howtos pkg etc and some fair ammount of time and effort. During this process the exploit would remain a serious vulnerability.
Sound argument. SecTeam, silent update?
I fail to see why we should update, we already have the following in the Workaround section: Disable CID-encoded Type 1 fonts by removing the "type1" module and replacing it with the "freetype" module in xorg.conf.
*cough* Poked my own eyes too much, probably ^^
closed
