Evolution Data Server contained multiple copies of base64_encode_simple function similar to one now implemented in glib2, that were affected by the glib2's CVE-2008-4316 integer overflow issue. out = g_malloc (len * 4 / 3 + 5); If the affected functions were used on large untrusted inputs, memory requirement computation may overflow, resulting in an insufficient memory allocation and heap-based buffer overflow during the base64 encode of the supplied data. Affected code existed in: - _evc_base64_encode_simple() in addressbook/libebook/e-vcard.c, can possibly be triggered by malicious LDAP address book backend - camel_base64_encode_simple() in camel/camel-mime-utils.c, can possibly be triggered by NTLM SASL authentication, or Exchange backend Note: current upstream versions of Evolution Data Server are not affected by these flaws, as they do no longer have own base64 encoding and decoding routines and rather rely on the functions provided by glib2. The change was done upstream in the following SVN commit: http://svn.gnome.org/viewvc/evolution-data-server?view=revision&revision=8090
Created attachment 333864 [details] Possible fix for _evc_base64_encode_simple() Based on glib2's patch, see bug #474770.
Created attachment 333866 [details] Possible fix for camel_base64_encode_simple() Unlike patch for _evc_base64_encode_simple(), this g_errors for large inputs rather than returning NULL, as camel_base64_encode_simple() does not seem to be be expected to ever return NULL. Failing g_error should not be a big issue though, as with multiplication and division operations reversed, only inputs of 3gig+ (on 32 bit systems) can trigger overflow, which are quite unlikely.
Fix for glib is now committed in glib's upstream SVN now: https://bugzilla.redhat.com/show_bug.cgi?id=474770#c17 Lifting embargo on this too.
Upstream SVN commit: http://svn.gnome.org/viewvc/evolution-data-server?view=revision&revision=10161
This issue has been addressed in following products: Red Hat Enterprise Linux 4 Red Hat Enterprise Linux 5 Via RHSA-2009:0354 https://rhn.redhat.com/errata/RHSA-2009-0354.html
This issue has been addressed in following products: Red Hat Enterprise Linux 4 Via RHSA-2009-0355 https://rhn.redhat.com/errata/RHSA-2009-0355.html
This issue has been addressed in following products: Red Hat Enterprise Linux 3 Via RHSA-2009:0358 https://rhn.redhat.com/errata/RHSA-2009-0358.html
as of Mon Mar 16 21:36:06 CET 2009 the src.rpm are not available on ftp://updates.redhat.com/ [tru@carrington ~]$ HEAD ftp://updates.redhat.com/enterprise/3AS/en/os/SRPMS/evolution-1.4.5-25.el3.src.rpm 404 File 'evolution-1.4.5-25.el3.src.rpm' not found Client-Date: Mon, 16 Mar 2009 20:36:14 GMT [tru@carrington ~]$ HEAD ftp://updates.redhat.com/enterprise/4AS/en/os/SRPMS/evolution-2.0.2-41.el4_7.2.src.rpm 404 File 'evolution-2.0.2-41.el4_7.2.src.rpm' not found Client-Date: Mon, 16 Mar 2009 20:37:07 GMT [tru@carrington ~]$ HEAD ftp://updates.redhat.com/enterprise/4AS/en/os/SRPMS/evolution-data-server-1.0.2-14.el4_7.1.src.rpm 404 File 'evolution-data-server-1.0.2-14.el4_7.1.src.rpm' not found Client-Date: Mon, 16 Mar 2009 20:37:21 GMT thanks Tru
(In reply to comment #19) > as of Mon Mar 16 21:36:06 CET 2009 > the src.rpm are not available on ftp://updates.redhat.com/ Are you sure the version of HEAD you are using is not playing tricks on you? With some older HEAD version, I still can get this bogus 404 message, even though the files are on the FTP and are wget-able. Anyway, please consider preferring to follow: https://www.redhat.com/security/team/contact/ when reporting similar issues, rather than using needinfo BZ flags.
the files were not there yesterday (I tried wget/HEAD/curl...) without success. They are now available, thx :)
This issue was addressed in: Red Hat Enterprise Linux: http://rhn.redhat.com/errata/RHSA-2009-0354.html http://rhn.redhat.com/errata/RHSA-2009-0355.html http://rhn.redhat.com/errata/RHSA-2009-0358.html