6 ms·

Fuzzification: Anti-Fuzzing Techniques [pdf]

93 points by kens 7y ago

dayynn 7y ago
Hmu for questions! (Daniel Pagan)
- saagarjha 7y ago
  How do you see your work being used? I only skimmed the paper, but it seems like Fuzzification hinders fuzzing but doesn't actually solve the issues that fuzzing would expose, which makes it seem ripe for misuse by "lazy" teams that aren't willing to fix the underlying issues but see it as a way to obfuscate their vulnerabilities away. For open source projects I can see attackers just fuzzing unmitigated binaries they compile themselves and translating these techniques to release versions, and for closed source projects security is predicated on the original authors running fuzzers themselves and actually acting on the results they find (which has historically been a smaller and less motivated group in fixing vulnerabilities).
  - dayynn 7y ago
    There is definitely a lot of considerations that arise with this form of releasing software. It does not fix bad code and should not be used as the only security consideration for a codebase. I could see this being incorporated into a closed source project that has a good testing and code review pipeline as well as regular third party pentests on a release of the software that does not use fuzzification. From a project motivation standpoint, we were examining the internals of fuzzers and found that these techniques could be extremely effective. Right now the project is just academic research and no projects currently use this technology.
- clfs 7y ago
  What would you say to someone who was worried fuzzification would introduce additional vulnerabilities? For example, Section 5 reads "To be specific, FUZZIFICATION changes the original condition (value == 12345) to (CRC_LOOP(value) == OUTPUT_CRC) (at line 20)." This is a dangerous bug, since it's trivial to find tons of different values with the desired checksum.
  - dayynn 7y ago
    At this point this research is purely academic, so the scope of it was simply to hinder fuzzers while minimizing overhead for users. Like all code, this would also need to be evaluated for correctness (just like your comment!). This is introducing new techniques to the already established field of anti-fuzzing
- Ded7xSEoPKYNsDd 7y ago
  I've seen a lot of criticism of this approach - hiding vulnerabilities, instead of actually fixing them. Other mitigations actually prevent exploits (e.g. the combination of NX and ASLR raises the bar for getting code execution: suddenly interactivity and an address leak are required in addition to a stack-based overflow) whereas your mitigation (?) just sweeps bugs under the rug. From my own skimming of the paper, the discussion of 'why?' boils down roughly to 'exploits are sometimes used for bad things'. Do you believe your approach will actually improve the security of any systems, or will it just allow lazy vendors to hide their shallow bugs - leaving them to the most motivated (e.g. nation-state) adversaries?
- nickpsecurity 7y ago
  I figured you were going in a similar direction as obfuscation-oriented security (eg randomizations) to effortlessly add effort for attackers. I knew you were going to say tested, proprietary applications as a potential target. The ideas were fun to read with clearly plenty of talent going into it. I'm with the naysayers, though, in that it's probably not a great idea or at best might be a good supplement to something else. If you or anyone else is interested, the strongest approaches when I last looked at everything tried to create full memory safety or do properties like CFI with strong assurance. Softbound+CETS, SafeCODE, and Data-Flow Integrity focused on memory safety with less performance hit. Code-Pointer Integrity with segments had low overhead. Some people were talking about S+C combined with DFI but overhead was crazy. I encourage folks to look at that kind of work, look at whatever [fast] mechanisms are in modern hardware, look at any software improvements in literature, and try to reduce the overhead of techniques like that (esp in combination). Similar to you, I proposed we use techniques like Softbound+CETS on proprietary, closed applications to increase their security at a performance loss that can be made up for with cheap hardware. And then sell them on that saying security personnel cost way more than a few more rack servers.
Jaxan 7y ago
Interesting idea. It makes you wonder how to best spend your time: writing better software (ie less bugs), or invest time in fuzzification (ie less exploits).
- moyix 7y ago
  Well, fuzzification is implemented as a compiler pass, so I feel like this is asking whether it's better to invest time writing better software or using -O3. In principle you wouldn't need to spend developer resources on it.
