Bug 503071 - (CVE-2009-0153) CVE-2009-0153 icu: XSS vulnerability due to improper invalid byte sequence handling
CVE-2009-0153 icu: XSS vulnerability due to improper invalid byte sequence ha...
Status: VERIFIED
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
http://web.nvd.nist.gov/view/vuln/det...
impact=moderate,public=20070417,repor...
: Security
Depends On: 505159 505160 505366 505368 505369
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-28 13:06 EDT by Vincent Danen
Modified: 2016-06-22 11:26 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
proposed backports .src.rpm (9.41 MB, application/x-rpm)
2009-06-02 12:09 EDT, Caolan McNamara
no flags Details

  None (edit)
Description Vincent Danen 2009-05-28 13:06:04 EDT
Common Vulnerabilities and Exposures assigned an identifier CVE-2009-0153 to
the following vulnerability:

International Components for Unicode (ICU) in Apple Mac OS X 10.5 before 10.5.7 does not properly handle invalid byte sequences during Unicode conversion, which might allow remote attackers to conduct cross-site scripting (XSS) attacks.

http://support.apple.com/kb/HT3549
http://lists.apple.com/archives/security-announce/2009/May/msg00002.html
http://www.us-cert.gov/cas/techalerts/TA09-133A.html
http://www.securityfocus.com/bid/34926
http://secunia.com/advisories/35074
http://www.vupen.com/english/advisories/2009/1297
http://xforce.iss.net/xforce/xfdb/50488
Comment 1 Vincent Danen 2009-05-28 13:11:32 EDT
This issue was originally reported upstream in 2007:

http://bugs.icu-project.org/trac/ticket/5691

The following patchsets are linked to the bug to correct the issue:

http://bugs.icu-project.org/trac/search?q=%22ticket:5691:%22&noquickjump=1&changeset=on

Most of the patches apply to RHEL5 with some rejects, so they need to be backported to the earlier versions.

According to the release notes, 4.0.1 contains the fix:

http://icu-project.org/download/4.0.html

This means that Red Hat Enterprise Linux 5, Directory Server 8, MRG-1, and Fedora 9 and 10 are affected.

Also looking at the release notes, icu4j did not receive any fixes for this issue so would likely not be vulnerable.
Comment 2 Rich Megginson 2009-05-28 13:35:46 EDT
Was this flaw in ICU 3.6 or earlier versions?  If so, only directory server on Fedora is affected.  Red Hat Directory Server is supported on RHEL4, RHEL5, Solaris, and HP-UX.  On RHEL4, Solaris, and HP-UX, we distribute ICU 3.6.  On RHEL5, we use ICU provided by the OS, which is version 3.6 release 5.11.2 on my RHEL5.3 system.  So I'm not sure if this affects Red Hat Directory Server.  For Fedora (389) Directory Server, I suppose it would be affected on those systems that use ICU 4.0.  But I'm not clear on the nature of the vulnerability.  Is there something directory server can do to workaround the vulnerability, or is the only recourse to use a patched ICU 4.0.1?
Comment 3 Vincent Danen 2009-05-28 14:07:59 EDT
Judging by the number of bits that applied clean to RHEL5's icu (3.6), I would say that yes it affects 3.6.  My manifest shows:

fedora:9/icu-3.8.1-7.fc9
fedora:epel:4/icu-3.6-4.el4.20
enterprise_linux:5:u2:server/icu-3.6-5.11.1
enterprise_linux:5:u3:client/icu-3.6-5.11.1
enterprise_linux:5:u3:server/icu-3.6-5.11.1
directory_server:8.1::el4/icu-3.6-4.el4dsrv
directory_server:8.1::sparc/icu-3.6-1
enterprise_mrg:1.1::el4/icu-3.6-5.12.el4

Yes, this would affect Directory Server (perhaps not on RHEL5 directly, but RHEL5 itself needs a fixed icu also).

To be honest, the details are quite sparse and I'm not aware of a reproducer for the issue, so I can't say if there is a workaround we could use on Directory Server (or anywhere else for that matter).

The upstream bug has more details on the issue.  This looks to be a problem only when converting to Unicode (possibly just from UTF-8, but it looks like there are some other charsets that it would be problematic with as well).

