5 ms·

Remember how cloudflare (in 2017) leaked pretty much everyone's secret tokens in search engine cache due to a simple buffer overflow? Yeah, that wouldn't have h

Remember how cloudflare (in 2017) leaked pretty much everyone's secret tokens in search engine cache due to a simple buffer overflow? Yeah, that wouldn't have happened with Rust

codr7 1y ago
Yeah I know, if only we could rewrite the entire world in Rust everything would be rainbows and unicorns. But it's not going to happen, deal with it.
lelanthran 1y ago
Remember that the most expensive exploit the world has ever seen was in a memory safe GC language? My argument is that you are missing the point: the point is that a larger attack surface enables more exploits regardless of language. When using a language that has tremendous friction in expanding the attack surface you tend to have a small attack surface as a result. Theres obviously a crossover point where you'd be safer with a memory safe language and a larger attack surface than with a memory unsafe language and a minuscule attack surface.
- lmm 1y ago
  > 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?
  - throw1111221 1y ago
    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.
  - lelanthran 1y ago
    > 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).
    - lmm 1y ago
      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.
      - lelanthran 1y ago
        > 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.
guappa 1y ago
I've seen segmentation faults in java, go, python. All you need is a bug in a hidden library :)
- MrJohz 1y ago
  A segfault won't leak sensitive data, though.
  - packetlost 1y ago
    Segfaults, no. Usually they're a null dereference, but it could also be an out of bounds read on an array, which can leak data.
    - MrJohz 1y ago
      Not if it's segfaulting, no. That's the point of a segfault.
      - packetlost 1y ago
        This just isn't true. A segfault happens when an access happens outside of the memory space of the process, such as a 0x00 pointer. Pages are typically allocated in 4kB chunks and allocators will try to minimize syscalls to allocate more virtual pages by trying to maximize reuse of existing pages. All of this results in an out of bounds access being trivial and hard to detect without additional code to check: https://paste.sr.ht/~chiefnoah/be5864cb0d78d6691fe3e36946709f17b3aa934a https://paste.sr.ht/~chiefnoah/be5864cb0d78d6691fe3e36946709... A runaway loop can access program memory until it segfaults pretty easily.
  - guappa 1y ago
    The problem is that the code is incorrect and what happens instead/before the segfault, not the segfault itself :) What happens before/instead is normally worth a CVE.

Remember how cloudflare (in 2017) leaked pretty much everyone's secret tokens in search engine cache due to a simple buffer overflow? Yeah, that wouldn't have happened with Rust

codr7 1y ago

Yeah I know, if only we could rewrite the entire world in Rust everything would be rainbows and unicorns. But it's not going to happen, deal with it.

lelanthran 1y ago

Remember that the most expensive exploit the world has ever seen was in a memory safe GC language? My argument is that you are missing the point: the point is that a larger attack surface enables more exploits regardless of language. When using a language that has tremendous friction in expanding the attack surface you tend to have a small attack surface as a result. Theres obviously a crossover point where you'd be safer with a memory safe language and a larger attack surface than with a memory unsafe language and a minuscule attack surface.

lmm 1y ago
> 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?
- throw1111221 1y ago
  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.
- lelanthran 1y ago
  > 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).
  - lmm 1y ago
    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.
    - lelanthran 1y ago
      > 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.

guappa 1y ago

I've seen segmentation faults in java, go, python. All you need is a bug in a hidden library :)

MrJohz 1y ago
A segfault won't leak sensitive data, though.
- packetlost 1y ago
  Segfaults, no. Usually they're a null dereference, but it could also be an out of bounds read on an array, which can leak data.
  - MrJohz 1y ago
    Not if it's segfaulting, no. That's the point of a segfault.
    - packetlost 1y ago
      This just isn't true. A segfault happens when an access happens outside of the memory space of the process, such as a 0x00 pointer. Pages are typically allocated in 4kB chunks and allocators will try to minimize syscalls to allocate more virtual pages by trying to maximize reuse of existing pages. All of this results in an out of bounds access being trivial and hard to detect without additional code to check: https://paste.sr.ht/~chiefnoah/be5864cb0d78d6691fe3e36946709f17b3aa934a https://paste.sr.ht/~chiefnoah/be5864cb0d78d6691fe3e36946709... A runaway loop can access program memory until it segfaults pretty easily.
- guappa 1y ago
  The problem is that the code is incorrect and what happens instead/before the segfault, not the segfault itself :) What happens before/instead is normally worth a CVE.