"And just because the source filename has to end in .gif, that doesn't mean it's really a GIF file. The ImageIO library, as detailed in a previous Project Zero blogpost, is used to guess the correct format of the source file and parse it, completely ignoring the file extension. Using this "fake gif" trick, over 20 image codecs are suddenly part of the iMessage zero-click attack surface, including some very obscure and complex formats, remotely exposing probably hundreds of thousands of lines of code."
90% of zero-days could be stopped at the front door by file format checkers doing static analysis on popular file formats (like ZIP, MS-CFB, Office, image, PDF) exchanged via message/email to reduce semantic gaps in the file format and weird-machine ambiguities that will inevitably be abused by attackers.
The problem is simple. Most codecs (and even vulnerable anti-virus software) were written in a time when Postel's law was the norm. It's much easier to write a file format checker as defense-in-depth for the vulnerable codec than to rewrite the codec, especially since a codec's interface typically can't expose policy decisions like a checker's interface can.
As a community, we could solve this problem tomorrow.
However, the file format checkers to defend don't exist, because the major email/message providers don't want to invest in them, because nobody would see this work. Even if we build them, they don't want to invest in tuning the false positive rate, because people want lax security not strict security on all message/email attachments they open.
> This is not an official Google product, it is just code that happens to be owned by Google.
Which generally means that the original author worked at Google when they wrote this code & "chose" to let Google own the copyright of this project rather than fill out more paperwork.
It doesn't imply the project was funded by Google--just that the author was a Google employee at some point.
That disclaimer appears at the bottom of every project that Google doesn't feel like officially supporting. Even the tcmalloc project has that disclaimer at the bottom and it's used in every single process running in Google datacenters right now. I think you'd be hard pressed to really make the case that WUFFS is not funded by Google.
> That disclaimer appears at the bottom of every project that Google doesn't feel like officially supporting.
Based on my understanding from conversations with Google staff, it's a disclaimer that's required if anyone at Google wants to write "personal" code & release it (under an Open Source license) while employed by Google.
(Unless they choose to undertake a much more paperwork-intensive alternate process with different requirements & implications.)
Personal code is different to code developed for reasons that were directed by Google (which they have no problem saying is unsupported, e.g. any version of Android older than 3 minutes or something :D )--which is why this disclaimer can be seen on such odd non-corporate things as retro-computing related projects.
Of course, sometimes such projects do become something Google wants to use (maybe WUFFS falls into this category)--so I expect we'll see more retro computing support on Stadia any day now... :D
90% of zero-days could be stopped at the front door by file format checkers doing static analysis on popular file formats (like ZIP, MS-CFB, Office, image, PDF) exchanged via message/email to reduce semantic gaps in the file format and weird-machine ambiguities that will inevitably be abused by attackers.
The problem is simple. Most codecs (and even vulnerable anti-virus software) were written in a time when Postel's law was the norm. It's much easier to write a file format checker as defense-in-depth for the vulnerable codec than to rewrite the codec, especially since a codec's interface typically can't expose policy decisions like a checker's interface can.
As a community, we could solve this problem tomorrow.
However, the file format checkers to defend don't exist, because the major email/message providers don't want to invest in them, because nobody would see this work. Even if we build them, they don't want to invest in tuning the false positive rate, because people want lax security not strict security on all message/email attachments they open.