6 ms·

> We have built an extensive set of proprietary fuzzing tools for KVM. We also do a thorough code review looking specifically for security issues each time we a

> We have built an extensive set of proprietary fuzzing tools for KVM. We also do a thorough code review looking specifically for security issues each time we adopt a new feature or version of KVM. As a result, we've found many vulnerabilities in KVM over the past three years. About half of our discoveries come from code review and about half come from our fuzzers. Why aren't these tools being open sourced?

devoply 10y ago
Maybe because they think it's a competitive advantage.
- SEJeff 10y ago
  More likely it is just heavily integrated with internal google tooling like chubby and borg. I suspect they still use American Fuzzy Lop[1] for much of their fuzzing even if they wrote some of it from scratch. The Linux Foundation's Core Infrastructure Initiative's[2] "Fuzzing Project" is more or less continuous integration running AFL[3] [1] http://lcamtuf.coredump.cx/afl/ http://lcamtuf.coredump.cx/afl/ [2] https://www.coreinfrastructure.org/grants https://www.coreinfrastructure.org/grants [3] https://fuzzing-project.org/ https://fuzzing-project.org/
cpeterso 10y ago
Because the fuzzers can be used by blackhats to find vulnerabilities to be exploited. The blackhats surely write their own fuzzers, but why give them a head start?
- SEJeff 10y ago
  Say it with me, "Security through obscurity is no security at all". Surely you'd know this working for Mozilla :) Probably due to business reasons in that it isn't meant to be a general purpose fuzzer and is likely tied to internal google infra.
  - felipemnoa 10y ago
    Not sure why you are getting down-voted. "Security through obscurity is no security at all" is a very true statement. It is the reason why the code for AES is known to everybody.
    - dgfgfdagasdfgfa 10y ago
      Except it's not true. Obscurity still has cost to decipher, and the cost may be the ends you're looking for. Not all security-oriented goals are make-or-break. Hell, if you're talking about a time scale of hours (not uncommon with 0-days) even using a trivial cypher could slow people (attempting to understand (and then fix) your vulnerability) down for long enough to "get away" with the data/transfer/rootkit/whatever. Obfuscation has its role; it's to retard understanding, not to prevent understanding.
      - kajecounterhack 10y ago
        Obfuscation as a way to prevent copyright violation makes sense. Obfuscation as a way to purposefully hide security holes is terrible. "Security through obscurity is not real security" is true, and has nothing to do with obfuscation in general. It has more to do with auditability. Real security has a quantifiable difficulty to break through. Security through obscurity means the quantity of effort to needed to break through is an unknown. Example: We do know what it takes to break bcrypt. So if you've implemented bcrypt for security, great. Not obscure, but known to be safe. We don't know how long it'll take random black hat to find out you're storing passwords in plaintext but hiding the fact cleverly. If you release your source code auditors / community can see quickly that "oh storing plaintext passwords is a bad idea" and fix the bug. If you don't you might not know you're vulnerable and the obscurity will ultimately cost you for your ineptitude.
        londons_explore 10y ago
        Hashing algorithms have historically been mostly obscurity. It turns out we're really good at coming up with functions we think are one way and later find aren't. MD4 and SHA0 were both once believed to be good...
andyhonig 10y ago
This is a valid question. Syzkaller is definitely one such tool that is open source, but the tool we've been using for the longest is internal only. The reason it's not open source is because it's built on a lot of internal tools and it would be hard to separate out those dependencies. For example it relies on our custom VMM. We've discussed refactoring it so that we could get rid of the dependencies and open sourcing it, but that work has to be balanced with other priorities.
strstr 10y ago
Some of the tools have been: https://github.com/google/syzkaller https://github.com/google/syzkaller

devoply 10y ago

Maybe because they think it's a competitive advantage.

SEJeff 10y ago
More likely it is just heavily integrated with internal google tooling like chubby and borg. I suspect they still use American Fuzzy Lop[1] for much of their fuzzing even if they wrote some of it from scratch. The Linux Foundation's Core Infrastructure Initiative's[2] "Fuzzing Project" is more or less continuous integration running AFL[3] [1] http://lcamtuf.coredump.cx/afl/ http://lcamtuf.coredump.cx/afl/ [2] https://www.coreinfrastructure.org/grants https://www.coreinfrastructure.org/grants [3] https://fuzzing-project.org/ https://fuzzing-project.org/

cpeterso 10y ago

Because the fuzzers can be used by blackhats to find vulnerabilities to be exploited. The blackhats surely write their own fuzzers, but why give them a head start?

SEJeff 10y ago
Say it with me, "Security through obscurity is no security at all". Surely you'd know this working for Mozilla :) Probably due to business reasons in that it isn't meant to be a general purpose fuzzer and is likely tied to internal google infra.
- felipemnoa 10y ago
  Not sure why you are getting down-voted. "Security through obscurity is no security at all" is a very true statement. It is the reason why the code for AES is known to everybody.
  - dgfgfdagasdfgfa 10y ago
    Except it's not true. Obscurity still has cost to decipher, and the cost may be the ends you're looking for. Not all security-oriented goals are make-or-break. Hell, if you're talking about a time scale of hours (not uncommon with 0-days) even using a trivial cypher could slow people (attempting to understand (and then fix) your vulnerability) down for long enough to "get away" with the data/transfer/rootkit/whatever. Obfuscation has its role; it's to retard understanding, not to prevent understanding.
    - kajecounterhack 10y ago
      Obfuscation as a way to prevent copyright violation makes sense. Obfuscation as a way to purposefully hide security holes is terrible. "Security through obscurity is not real security" is true, and has nothing to do with obfuscation in general. It has more to do with auditability. Real security has a quantifiable difficulty to break through. Security through obscurity means the quantity of effort to needed to break through is an unknown. Example: We do know what it takes to break bcrypt. So if you've implemented bcrypt for security, great. Not obscure, but known to be safe. We don't know how long it'll take random black hat to find out you're storing passwords in plaintext but hiding the fact cleverly. If you release your source code auditors / community can see quickly that "oh storing plaintext passwords is a bad idea" and fix the bug. If you don't you might not know you're vulnerable and the obscurity will ultimately cost you for your ineptitude.
      - londons_explore 10y ago
        Hashing algorithms have historically been mostly obscurity. It turns out we're really good at coming up with functions we think are one way and later find aren't. MD4 and SHA0 were both once believed to be good...

andyhonig 10y ago

This is a valid question. Syzkaller is definitely one such tool that is open source, but the tool we've been using for the longest is internal only. The reason it's not open source is because it's built on a lot of internal tools and it would be hard to separate out those dependencies. For example it relies on our custom VMM. We've discussed refactoring it so that we could get rid of the dependencies and open sourcing it, but that work has to be balanced with other priorities.

strstr 10y ago

Some of the tools have been: https://github.com/google/syzkaller https://github.com/google/syzkaller