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 …
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
http://googleprojectzero.blogspot.com.au/2015/12/fireeye-exploitation-project-zeros.html
"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)?
http://betterembsw.blogspot.co.uk/2014/09/a-case-study-of-toyota-unintended.html
If the answer is "nobody is doing it", does it matter?
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.
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.
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
