2 ms·

Hmu for questions! (Daniel Pagan)

by dayynn 7y ago

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.

Hmu for questions! (Daniel Pagan)

by dayynn 7y ago

Hmu for questions! (Daniel Pagan)

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.