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.

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?

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.

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.

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?

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.

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.

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.

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.

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)

(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.

(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.

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.

Caolan, can you make sure this gets updated for Fedora 9 and Fedora 10 please?  Thanks.

>>(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.

Ok, thanks for the clarification.  Please let me know when you have packages prepared for RHEL5.  Thanks.

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.

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.

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