desc 7y ago
This is by definition impossible to do without changing the behaviour of the code being 'anti-fuzzed'. This therefore risks introducing bugs which are then much harder to fix, and complicates debugging of issues in the original code which may show up in production. Note that whether or not that behaviour happens to be undefined in the source language is irrelevant. Undefined behaviour still tends to manifest in a few recognisable ways, which this would then obfuscate. While an interesting academic exercise, this has negative value to the software industry. I bet it'll still see a lot of use though. Reminds me a bit of people trying to 'fix' errors with an empty `catch` block...
SCHiM 7y ago
My opinion: this is an idiotic thing to do. I got triggered in a huge way by this for a number of reasons: 1. An attacker skilled enough to perform black box binary fuzzing, and create a testing harnass. Will only be minimally hindered by anything less than full blown obfuscation. 2. This approach aims to 'fix' the problem of someone looking and testing your code, it's hiding (not fixing!) a symptom of the problem: you wrote vulnerable code. Why not spend this effort on improving existing and actually helpfull mitigations such as dep, aslr, re-linking and pledge systems? Even better, why not re-write error prone or complex code in a safe language?! 2.1. This is security through obscurity, the vulnerable code is still there, someone will find it. 3. End users will be inconvenienced because obfuscation implies inefficient code. 4. This widens the gap between white hat research (not funded, often done for reputation) and black hat research which is worth good money for a quality exploit and therefore more sustainable for researchers making it their day job.
- Spivak 7y ago
  1. Yes but think of all the attackers who aren't skilled enough to do that. Making the barrier to entry higher is exactly what you want. 2. Well yeah! If I write vulnerable code I would want to make sure it was as difficult as possible to discover. Who wants easy to discover vulnerabilities? Anyone who I want looking at my code will have the source and can build without obfuscation and fuzzing protection. 2.1 If I'm a big enough target sure, but if I make it as annoying and difficult to work with my software as possible the hope is that you'll go somewhere else. 3. The performance impact is super mild and completely unnoticeable on anything that works in human time. The slight performance hit to protect your IP is a no brainier calculation. Nvidia famously implores absolutely crazy obfuscation on their chips and they're still the market leader on speed. 4. Companies that use these kinds of techniques don't recognize a difference between the two. If you're not employed or contracted by them and you're looking at their code you are the adversary. I think it's funny that when we talk about encryption we talk about its strength like "an attacker with a supercomputer X years to brute-force it" but when it comes to things like this we say "security through obscurity! Worthless!" instead of "the total population of people with the skills to even begin to find vulnerabilities is professional security researches and could all fit comfortably in a mid-sized event venue."
feanaro 7y ago
If this ever gets popular, it is just one more reason to strongly prefer free software, I guess, since it can't be "protected" with this.
- hannob 7y ago
  I have some bad news for you: There are developers of the Linux kernel who deploy anti-fuzzing techniques (CRCs, which is a surprisingly effective anti-fuzzing-technique) and think it's a good idea to reduce the number of people reporting fuzzing-bugs: https://marc.info/?l=linux-fsdevel&m=152410224900838&w=2 https://marc.info/?l=linux-fsdevel&m=152410224900838&w=2
  - saagarjha 7y ago
    I didn't draw that sort of conclusion at all from that email: isn't it just saying that the filesystem has a CRC (for reliability, presumably, not because they are trying to deter fuzzers) and they're frustrated that they keep getting fuzzer reports for things that don't pass that check (and don't matter because they're caught by the CRC)? They have a specific suite of CRC-aware fuzzers that they're still using.
  - feanaro 7y ago
    The other poster already handled the issue that this is not talking about the same thing, but filesystem-specific CRCs. But why would you think it a good thing if less people reported unfixed bugs?
- 283b 7y ago
  What prevents free software from using this technique?
  - saagarjha 7y ago
    Nothing, but attackers can just compile their own versions without these obfuscations to fuzz.
  - feanaro 7y ago
makomk 7y ago
You know what's probably a better way of making it harder to find bugs in your code using fuzzing? Fuzz it yourself and actually fix the damn bugs.
- 283b 7y ago
  In practice I think this is akin to asking someone to write bug free code the first time. Regardless of this specific paper, assuming all bugs can be found and fixed is not a sound assumption. I'm happy to see techniques that correctly assume undetected bugs exist, and propose solutions to that problem. (Other than asking developers to just find and fix all the bugs, which again, is not possible)
  - makomk 7y ago
    You don't need to find and fix all the bugs to make fuzzing less useful for an attacker - just finding and fixing the low-hanging fruit that's easily detected by fuzzing is enough to make it a lot less productive for everyone else.
