[arch-security] Fw: [oss-security] Running Java across a privilege boundry

[Borja]

Hi guys,

I noticed that Arch's Java JRE binary is also prone to this issue:

----------------------------[ SNIP ]-----------------------------
$ objdump -x /usr/lib/jvm/java-7-openjdk/jre/bin/java | grep RPATH | awk '{print $2}' | tr ':' '\n'
$ORIGIN/../lib/amd64/jli
bootstrap/jre/lib/amd64/jli
$ORIGIN/../lib/amd64
bootstrap/lib/amd64
$ORIGIN/../jre/lib/amd64
bootstrap/jre/lib/amd64
$ 
$ 
$ mkdir -p bootstrap/lib/amd64/
$ touch bootstrap/lib/amd64/libc.so.6
$ 
$ 
$ sudo /usr/lib/jvm/java-7-openjdk/jre/bin/java
/usr/lib/jvm/java-7-openjdk/jre/bin/java: error while loading shared libraries: bootstrap/lib/amd64/libc.so.6: file too short
----------------------------[ SNIP ]-----------------------------


Below the oss-security mail by Tim Brown:


--------------------------[ FORWARDED ]--------------------------

Fecha: Thu, 18 Dec 2014 09:18:25 +0000
Desde: Tim Brown <tmb at 65535.com>
Para: Solar Designer <solar at openwall.com>
Cc: oss-security at lists.openwall.com
Asunto: Re: [oss-security] Running Java across a privilege boundry


On Wednesday 26 November 2014 03:54:48 Solar Designer wrote:
> On Sun, Nov 23, 2014 at 05:59:41PM +0300, Solar Designer wrote:
> > So far no distro has expressed any interest in having this embargoed.
> > 
> > Distros list members: please speak up (here or on the distros list, with
> > Tim CC'ed) if you'd like this embargoed.
> > 
> > Tim: if until Tuesday no distro says they want this embargoed, please go
> > ahead and make the issue fully public.  (On a related note, I hate it
> > when an issue is sort of "semi-public".  It's the worst possible case.
> > When this happens, it's a reason to opt for a shorter embargo period, or
> > for none at all indeed.)  If an embargo is requested, please make sure
> > there's an exact date and time for the planned public disclosure.
> 
> So far no distro has expressed any interest in having this embargoed,
> and no specific coordinated disclosure date has been proposed by anyone.
> Tim, please make the issue public now by posting it in here.  Thanks!

Apologies, I was locked in a server room for the last 2-3 weeks without
access to my Internet.

The issue for anyone that was interested was as follows:

> $ objdump -x /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java | grep RPATH
> 
>   RPATH                $ORIGIN/../lib/amd64/jli:bootstrap/jre/lib/amd64/jli:
> $ORIGIN/../lib/amd64:bootstrap/lib/amd64:
> $ORIGIN/../jre/lib/amd64:bootstrap/jre/lib/amd64
> $ mkdir -p bootstrap/jre/lib/amd64/jli
> $ touch bootstrap/jre/lib/amd64/jli/libc.so.6
> $ sudo java
> java: error while loading shared libraries:
> bootstrap/jre/lib/amd64/jli/libc.so.6: file too short
> 
> I haven't checked if this is an upstream problem or whether just Debian is
> affected.
> 
> Whilst strictly speaking, there is no security boundary offered by Java
> itself, in the case of unsafe RPATH headers on a ELF binary, sudo can do
> nothing to sanitise the environment. Nor indeed could an arbitrary setuid
> which ends up calling Java with additional privileges. (Unlike say PATH
> etc which sudo can quite happily sanitise.)
> 
> As such, only fixing the java binary itself will prevent library injection
> into any Java application that is run interactively (or maybe otherwise)
> in such a manner.

Cheers,
Tim
-- 
Tim Brown
<mailto:tmb at 65535.com>

--------------------------[ FORWARDED ]--------------------------

Cheers,

Borja.

-- 

================================================================================

 GPG 0x8C00BA074CA6E08B -- https://www.libcrack.so/