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?

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.

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

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.