5 ms·

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 b

by 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."
- desc 7y ago
  > 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. And yet, Oracle still has some market share.
- saagarjha 7y ago
  Encryption has mathematical guarantees on its resistance against brute-forcing. Security by obscurity just makes it harder for white hats to help you and lets nation states and other determined attackers exploit you secretly.
  - 283b 7y ago
    If by brute force you mean checking the entire key space, fuzzing can be made to sound quite similar to encryption. There is a specific program path, or "key", that leads to a crash. Fuzzers attempt to search all paths in a somewhat intelligent manner to find the "key" path that leads to a crash. We can inhibit the fuzzers ability to find the key by increasing the search space by adding more paths. The way in which this paper adds paths takes advantages of the way intelligent fuzzers explore the path space to make it even more difficult to search the entire path space.
    - feanaro 7y ago
      The problem is that there isn't a single key in this case, there are many. If there was just a single key to begin with, fuzzing would not be very fruitful for any moderately+ complex program since finding that single path would already be very hard (and therefore has a high cost/benefit). What fuzzification actually enables is to hide more keys (crashes) from a constant amount of (current) effort. Those crashes are still there and now there are more of them, waiting for someone to find them with an alternative method or simply by buying more fuzzing equipment to scale horizontally.
- SCHiM 7y ago
  2./2.1./4. Yes this is true, and that's exactly where root of my problem with this direction of research lies. The incentives of software vendors are partially misaligned with those of the users. A vendor will want to maximize their profit, if a tool that implements this research allows them to be lazy then en-masse they will (ab)use it. 3. Software is layered, if every layer of your electron app starts using this type of obfuscation you will notice the slowdown. 1. I think there's an underlying assumption we both make about this research: it will increase the costs of finding exploits, but it will definitively not prevent a skilled attacker. I also don't think it absolutely disqualifies anyone who's already able to craft an exploit, perhaps it will take them longer but anyone with the reversing chops to abuse an aslr weakness can figure out how to patch out or reverse the jumptables. With that in mind, it comes back at the question: Is it worth it? Increase the costs for an attacker but simultaneously adding an incentive for vendors to be lazy, an chose a cheap band-aid bolted-on-security approach as opposed to what we all know is the eventual (expensive) fix for memory related security problems? I still think: hell no, don't make this stuff available, invest resources in alternative mitigations if not in outright solving the issue.
tptacek 7y ago
As you can plainly see from the paper, this is a form of full-blown obfuscation --- it's post-compilation program transformation to inject small proof of work functions entwined with program logic, to inject new branches and jump tables, and other things. Their goal isn't to make static analysis impossible, but the underlying CS they're invoking to accomplish their goal is the same as obfuscation. Nothing that they're doing would be a "minimal" hindrance to people employing fuzzers. Rather, it all seems like an extreme pain in the ass, and it would doubtlessly deter people from fuzzing. My guess is that the authors likely share your opinion of the utility of anti-fuzzing. This is (literally) a science project, not an advertisement for a product. In the scientific context, that the most popular current-generation fuzzing tools can be straightforwardly retarded through these techniques is an important observation.
283b 7y ago
On 2.1, I"m not sure this is security through obscurity. I can send a malicious individual a link to this paper saying I used these techniques on my binary but fuzzing will still be more difficult. Just like encryption takes my message and jumbles it up to "obscure it", this technique is adding slowdowns and false paths to hinder the fuzzer. Knowing my message is encrypted doesn't make it any easier to read, just like knowing my binary has been fuzzification-ified doesn't make it any easier to fuzz. The only thing that would help is giving you the key to my message, or program paths with added complexity to throw off the fuzzer.
- a1369209993 7y ago
  If you have the source code[0], you can compile your own version without fuzzification, and any attacks you find will work just as well on the fuzzified executable. This is not true of eg ASLR. If you don't have the source code, it's security through obscurity. 0: Note that obfuscator output is not source code.
dang 7y ago
When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

by SCHiM 7y ago

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."

