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.