- nickpsecurity 7y ago
  The state-of-the-art analyzers and fuzzers are also really good. Especially the ones setup for no false positives. Bar is lower than ever.
- segmondy 7y ago
  One, these guys needed to write a paper. They also can't write a tool that can fix all bugs, but they can write a tool that makes it harder to find for others which is what they did. Last, you never know who else could build on this idea and where they might take it. So relax. :)
- jplayer01 7y ago
  I love how their justification is: > Unfortunately, advanced fuzzing techniques can also be used by malicious attackers So the solution is to make it harder to find bugs instead of finding and fixing them, which affects everybody, not just "attackers". This is like the companies who'll sue or ban researchers for finding bugs in their stuff. Or programmers on HN who criticize researchers for publicizing vulnerabilities when companies refuse to fix them and give them the runaround. I can already see companies like Apple implementing something like this instead of putting in the required time, effort and money to fix issues, while simultaneously villifying legitimate security researchers who look for vulnerabilities in their products.
zelon88 7y ago
Good read, but there is a huge elephant in the room. In many cases vulnerabilities come from complex, messy, disorganized, or just poorly written code. Assuming that the "fuzzification" techniques are implemented by the same developer who wrote the original vulnerable code; how can we be sure that he isn't introducing MORE bugs in his fuzzified version? For example, if you have a product which is NOT currently vulnerable and add BranchTrap to it the likelihood that you're creating a vulnerability where one never existed before is insanely high. So you essentially created a code path for the fuzzer that never would have existed if you never tried to fool the fuzzer in the first place. Assuming two binaries, an original and a "fuzzified" version and an unlimited amount of time: Which version would have overall More vulnerable code paths? Probably the fuzzified version simply because it has more code. The point of producing two binaries is that one can be analyzed quickly and one slowly. But if your original code doesn't contain a vulnerability and the fuzzed version does your trusted party doesn't mean anything. This is not insignificant either. Time to fuzz an application no longer matters for the attacker. If he grinds on it long enough he will have a vuln that the authors aren't aware of (and can't/won't even find now). It doesn't matter if it takes 2 years to find a vuln in your code... Someone will do it.
ravenstine 7y ago
The things people will do to avoid doing actual work...

93 points by kens 7y ago

dayynn 7y ago

Hmu for questions! (Daniel Pagan)

saagarjha 7y ago
How do you see your work being used? I only skimmed the paper, but it seems like Fuzzification hinders fuzzing but doesn't actually solve the issues that fuzzing would expose, which makes it seem ripe for misuse by "lazy" teams that aren't willing to fix the underlying issues but see it as a way to obfuscate their vulnerabilities away. For open source projects I can see attackers just fuzzing unmitigated binaries they compile themselves and translating these techniques to release versions, and for closed source projects security is predicated on the original authors running fuzzers themselves and actually acting on the results they find (which has historically been a smaller and less motivated group in fixing vulnerabilities).
- dayynn 7y ago
  There is definitely a lot of considerations that arise with this form of releasing software. It does not fix bad code and should not be used as the only security consideration for a codebase. I could see this being incorporated into a closed source project that has a good testing and code review pipeline as well as regular third party pentests on a release of the software that does not use fuzzification. From a project motivation standpoint, we were examining the internals of fuzzers and found that these techniques could be extremely effective. Right now the project is just academic research and no projects currently use this technology.
clfs 7y ago
What would you say to someone who was worried fuzzification would introduce additional vulnerabilities? For example, Section 5 reads "To be specific, FUZZIFICATION changes the original condition (value == 12345) to (CRC_LOOP(value) == OUTPUT_CRC) (at line 20)." This is a dangerous bug, since it's trivial to find tons of different values with the desired checksum.
- dayynn 7y ago
  At this point this research is purely academic, so the scope of it was simply to hinder fuzzers while minimizing overhead for users. Like all code, this would also need to be evaluated for correctness (just like your comment!). This is introducing new techniques to the already established field of anti-fuzzing