desc 7y ago
> 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. And yet, Oracle still has some market share.
saagarjha 7y ago
Encryption has mathematical guarantees on its resistance against brute-forcing. Security by obscurity just makes it harder for white hats to help you and lets nation states and other determined attackers exploit you secretly.
- 283b 7y ago
  If by brute force you mean checking the entire key space, fuzzing can be made to sound quite similar to encryption. There is a specific program path, or "key", that leads to a crash. Fuzzers attempt to search all paths in a somewhat intelligent manner to find the "key" path that leads to a crash. We can inhibit the fuzzers ability to find the key by increasing the search space by adding more paths. The way in which this paper adds paths takes advantages of the way intelligent fuzzers explore the path space to make it even more difficult to search the entire path space.
  - feanaro 7y ago
    The problem is that there isn't a single key in this case, there are many. If there was just a single key to begin with, fuzzing would not be very fruitful for any moderately+ complex program since finding that single path would already be very hard (and therefore has a high cost/benefit). What fuzzification actually enables is to hide more keys (crashes) from a constant amount of (current) effort. Those crashes are still there and now there are more of them, waiting for someone to find them with an alternative method or simply by buying more fuzzing equipment to scale horizontally.
SCHiM 7y ago
2./2.1./4. Yes this is true, and that's exactly where root of my problem with this direction of research lies. The incentives of software vendors are partially misaligned with those of the users. A vendor will want to maximize their profit, if a tool that implements this research allows them to be lazy then en-masse they will (ab)use it. 3. Software is layered, if every layer of your electron app starts using this type of obfuscation you will notice the slowdown. 1. I think there's an underlying assumption we both make about this research: it will increase the costs of finding exploits, but it will definitively not prevent a skilled attacker. I also don't think it absolutely disqualifies anyone who's already able to craft an exploit, perhaps it will take them longer but anyone with the reversing chops to abuse an aslr weakness can figure out how to patch out or reverse the jumptables. With that in mind, it comes back at the question: Is it worth it? Increase the costs for an attacker but simultaneously adding an incentive for vendors to be lazy, an chose a cheap band-aid bolted-on-security approach as opposed to what we all know is the eventual (expensive) fix for memory related security problems? I still think: hell no, don't make this stuff available, invest resources in alternative mitigations if not in outright solving the issue.

tptacek 7y ago

As you can plainly see from the paper, this is a form of full-blown obfuscation --- it's post-compilation program transformation to inject small proof of work functions entwined with program logic, to inject new branches and jump tables, and other things. Their goal isn't to make static analysis impossible, but the underlying CS they're invoking to accomplish their goal is the same as obfuscation. Nothing that they're doing would be a "minimal" hindrance to people employing fuzzers. Rather, it all seems like an extreme pain in the ass, and it would doubtlessly deter people from fuzzing. My guess is that the authors likely share your opinion of the utility of anti-fuzzing. This is (literally) a science project, not an advertisement for a product. In the scientific context, that the most popular current-generation fuzzing tools can be straightforwardly retarded through these techniques is an important observation.

283b 7y ago

On 2.1, I"m not sure this is security through obscurity. I can send a malicious individual a link to this paper saying I used these techniques on my binary but fuzzing will still be more difficult. Just like encryption takes my message and jumbles it up to "obscure it", this technique is adding slowdowns and false paths to hinder the fuzzer. Knowing my message is encrypted doesn't make it any easier to read, just like knowing my binary has been fuzzification-ified doesn't make it any easier to fuzz. The only thing that would help is giving you the key to my message, or program paths with added complexity to throw off the fuzzer.

a1369209993 7y ago
If you have the source code[0], you can compile your own version without fuzzification, and any attacks you find will work just as well on the fuzzified executable. This is not true of eg ASLR. If you don't have the source code, it's security through obscurity. 0: Note that obfuscator output is not source code.

dang 7y ago

When disagreeing, please reply to the argument instead of calling names. "That is idiotic; 1 + 1 is 2, not 3" can be shortened to "1 + 1 is 2, not 3." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html