
Fuzzification: Anti-Fuzzing Techniques [pdf] - kens
https://www.usenix.org/system/files/sec19fall_jung_prepub.pdf
======
makomk
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
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
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.

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

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

------
dayynn
Hmu for questions! (Daniel Pagan)

~~~
clfs
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
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

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

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

~~~
283b
What prevents free software from using this technique?

~~~
saagarjha
Nothing, but attackers can just compile their own versions without these
obfuscations to fuzz.

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

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

~~~
saagarjha
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
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
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.

