back to article FireEye flamed: A single email will grant total network access

Researchers at the Google's Project Zero security research team have found a brutal hole in FireEye kit that allows attackers to lay waste to corporate networks with a single email. The flaw, dubbed "666" from its Project Zero vulnerability number, is a passive monitoring hole that respected hacker Tavis Ormandy describes as a …

  1. dan1980
    1. Captain DaFt

      Wow indeed. That's no hole, that's the Marianas Trench!

  2. Bronek Kozicki Silver badge

    here is the question

    ... how many of the government customers (among others) of FireEye will ignore the patch?

    1. Anonymous Coward
      Anonymous Coward

      Re: here is the question

      And then complain when they are hacked.

  3. Anonymous Coward
    Anonymous Coward

    Highlights of ProjectZero writeup

    Your author here wonders in what world a 'security' vendor employee or subcontractor ever considered it sensible to attempt to execute data/code which arrives in an untrustworthy manner. Still, what do I know.

    The highlights (from my point of view) of the ProjectZero writeup are the following, the full thing is at

    "by sending a JAR across the network, we can get the FireEye to execute it simply by pretending to use string obfuscation."

    [ ... ]

    "we were eventually able to construct a class that JODE would execute, and used it to invoke java.lang.Runtime.getRuntime().exec(), which allows us to execute arbitrary shell commands. This worked during our testing, and we were able to execute commands just by transferring JAR files across the passive monitoring interfaces."

    [ ... ]

    "Just find an exploit that provides privilege escalation on the FireEye, and the machine is yours:

    "now we’re root, with complete control of the FireEye machine. We can load a rootkit, persist across reboots or factory resets, inspect or modify traffic, or perform any other action."

    [ ... ]

    Nice writeup of a nice find. And at least FireEye fixed it in a timely fashion.

    Who's doing a similar kind of bug-hunting job for safety-critical software (e.g. the Toyota uncommanded acceleration case is one of the more public examples)?

    If the answer is "nobody is doing it", does it matter?

    1. Michael Wojcik Silver badge

      Re: Highlights of ProjectZero writeup

      The problem boils down to this:

      - One of the things the FireEye appliance does is inspect content to see if it appears to be dangerous.

      - If the content includes compiled Java (class or jar files), it decompiles it to Java source and scans the source for potential problems. (I'm not going to debate here the probability that scanning decompiled source in this way is useful.)

      - To decompile Java classes, it uses the open-source JODE tool.

      - JODE, it turns out, is marvelously unsafe. It uses reflection (which we know is a security hole) and, as the PZ team put it, "contains a simple java virtual machine". So, ouch.

      And thus the problem. FireEye can't be expected to write all of their scanners and validators from scratch; they have to deal with a huge array of content types, with new ones being invented all the time. And there are all these open-source goodies that can be used, more or less modified, to check out content of particular types.

      I hope the people at FireEye do some sanity testing of the third-party components they use - fuzzing and the like - and they probably do, because that's their business. But this kind of issue is tougher to find without doing an in-depth analysis.

      I expect that after this, FireEye will be looking at their third-party components more closely.

  4. Stevie Silver badge


    Well, if you name products the same way Bond movie villains name thier secret terror weapons, what do you expect?

    1. Michael Wojcik Silver badge

      Re: Bah!

      A secret terror weapon? Doesn't that rather defeat the point?

      "Fools! They would quake in fear, if they knew of this! Which they don't. Oh, well."

  5. Anonymous Coward
    Anonymous Coward

    Game over for FireEye

    sorry, but if your 'security' product is written in Java, that's like wearing honey underwear at a bear party.

    Unless they can re-implement that thing in a secure language, no amount of 'patches' will ever get them out of that nightmare.

    1. Anonymous Coward
      Anonymous Coward

      Re: Game over for FireEye

      Not to mention the fact that whatever management and review process they were using inside FireEye (if any) didn't seem to spot that unprotected execution of arbitrary data received from unknown sources in an untrustworthy way just might possibly be a bad idea occasionally.

      Isn't what's happened here basically today's equivalent of checking whether an attachment with macros is safe, by clicking on it and seeing what happens? Any rocket scientists here care to comment? Oh hang on, it's not rocket science.

      1. Anonymous Coward
        Anonymous Coward


        Exploding it in a sandboxed virtual machine.

        just clicking on it...duuuuuhhhhhhhhhh

    2. Michael Wojcik Silver badge

      Re: Game over for FireEye

      Aaaaaand the AC who didn't read the actual blog post makes a dumb comment. Shocking!

      1. This post has been deleted by its author

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019