[nothrabannosir]

As far as I understand the bug, this is not about running untrusted code (but: a parsing error resulting in state corruption). Unless you refer to the 3rd party lib (7z), used by virus scanners, to analyse rar files. But typically "untrusted code" means code that was supplied "at runtime", not at compile time (like a lib), so e.g. if a virus scanner would actually execute a .exe to evaluate its effects, or run javascript found in a webpage.

To be fair to virus scanner vendors, the only way to mitigate this kind of bug is NIH: don't use 3rd party libs, implement everything yourself. But then, of course, without bugs yourself, as well :)

[pfg]

> To be fair to virus scanner vendors, the only way to mitigate this kind of bug is NIH: don't use 3rd party libs, implement everything yourself. But then, of course, without bugs yourself, as well :)

That is not the only way to mitigate such vulnerabilities. AV vendors have had plenty of time to work on sandboxing parts of their scan engines that have repeatedly been found to have vulnerabilities like this one. Somehow we've arrived at a point where no one would recommend using a browser that doesn't utilize sandboxing to some degree, but when it comes to security products, you can count yourself lucky if they don't just run that code as SYSTEM. That should really tell you all you need to know about the state of the AV industry.

[RaleyField]

> no one

Plenty of people recommend Firefox despite it sharing processes between tabs. More than 10 years after MS sandboxed IE.

[infogulch]

> the only way to mitigate this kind of bug is NIH

Or, you know, conduct audits of open source libraries they use and contribute fixes back.

[jessaustin]

It is a very blurry line between running strange code and running library code against strange data. Mostly though, I'm trying to say that AV boxes should be outside the firewall.