Ded7xSEoPKYNsDd 7y ago
I've seen a lot of criticism of this approach - hiding vulnerabilities, instead of actually fixing them. Other mitigations actually prevent exploits (e.g. the combination of NX and ASLR raises the bar for getting code execution: suddenly interactivity and an address leak are required in addition to a stack-based overflow) whereas your mitigation (?) just sweeps bugs under the rug. From my own skimming of the paper, the discussion of 'why?' boils down roughly to 'exploits are sometimes used for bad things'. Do you believe your approach will actually improve the security of any systems, or will it just allow lazy vendors to hide their shallow bugs - leaving them to the most motivated (e.g. nation-state) adversaries?
nickpsecurity 7y ago
I figured you were going in a similar direction as obfuscation-oriented security (eg randomizations) to effortlessly add effort for attackers. I knew you were going to say tested, proprietary applications as a potential target. The ideas were fun to read with clearly plenty of talent going into it. I'm with the naysayers, though, in that it's probably not a great idea or at best might be a good supplement to something else. If you or anyone else is interested, the strongest approaches when I last looked at everything tried to create full memory safety or do properties like CFI with strong assurance. Softbound+CETS, SafeCODE, and Data-Flow Integrity focused on memory safety with less performance hit. Code-Pointer Integrity with segments had low overhead. Some people were talking about S+C combined with DFI but overhead was crazy. I encourage folks to look at that kind of work, look at whatever [fast] mechanisms are in modern hardware, look at any software improvements in literature, and try to reduce the overhead of techniques like that (esp in combination). Similar to you, I proposed we use techniques like Softbound+CETS on proprietary, closed applications to increase their security at a performance loss that can be made up for with cheap hardware. And then sell them on that saying security personnel cost way more than a few more rack servers.

Jaxan 7y ago

Interesting idea. It makes you wonder how to best spend your time: writing better software (ie less bugs), or invest time in fuzzification (ie less exploits).

moyix 7y ago
Well, fuzzification is implemented as a compiler pass, so I feel like this is asking whether it's better to invest time writing better software or using -O3. In principle you wouldn't need to spend developer resources on it.

desc 7y ago

This is by definition impossible to do without changing the behaviour of the code being 'anti-fuzzed'. This therefore risks introducing bugs which are then much harder to fix, and complicates debugging of issues in the original code which may show up in production. Note that whether or not that behaviour happens to be undefined in the source language is irrelevant. Undefined behaviour still tends to manifest in a few recognisable ways, which this would then obfuscate. While an interesting academic exercise, this has negative value to the software industry. I bet it'll still see a lot of use though. Reminds me a bit of people trying to 'fix' errors with an empty `catch` block...

SCHiM 7y ago

My opinion: this is an idiotic thing to do. I got triggered in a huge way by this for a number of reasons: 1. An attacker skilled enough to perform black box binary fuzzing, and create a testing harnass. Will only be minimally hindered by anything less than full blown obfuscation. 2. This approach aims to 'fix' the problem of someone looking and testing your code, it's hiding (not fixing!) a symptom of the problem: you wrote vulnerable code. Why not spend this effort on improving existing and actually helpfull mitigations such as dep, aslr, re-linking and pledge systems? Even better, why not re-write error prone or complex code in a safe language?! 2.1. This is security through obscurity, the vulnerable code is still there, someone will find it. 3. End users will be inconvenienced because obfuscation implies inefficient code. 4. This widens the gap between white hat research (not funded, often done for reputation) and black hat research which is worth good money for a quality exploit and therefore more sustainable for researchers making it their day job.

Spivak 7y ago
1. Yes but think of all the attackers who aren't skilled enough to do that. Making the barrier to entry higher is exactly what you want. 2. Well yeah! If I write vulnerable code I would want to make sure it was as difficult as possible to discover. Who wants easy to discover vulnerabilities? Anyone who I want looking at my code will have the source and can build without obfuscation and fuzzing protection. 2.1 If I'm a big enough target sure, but if I make it as annoying and difficult to work with my software as possible the hope is that you'll go somewhere else. 3. The performance impact is super mild and completely unnoticeable on anything that works in human time. The slight performance hit to protect your IP is a no brainier calculation. Nvidia famously implores absolutely crazy obfuscation on their chips and they're still the market leader on speed. 4. Companies that use these kinds of techniques don't recognize a difference between the two. If you're not employed or contracted by them and you're looking at their code you are the adversary. I think it's funny that when we talk about encryption we talk about its strength like "an attacker with a supercomputer X years to brute-force it" but when it comes to things like this we say "security through obscurity! Worthless!" instead of "the total population of people with the skills to even begin to find vulnerabilities is professional security researches and could all fit comfortably in a mid-sized event venue."

