3 ms·

Are the AV vendor's code having the same problems that the old version of the file command had that lead to a rewrite on OpenBSD[1]? It seems that way with not

Are the AV vendor's code having the same problems that the old version of the file command had that lead to a rewrite on OpenBSD[1]? It seems that way with not doing the fuzzing of inputs comment, or is there a second problem because its the browser? 1) https://news.ycombinator.com/item?id=9439778 https://news.ycombinator.com/item?id=9439778

masklinn 10y ago
AV vendors are even worse, they don't just play fast and loose with incoming files they also fuck up other processes in the system, bundle de-secured versions of other software (e.g. Chrome) or enable security holes (remotely accessible local debuggers) by default. Check out issues reported by taviso on Google Zero: https://bugs.chromium.org/p/project-zero/issues/list?can=1&q=reporter%3Ataviso%40google.com https://bugs.chromium.org/p/project-zero/issues/list?can=1&q... Examples: https://bugs.chromium.org/p/project-zero/issues/detail?id=675 https://bugs.chromium.org/p/project-zero/issues/detail?id=67... or https://bugs.chromium.org/p/project-zero/issues/detail?id=773 https://bugs.chromium.org/p/project-zero/issues/detail?id=77... or https://bugs.chromium.org/p/project-zero/issues/detail?id=704 https://bugs.chromium.org/p/project-zero/issues/detail?id=70...
- Bartweiss 10y ago
  Yep. I got the feeling that Vess was hammering the browser hooks issue because it's the only one where blame can be shared outside of the AV vendor. Handing out privilege escalation and sandbox escape from your own crappy code isn't something that can be blamed on a shortage of external support. Nor, for that matter, is silently disabling other, better security products, which seems to be standard practice these days.
- Yoric 10y ago
  In Firefox, we've had a number of security issues created by AV. They tend to run as root, patch up our dynamic libraries in-memory, play man-in-the-middle on the network layer, deactivate security updates, rewrite security certificates, block entire processes at every disk access, .... Some of these practices might make sense if they had the resources to actually follow the update trains (in my experience, they don't, so Bad Consequences ensue). Some, I suspect, are due to them working in secrecy out of fear from other AV vendors – so much secrecy that we actually don't know what kind of APIs they need for their code to work more cleanly. Some suggest that they simply don't care about killing the performance of the entire browser. And I have seen at least one bug that showed a complete misunderstanding of how SSL works. I hear that the situation is improving. But for the moment, I'm not a big fan of reading crash reports and cleaning up after messes left by AV software.
- 0xfeba 10y ago
  The Security Now! episode over the Chromodo browser fiasco was hilarious, one of the best.
- Already__Taken 10y ago
  FYI on the project zero link, change issues from open to all.
  - masklinn 10y ago
    Ah yes fixed, I trimmed the URL a bit too much.
  - deleted 10y ago
    [deleted]
hannob 10y ago
Well, some people fuzzed file intensively (I was one of them). I won't claim it's bug-free, but I'd say it's probably pretty hard to find a memory corruption vuln in file these days. Nothing like that happened for most AV software (with probably the exception of clamav). But yeah, the situation is similar: Whenever you have a C software that parses lots of complex binary formats you have lots of potential for memory corruption.

masklinn 10y ago

AV vendors are even worse, they don't just play fast and loose with incoming files they also fuck up other processes in the system, bundle de-secured versions of other software (e.g. Chrome) or enable security holes (remotely accessible local debuggers) by default. Check out issues reported by taviso on Google Zero: https://bugs.chromium.org/p/project-zero/issues/list?can=1&q=reporter%3Ataviso%40google.com https://bugs.chromium.org/p/project-zero/issues/list?can=1&q... Examples: https://bugs.chromium.org/p/project-zero/issues/detail?id=675 https://bugs.chromium.org/p/project-zero/issues/detail?id=67... or https://bugs.chromium.org/p/project-zero/issues/detail?id=773 https://bugs.chromium.org/p/project-zero/issues/detail?id=77... or https://bugs.chromium.org/p/project-zero/issues/detail?id=704 https://bugs.chromium.org/p/project-zero/issues/detail?id=70...

Bartweiss 10y ago
Yep. I got the feeling that Vess was hammering the browser hooks issue because it's the only one where blame can be shared outside of the AV vendor. Handing out privilege escalation and sandbox escape from your own crappy code isn't something that can be blamed on a shortage of external support. Nor, for that matter, is silently disabling other, better security products, which seems to be standard practice these days.
Yoric 10y ago
In Firefox, we've had a number of security issues created by AV. They tend to run as root, patch up our dynamic libraries in-memory, play man-in-the-middle on the network layer, deactivate security updates, rewrite security certificates, block entire processes at every disk access, .... Some of these practices might make sense if they had the resources to actually follow the update trains (in my experience, they don't, so Bad Consequences ensue). Some, I suspect, are due to them working in secrecy out of fear from other AV vendors – so much secrecy that we actually don't know what kind of APIs they need for their code to work more cleanly. Some suggest that they simply don't care about killing the performance of the entire browser. And I have seen at least one bug that showed a complete misunderstanding of how SSL works. I hear that the situation is improving. But for the moment, I'm not a big fan of reading crash reports and cleaning up after messes left by AV software.
0xfeba 10y ago
The Security Now! episode over the Chromodo browser fiasco was hilarious, one of the best.
Already__Taken 10y ago
FYI on the project zero link, change issues from open to all.
- masklinn 10y ago
  Ah yes fixed, I trimmed the URL a bit too much.
- deleted 10y ago
  [deleted]

hannob 10y ago

Well, some people fuzzed file intensively (I was one of them). I won't claim it's bug-free, but I'd say it's probably pretty hard to find a memory corruption vuln in file these days. Nothing like that happened for most AV software (with probably the exception of clamav). But yeah, the situation is similar: Whenever you have a C software that parses lots of complex binary formats you have lots of potential for memory corruption.