Bug 13506 (CVE-2009-5029) - tzfile.c heap overrun/corruption (CVE-2009-5029)
Summary: tzfile.c heap overrun/corruption (CVE-2009-5029)
Status: RESOLVED FIXED
Alias: CVE-2009-5029
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: 2.14
: P2 normal
Target Milestone: ---
Assignee: Ulrich Drepper
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-15 20:44 UTC by Paul Eggert
Modified: 2014-06-27 11:30 UTC (History)
7 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security+


Attachments
Jeff Law work-in-progress patch (605 bytes, patch)
2011-12-15 20:44 UTC, Paul Eggert
Details | Diff
catch multiplication as well as addition overflows (561 bytes, patch)
2011-12-15 21:00 UTC, Paul Eggert
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Eggert 2011-12-15 20:44:55 UTC
Created attachment 6113 [details]
Jeff Law work-in-progress patch

In <http://cygwin.com/ml/libc-alpha/2011-12/msg00037.html>
Jeff Law writes:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As y'all may be aware, there's an integer overflow which can be used
to trigger a heap overrun/corruption in time/tzfile.c

http://dividead.wordpress.com/2009/06/01/glibc-timezone-integer-overflow/


http://rcvalle.com/post/14169476482/exploiting-glibc-tzfile-read-integer-overflow-to


I'm not terribly familiar with the code in question, but ISTM we have
to verify the intermediate computations to determine the amount of
memory to malloc don't overflow/wrap.

Here's a WIP.  It catches the cases I've been made aware of
(overflowing total_size to 0 by creating a tzfile with a very large
tzh_charcnt).  But there may be further overflows I've missed.

Obviously it's not commented and it's unclear to me if we also want to
put in some kind of sanity checks on total_size to prevent it from
trying to malloc unreasoanble amounts of memory.

Your feedback would be greatly appreciated.




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJO6k6gAAoJEBRtltQi2kC7ASQH/0UmQm0wqk3NRmlsVr5M1r3f
fUelY55y8OQssaFCLDZ9LX1vybam9j85gmvGtRJUU4MJ3134hn/v73k8TYCd3rHJ
/QIQY10zPBHkmEwp8G56+3l9QRl418C+ajTq0W4NAzM1rIHtPUgrqZ3AkNJgFVYU
OAF+2afFDGE5vJ3HR7LSL62tuxjDf7m66r4tHHkbhkSSZgkyW/YxfFUPDupZnlz8
Wl87JU/RWHdMJ+RR+fB1ofgFKrNZnGpIsD3sAc07KWTp63S358DSRpZ1IaF2o3vh
N93z28eCQQKIVciOKgAE5q/qYr1KmcyU/6M4xPk+Pqv5YFdKOz8uNiw5NQu2rv0=
=RKgA
-----END PGP SIGNATURE-----
Comment 1 Paul Eggert 2011-12-15 21:00:49 UTC
Created attachment 6114 [details]
catch multiplication as well as addition overflows

Jeff Law's work-in-progress patch misses some problematic overflows.  This is
because the integer multiplications may overflow too.  Attached is an
untested patch that catches the problematic overflows that I found
by inspection.  This patch does not attempt to catch all overflows, only
those that might corrupt memory.
Comment 2 Ulrich Drepper 2011-12-18 01:19:35 UTC
I added a patch.
Comment 4 Allan McRae 2011-12-19 05:50:57 UTC
Note that there is a typo in that patch. The "tzspec == 0"  should be "tzspec_len == 0".  I sent the trivial patch to the mailing list (awaiting moderation).
Comment 5 law 2011-12-19 07:57:44 UTC
Also looks like s390 won't build because SIZE_MAX is not defined.  Guessing stdint.h needs to be included in tzfile.c
Comment 6 Ulrich Drepper 2011-12-21 23:58:14 UTC
(In reply to comment #5)
> Also looks like s390 won't build because SIZE_MAX is not defined.  Guessing
> stdint.h needs to be included in tzfile.c

The correct change is to make the s390 header look like the x86-64 headers.