There exists a integer overflow to buffer overflow vulnerability within __tzfile_read function of the GNU C Library. This vulnerability was published by dividead early in 2009 in the following blog post: http://dividead.wordpress.com/2009/06/01/glibc-timezone-integer-overflow/ In December 3, Kingcope, at Full Disclosure Mailing List, noted vsftpd as one possible attack vector for this issue: http://lists.grok.org.uk/pipermail/full-disclosure/2011-December/084452.html
Exploiting glibc __tzfile_read integer overflow to buffer overflow and vsftpd http://rcvalle.com/post/14169476482/exploiting-glibc-tzfile-read-integer-overflow-to
Created glibc tracking bugs for this issue Affects: fedora-all [bug 767696]
More on exploiting glibc __tzfile_read integer overflow to buffer overflow and vsftpd http://rcvalle.com/post/14261796328/more-on-exploiting-glibc-tzfile-read-integer-overflow
So I'm just coming up to speed on this problem. If I've read things correctly, the problem is the integer overflow if mr. badguy constructs a bogus tzfile. The integer overflow is used to generate a "useful" size for the malloc call. After that I'm a bit lost, though it may not matter. ISTM we need to verify that the computation of total_size, tzspec_len don't overflow nor does total_size + tzspec_len + extra overflow. If an overflow is detected it appears we can safely "goto lose". Does that match your interpretation of the core issue and what needs to be changed to resolve it? Having never worked with security errata before, are there restrictions on discussing it on the upstream mailing lists or with the upstream developers privately?
Hi Jeff, There are a few more checks to be made beyond these. I recommend contacting the developers for an appropriate correction. Feel free to publicly discuss this issue on mailing-lists since it is public since earlier 2009.
(In reply to comment #15) > The integer overflow is used to generate a "useful" size for the malloc call. > After that I'm a bit lost, though it may not matter. This is a common flaw pattern - an integer overflow / wrap around in the expression used to compute size passed to malloc results in an allocation of the buffer of the insufficient size. Later processing, however, tries to write more data to the buffer, resulting in (heap-based) buffer overflow, i.e. possibly exploitable memory corruption.
Upstream bug and discussion: http://sourceware.org/bugzilla/show_bug.cgi?id=13506 http://sourceware.org/ml/libc-alpha/2011-12/msg00037.html
Upstream commits: http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=97ac2654b2d831acaa18a2b018b0736245903fd2 http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=8fa26d571d4b87a1c7a7f19f1365f7e5d2995933
glibc-2.14.1-5 has been pushed to the Fedora 15 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 6 Via RHSA-2012:0058 https://rhn.redhat.com/errata/RHSA-2012-0058.html
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2012:0126 https://rhn.redhat.com/errata/RHSA-2012-0126.html
This issue has been addressed in following products: Red Hat Enterprise Linux 4 Via RHSA-2012:0125 https://rhn.redhat.com/errata/RHSA-2012-0125.html