Bugzilla Bug 145513

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 an attachment (id=95407) [details]
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 an attachment (id=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 an attachment (id=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 an attachment (id=96254) [details]
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 an attachment (id=96271) [details]
1.2.0-cid-overflows.patch-6447.out

96254: 1.2.0-cid-overflows.patch doesn't work.

Created an attachment (id=96288) [details]
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 an attachment (id=96295) [details]
1.2.0-cid-overflows.patch

Attachment #96288 [details] (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], 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