
FireEye Exploitation: Project Zero’s Vulnerability of the Beast - officialjunk
http://googleprojectzero.blogspot.com/2015/12/fireeye-exploitation-project-zeros.html
======
MrBuddyCasino
tl;dr: there is a decompiler for JARs that has a built-in virtual machine that
executes some code in order to de-obfuscate Java strings. And yes, this is
exactly as bad as it sounds.

~~~
akiselev
And that decompiler operates as part of popular enterprise passive network
monitoring hardware, so the attack vector is literally any JAR sent over the
monitored switch, giving the attacker full read only access to the entire
network (possibly even write access in some configurations).

That said, the manufacturer had configurations to mitigate the damage out
within hours and a full patch 2 days after they were notified by Project Zero.

~~~
mike_hearn
I guess the more important question is what kind of process changes are
FireEye going to make?

FireEye is a security company. Their business is security and catching hacking
attempts. They of all people should know how dangerous it is to scrape and
parse potentially malicious data off the wire in large quantities, and yet it
doesn't sound like they've taken any special precautions. OK, the JAR
disassembler doesn't run as root, but there's a privilege escalation so simple
the description fits in a single line of text, so that's not worth much.

The fact that JODE has the potential to execute arbitrary code whilst
decompiling isn't a secret, it's mentioned in the FAQ. So there must have been
some kind of failure in the development process that led to the appliance
developers simply grabbing whatever package they encountered first in order to
ship the feature, without taking into account the security of their own
software stack.

To me this says that the appliance is very likely to have lots of other
vulnerabilities in it. Sort of like how anti-virus engines have been found to
be vipers nests of exploits.

~~~
pyvpx
JODE is basically not maintained and quite ancient in its feature set. I don't
understand why JODE is being used here. I thought perhaps because of
licensing, but it is GPL/LGPL as are other, more maintained and modern java
decompilers.

does anyone out there know why they're using JODE?

------
tetrep
This is pretty interesting because it's actually a vuln in JODE, which is used
by FireEye's devices to decompile and inspect JARs for malicious code. I'm
curious as to the thought process behind JODE's developers when they decided
to execute code from the JAR they're decompiling, since decompiling is almost
always done against untrusted JARs, it seems like an odd move to explicitly
execute code from them. Yet another reason to do all your RE in a VM/locked
down environment. I think it's kinda funny that FireEye have made a dedicated
environment for scanning malware but aren't even taking advantage of basic
chroot/jail/whatever to at least mitigate an RCE such as this. There's also a
privilege escalation issue at play here that seems to be non-trivial to fix as
it's been weeks since disclosure and FireEye has requested more time to fix
it. I guess FireEye really doesn't want its customers to have root access to
their devices? I'm not sure how the devices are sold, but I suppose if they're
rented or leased that would make sense.

------
detaro
Guess Google was a bit to large to sue into silence...

------
jkot
Bit relevant, if you want to get most Maven dependencies over HTTPS, add this
to _~ /.m2/settings.xml_

    
    
      <mirrors>
        <mirror>
          <id>UK</id>
          <name>UK Central</name>
          <url>https://repo1.maven.org/maven2</url>
          <mirrorOf>central</mirrorOf>
        </mirror>
      </mirrors>