feanaro 7y ago

If this ever gets popular, it is just one more reason to strongly prefer free software, I guess, since it can't be "protected" with this.

hannob 7y ago
I have some bad news for you: There are developers of the Linux kernel who deploy anti-fuzzing techniques (CRCs, which is a surprisingly effective anti-fuzzing-technique) and think it's a good idea to reduce the number of people reporting fuzzing-bugs: https://marc.info/?l=linux-fsdevel&m=152410224900838&w=2 https://marc.info/?l=linux-fsdevel&m=152410224900838&w=2
- saagarjha 7y ago
  I didn't draw that sort of conclusion at all from that email: isn't it just saying that the filesystem has a CRC (for reliability, presumably, not because they are trying to deter fuzzers) and they're frustrated that they keep getting fuzzer reports for things that don't pass that check (and don't matter because they're caught by the CRC)? They have a specific suite of CRC-aware fuzzers that they're still using.
- feanaro 7y ago
  The other poster already handled the issue that this is not talking about the same thing, but filesystem-specific CRCs. But why would you think it a good thing if less people reported unfixed bugs?
283b 7y ago
What prevents free software from using this technique?
- saagarjha 7y ago
  Nothing, but attackers can just compile their own versions without these obfuscations to fuzz.
- feanaro 7y ago

makomk 7y ago

You know what's probably a better way of making it harder to find bugs in your code using fuzzing? Fuzz it yourself and actually fix the damn bugs.

283b 7y ago
In practice I think this is akin to asking someone to write bug free code the first time. Regardless of this specific paper, assuming all bugs can be found and fixed is not a sound assumption. I'm happy to see techniques that correctly assume undetected bugs exist, and propose solutions to that problem. (Other than asking developers to just find and fix all the bugs, which again, is not possible)
- makomk 7y ago
  You don't need to find and fix all the bugs to make fuzzing less useful for an attacker - just finding and fixing the low-hanging fruit that's easily detected by fuzzing is enough to make it a lot less productive for everyone else.
nickpsecurity 7y ago
The state-of-the-art analyzers and fuzzers are also really good. Especially the ones setup for no false positives. Bar is lower than ever.
segmondy 7y ago
One, these guys needed to write a paper. They also can't write a tool that can fix all bugs, but they can write a tool that makes it harder to find for others which is what they did. Last, you never know who else could build on this idea and where they might take it. So relax. :)
jplayer01 7y ago
I love how their justification is: > Unfortunately, advanced fuzzing techniques can also be used by malicious attackers So the solution is to make it harder to find bugs instead of finding and fixing them, which affects everybody, not just "attackers". This is like the companies who'll sue or ban researchers for finding bugs in their stuff. Or programmers on HN who criticize researchers for publicizing vulnerabilities when companies refuse to fix them and give them the runaround. I can already see companies like Apple implementing something like this instead of putting in the required time, effort and money to fix issues, while simultaneously villifying legitimate security researchers who look for vulnerabilities in their products.

zelon88 7y ago

Good read, but there is a huge elephant in the room. In many cases vulnerabilities come from complex, messy, disorganized, or just poorly written code. Assuming that the "fuzzification" techniques are implemented by the same developer who wrote the original vulnerable code; how can we be sure that he isn't introducing MORE bugs in his fuzzified version? For example, if you have a product which is NOT currently vulnerable and add BranchTrap to it the likelihood that you're creating a vulnerability where one never existed before is insanely high. So you essentially created a code path for the fuzzer that never would have existed if you never tried to fool the fuzzer in the first place. Assuming two binaries, an original and a "fuzzified" version and an unlimited amount of time: Which version would have overall More vulnerable code paths? Probably the fuzzified version simply because it has more code. The point of producing two binaries is that one can be analyzed quickly and one slowly. But if your original code doesn't contain a vulnerability and the fuzzed version does your trusted party doesn't mean anything. This is not insignificant either. Time to fuzz an application no longer matters for the attacker. If he grinds on it long enough he will have a vuln that the authors aren't aware of (and can't/won't even find now). It doesn't matter if it takes 2 years to find a vuln in your code... Someone will do it.

ravenstine 7y ago

The things people will do to avoid doing actual work...