> Remember that the most expensive exploit the world has ever seen was in a memory safe GC language?
No I don't, which exploit are you talking about? The most expensive exploit I can think of was caused by heartbleed which was in a memory unsafe language. The "most expensive software bug" (not an exploit) caused by turning off the safe overflow handler in the language being used can hardly be considered an indictment of language level safety either. So what exploit are you talking about?
Not the person you replied to, but they're probably talking about Log4j. It's a Java logging library that had a helpful feature where logging a special format string would pull code from a remote URL and execute it. So anywhere you can get a Java server to log something you can run arbitrary code. (Ex: by setting a malicious User-Agent.) Estimates say 93% of enterprise cloud environments where affected.
I suppose Stuxnet could also count, where the initial infection depends on the human curiosity of plugging an unknown usb drive into an air gapped system.
> No I don't, which exploit are you talking about?
Log4j
> The most expensive exploit I can think of was caused by heartbleed which was in a memory unsafe language.
Heartbleed was nowhere near as costly as Log4j. Last I checked, there was two orders of magnitude difference between the cost of fixing Log4j (which still isn't completely fixed for a few systems) than Heartbleed (which is completely fixed).
I wouldn't consider the remediation costs as being the costs of the exploit - that's more just a measurement of how widely used something is (if anything I'd say it should count for the other side - cost of exploitation divided by cost of remediation is a reasonable measure of how "bad" the bug was, because the cost of remediation is generally proportionate to the cost that was being saved in the first place). Heartbleed has the most expensive case of actual exploitation I can think of - the $73M JP Morgan hack. So far I haven't heard of any attackers actually using the log4j vulnerability.
> Log4j (which still isn't completely fixed for a few systems) than Heartbleed (which is completely fixed)
How are you counting that? There are definitely embedded systems out there running old versions of OpenSSL that will never be patched. Because there's no standard package management and vendoring dependencies is more common in the C world, it's probably less easy to get a list of vulnerable systems, but that doesn't mean the vulnerability isn't there.
> I wouldn't consider the remediation costs as being the costs of the exploit - that's more just a measurement of how widely used something is
Maybe you won't in general, but we're chatting on a thread about the threats of supply chain attacks.
Reading upthread, some GG...P thread espoused the idea that maybe the trade-off in using a memory-safe language with almost frictionless thirdy-party dependency might not always be worth it compared to a memory-unsafe language with very high friction for third-party dependencies.
In this context, the specific comment I replied to made a frankly asinine comment about how "this wouldn't happen in Rust", to which I felt compelled
to point out that a) More expensive breaches have occurred in memory safe languages, and b) Supply chain attacks have large dollar impacts anyway.
To add, there's also c) The majority of breaches are occurring irrespective of tech stacks.
No I don't, which exploit are you talking about? The most expensive exploit I can think of was caused by heartbleed which was in a memory unsafe language. The "most expensive software bug" (not an exploit) caused by turning off the safe overflow handler in the language being used can hardly be considered an indictment of language level safety either. So what exploit are you talking about?