Buffer overflow in C code. (original) (raw)
Andrew Hughes ahughes at redhat.com
Wed Aug 1 02:35:47 PDT 2012
- Next message: hg: jdk8/tl/jdk: 2 new changesets
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
----- Original Message -----
[cc'ing net-dev mailing list]
Thanks for reporting this issue. This looks like 7089443 [1], fixed in jdk8 via 7112670 [2]. Looks like icetea needs to sync up, or maybe they are based against the jdk7 repo.
The report is from OpenJDK6:
/usr/lib/jvm/java-6-openjdk-amd64/
There is IcedTea support for 6, 7 and 8, but we only ship the complete releases (6 & 7) at present. Shipping an early release / early releases of 8 may be on the agenda at some point, but it means also covering it for security issues.
If so, this could be a good candidate to backport from jdk8 to jdk7 ( then I think icetea will get it for free! ).
I'll look into this.
-Chris.
[1] http://bugs.sun.com/bugdatabase/viewbug.do?bugid=7089443 [2] http://bugs.sun.com/bugdatabase/viewbug.do?bugid=7112670 -Chris. On 31/07/12 06:07, Robert Święcki wrote: > Hi, > > When using Java code compiled with gllibc's fortify source (buffer > overflow detection among others). It crashes: > > $ java -jar jar.jar > *** buffer overflow detected ***: java terminated > ======= Backtrace: ========= _> /lib/x8664-linux-gnu/libc.so.6(fortifyfail+0x37)[0x7fc56100a007] > /lib/x8664-linux-gnu/libc.so.6(+0x107f00)[0x7fc561008f00] > /usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/libnet.so(JavajavanetInet4AddressImplgetLocalHostName+0x1a0)[0x7fc55d8e4530] > [0x7fc555010d28] > ======= Memory map: ======== > 00400000-00409000 r-xp 00000000 fd:01 2872 > /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java > 00608000-00609000 r--p 00008000 fd:01 2872 > /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java > 00609000-0060a000 rw-p 00009000 fd:01 2872 > /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java > 01dba000-01ddb000 rw-p 00000000 00:00 0 > [heap] > cc000000-cca70000 rw-p 00000000 00:00 0 > cca70000-d9e00000 rw-p 00000000 00:00 0 > d9e00000-db2f0000 rw-p 00000000 00:00 0 > db2f0000-f5a00000 rw-p 00000000 00:00 0 > f5a00000-f6ec0000 rw-p 00000000 00:00 0 > f6ec0000-100000000 rw-p 00000000 00:00 0 > 7fc538000000-7fc538021000 rw-p 00000000 00:00 0 > 7fc538021000-7fc53c000000 ---p 00000000 00:00 0 > 7fc53c000000-7fc53c021000 rw-p 00000000 00:00 0 > 7fc53c021000-7fc540000000 ---p 00000000 00:00 0 > 7fc540000000-7fc540021000 rw-p 00000000 00:00 0 > 7fc540021000-7fc544000000 ---p 00000000 00:00 0 > 7fc544000000-7fc5440f5000 rw-p 00000000 00:00 0 > 7fc5440f5000-7fc548000000 ---p 00000000 00:00 0 > 7fc548000000-7fc548021000 rw-p 00000000 00:00 0 > 7fc548021000-7fc54c000000 ---p 00000000 00:00 0 > > IMO, the problem is here > > http://icedtea.classpath.org/~vanaltj/webrevs/tl/patch1/jdk/src/solaris/native/java/net/Inet4AddressImpl.c.html > (line 112) > > I.e. MAXHOSTNAMELEN is declarative only (a convention), and it is > assumed there that gethostbyaddr-like functions will return strings > which are shorter-equal than 64 (typical value of MAXHOSTNAMELEN). > > The machine's FQDN was way over 64 characters, so it crashed. I > don't > think it's easily exploitable (requires control over DNS), but it'd > be > probably good to fix it. >
-- Andrew :)
Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com)
PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
- Next message: hg: jdk8/tl/jdk: 2 new changesets
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]