FireEye Exploitation: Project Zero’s Vulnerability of the Beast | Hacker News Reader

FireEye Exploitation: Project Zero’s Vulnerability of the Beast

googleprojectzero.blogspot.com

67 pointsofficialjunk9 comments

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.

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.

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.

"The hackers could only exploit us because we used open-source for Java decompilation! From now on all open source is forbidden."

I used to work for a security vendor and MIME/email used to be another great target for exploiting mail filters. We had our own sec team checking the security of our own software - amazing what stuff they found in our own code base and third party libraries. Security is hard.

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?

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.

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

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>

Reply on news.ycombinator.com