Buffer overflow in C code.

[Chris Hegarty]

[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. 
If so, this could be a good candidate to backport from jdk8 to jdk7 ( 
then I think icetea will get it for free! ).

-Chris.

[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7089443
[2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=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/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7fc56100a007]
> /lib/x86_64-linux-gnu/libc.so.6(+0x107f00)[0x7fc561008f00]
> /usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/libnet.so(Java_java_net_Inet4AddressImpl_getLocalHostName+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.
>