Without knowing how Directory Server is using uci, I can't really guess at a workaround.
Comment 4 Rich Megginson 2009-05-28 16:37:40 EDT
The directory server uses iconv to do charset <-> utf8 conversion for data coming from a client.  We use u_strToUTF8 to convert resource bundle strings to utf8.  The only way to exploit this then in the directory server would be for someone to hack into the system an change one of the read-only resource bundles supplied with the server package.

The fedora-ds-dsgw package, not supported for RHDS, only via Fedora, does use ucnv_toUnicode and ucnv_fromUnicode.  So I suppose an attack vector would be for a malicious user to store bogus data in the directory server then retrieve it.  When the directory server stores the data, it is converted from the native charset to utf8 and stored in the DS as utf8.  When retrieved, it is converted from utf8 to the native charset.  This assumes the malicious user has write privileges to the DS, or has somehow identified data already in the DS that can be exploited in this manner.

So - Red Hat Directory Server is not affected.  The fedora-ds-dsgw package is affected, and the resolution is to upgrade ICU to 4.0.1 or later.

However, we should upgrade Red Hat Directory Server to use ICU 4.0.1 on all the platforms that we support.
Comment 5 Vincent Danen 2009-05-28 17:14:03 EDT
So you think it would be better to respin to 4.0.1 on all platforms instead of backporting the fixes?  I can see this on Fedora, no problem.  I can even see this on Directory Server for the other platforms, but I'm not sure about respinning to 4.0.1 on RHEL5, unless it's there specifically for Directory Server.

I don't have the data yet to determine what requires icu in RHEL5, but in Fedora 10 it is boost, OpenOffice.org, and WebKit-gtk.  Of those, only WebKit-gtk is not included in RHEL5.  I'm not sure how intrusive the changes from 3.6 to 4.0.1 is, so I can't really comment on whether or not this is feasible for RHEL5, but we cannot have any ABI changes there so if the ABI has changed then we must backport on RHEL5 at least, which may impact Directory Server.  Do you have to make actual code changes to Directory Server to work with 4.0.1 do you know?
Comment 6 Rich Megginson 2009-05-28 17:40:55 EDT
I was talking only about the ICU we distribute with directory server.  For the other platforms, I suppose it's up to the ICU maintainer to figure out which way is best.
Comment 7 Vincent Danen 2009-05-28 18:42:24 EDT
Fair enough.

Caolan, how would you like to handle the icu packages for RHEL5 and the rest?  The appropriate patches have been found, so I think we should patch RHEL5 instead of respinning to 4.0.1.
Comment 8 Caolan McNamara 2009-05-29 03:28:38 EDT
We've got 3.6 in RHEL-5 and changing to a 4.X would change the behaviour of at least keyboard traversal of Indic clusters, etc and a load of other behavioural stuff that wouldn't be good to see changed in a security update. (And every icu major version has a different SONAME requiring re-building everything that depends on it unless we hack it to not do that).

