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 curio

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.