[dinglejungle]

The title of this submission ("Fuzzing makes memory-unsafe languages untenable") makes no sense[1] and is not found anywhere in the linked article.

[1] perhaps the intended meaning of the title was "fuzzing shows that memory-unsafe languages are untenable", but that's certainly not the meaning of the current title

[masklinn]

It's the tagline the author used on Twitter: https://twitter.com/justincormack/status/1153060402495991808 and seemed clearer than the actual title.

> perhaps the intended meaning of the title was "fuzzing shows that memory-unsafe languages are untenable", but that's certainly not the meaning of the current title

No, fuzzing makes these languages untenable because it provides a tool for automating memory unsafety issues. Without mature fuzzing tools, most of these issues can remain unfound, but fuzzing surfaces them — and their potential for exploitation — rather easily.

It's a bit of a "security by obscurity" thing, but I think there's a point to this view: fuzzing takes the existing crack / fault of memory unsafety[0] and blasts it open so wide you can get a truck through.

[nullc]

> fuzzing makes these languages untenable because it provides a tool for automating memory unsafety issues. Sans mature fuzzing tools, most of these issues can remain unfound,

<Pointy-haired Boss>Fuzzing is now forbidden in our offices. Next problem?</phb>

[snaky]

Jokes aside, Pointy-haired Boss ask why should we care about security issues from the business standpoint. Do we know any company went out of business due the security breach?

[jusob]

Yes, last month for example: https://healthitsecurity.com/news/amca-files-chapter-11-afte...

[gmueckl]

Not yet, but fines due to GDPR violations might have that effect in the near future. That only requires that a security hole leads to a massive data breach.

[dinglejungle]

Ah, I see. It would help if the article made that argument a bit more explicitly, as I totally missed that interpretation the first time through.

[jplayer01]

It makes sense to me. The article is all about how a significant percentage of all vulnerabilities are memory-related. With the rise of fuzzing, finding these vulnerabilities has become far easier to do and to automate (you can run fuzzers 24/7 and come up with plenty of attack vectors given enough time). So his final conclusion is "start to explore and invest in ways to replace every legacy C dependency you are currently using. Write a deprecation roadmap. Cut down your dependencies on Linux distributions." And from that logical chain to the conclusion follows the title.

It could be seen as a form of editorializing though, so it could be argued that it should be changed to the original just based on that.

[masklinn]

> It could be seen as a form of editorializing though, so it could be argued that it should be changed to the original just based on that.

FWIW it's the title / tagline the author themselves used when they posted the article on twitter, and I thought it was much clearer than the "official" title of "Fuzz rising".

[jplayer01]

https://twitter.com/justincormack/status/1153060402495991808...

Indeed. I prefer this title over "Fuzz rising" as well.

[jononor]

Fuzzing is a tool that can be used to find vulnerabilities. This can happen by good-intended actors (which is what there is the most data about, as referenced in the post). But it can (and certainly is) also used bad actors. And there is always a bunch of code out there that goes unpatched for extended amounts of time. So even with code that is actively fuzzed and fixed, there are usually vulnerability windows for deployed software. And with memory unsafe languages, we tend to continue to produce such vulnerabilities.