We'd really have to patch instead of re-spinning. This issue really sounds very similar to CVE-2008-1036.
Comment 9 Vincent Danen 2009-05-29 11:32:56 EDT
Thanks for spelling that out. I suspected a rebase would be a no-go (we usually don't like doing that to begin with).  It makes me also think that rebasing for Directory Server may not be wise either.

And yes, it does sound similar, but it is not the same issue.  There was some confusion about this at first, but Apple cleared it up as noted with the upstream bug reference.

The patches I've linked to apply for the most part, but there is some backporting you need to do to get it to fully apply to 3.6.
Comment 10 Caolan McNamara 2009-06-02 12:09:48 EDT
Created attachment 346280 [details]
proposed backports .src.rpm

Where some backporting == quite a lot of backporting.

So, good few patches required really. Attached a .src.rpm as the order matters and the previous CVE-2008-1036 change needs regenerating as well. *should* be abi compatible and fix this problem (definitely the test added to test the problem passes fine)
Comment 11 Vincent Danen 2009-06-10 16:33:14 EDT
(In reply to comment #4)

> The fedora-ds-dsgw package, not supported for RHDS, only via Fedora, does use
> ucnv_toUnicode and ucnv_fromUnicode.  So I suppose an attack vector would be
> for a malicious user to store bogus data in the directory server then retrieve
> it.  When the directory server stores the data, it is converted from the native
> charset to utf8 and stored in the DS as utf8.  When retrieved, it is converted
> from utf8 to the native charset.  This assumes the malicious user has write
> privileges to the DS, or has somehow identified data already in the DS that can
> be exploited in this manner.
> 
> So - Red Hat Directory Server is not affected.  The fedora-ds-dsgw package is
> affected, and the resolution is to upgrade ICU to 4.0.1 or later.

Ok, so to clarify: fedora-ds-dsgw would be affected, but would it not use the system icu?  So if icu were updated to 4.0.1 in Fedora, this would correct any problems in fedora-ds-dsgw, correct?

> However, we should upgrade Red Hat Directory Server to use ICU 4.0.1 on all the
> platforms that we support.  

If RHDS is not affected, why upgrade ICU?


(In reply to comment #10)

> So, good few patches required really. Attached a .src.rpm as the order matters
> and the previous CVE-2008-1036 change needs regenerating as well. *should* be
> abi compatible and fix this problem (definitely the test added to test the
> problem passes fine) 

The test you're referring to is in the patch itself?  Can you clarify that?  Thanks.
Comment 13 Rich Megginson 2009-06-10 16:50:47 EDT
(In reply to comment #11)
> (In reply to comment #4)
> 
> > The fedora-ds-dsgw package, not supported for RHDS, only via Fedora, does use
> > ucnv_toUnicode and ucnv_fromUnicode.  So I suppose an attack vector would be
> > for a malicious user to store bogus data in the directory server then retrieve
> > it.  When the directory server stores the data, it is converted from the native
> > charset to utf8 and stored in the DS as utf8.  When retrieved, it is converted
> > from utf8 to the native charset.  This assumes the malicious user has write
> > privileges to the DS, or has somehow identified data already in the DS that can
> > be exploited in this manner.
> > 
> > So - Red Hat Directory Server is not affected.  The fedora-ds-dsgw package is
> > affected, and the resolution is to upgrade ICU to 4.0.1 or later.
> 
> Ok, so to clarify: fedora-ds-dsgw would be affected, but would it not use the
> system icu?  So if icu were updated to 4.0.1 in Fedora, this would correct any
> problems in fedora-ds-dsgw, correct?

fedora-ds-dsgw uses the system icu.  If icu were updated to 4.0.1, this would correct any problems in the fedora-ds-dsgw.

> 
> > However, we should upgrade Red Hat Directory Server to use ICU 4.0.1 on all the
> > platforms that we support.  
> 
> If RHDS is not affected, why upgrade ICU?

Because we should use the most current version, unless there is some reason not to.

> 
> 
> (In reply to comment #10)
> 
> > So, good few patches required really. Attached a .src.rpm as the order matters
> > and the previous CVE-2008-1036 change needs regenerating as well. *should* be
> > abi compatible and fix this problem (definitely the test added to test the
> > problem passes fine) 
> 
> The test you're referring to is in the patch itself?  Can you clarify that? 
> Thanks.
Comment 14 Vincent Danen 2009-06-10 19:01:27 EDT
Ok, then we should definitely update Fedora.  Note that Fedora 11 has 4.0.1.

I'm not sure if RHDS follows a different policy than other products, but we typically prefer to backport fixes as required and refrain from rebasing packages to the latest versions to prevent ABI changes, or other changes and bugs that new versions tend to introduce and can have unintended consequences with other packages.  Also, if this issue does not even affect RHDS in that the vulnerabilities in question are not used by RHDS, then upgrading is spurious as it doesn't really fix anything.
Comment 15 Vincent Danen 2009-06-10 19:03:13 EDT
Caolan, can you make sure this gets updated for Fedora 9 and Fedora 10 please?  Thanks.
Comment 16 Caolan McNamara 2009-06-11 05:15:01 EDT
>>(definitely the test added to test the problem passes fine) 
>The test you're referring to is in the patch itself?  Can you clarify that? 

Yes, icu has a make check and as part of their fixes for this they added extra test-cases to that make check for the encodings affected by this. With the above set of inter-locking backports the make check passes, so the built-in test passes.
Comment 17 Vincent Danen 2009-06-11 11:54:16 EDT
Ok, thanks for the clarification.  Please let me know when you have packages prepared for RHEL5.  Thanks.
Comment 20 Fedora Update System 2009-06-15 21:42:22 EDT
icu-3.8.1-9.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 21 Fedora Update System 2009-06-15 22:03:32 EDT
icu-4.0-3.1.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 22 errata-xmlrpc 2009-06-25 10:06:35 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2009:1122 https://rhn.redhat.com/errata/RHSA-2009-1122.html

Note You need to log in before you can comment on or make changes to this bug.