4 ms·

"Memory unsafe languages" is maybe one percent of one percent of the problem. As always, nobody actually gives a damn about "security" and uses it as a pretext

"Memory unsafe languages" is maybe one percent of one percent of the problem. As always, nobody actually gives a damn about "security" and uses it as a pretext to push something unrelated. (In this case, Current Year's stupid fad programming language.)

candiddevmike 3y ago
From what I've seen, we're going to rewrite everything in memory safe languages, miss all of the corner case logic and tests, and end up less secure than we were at the beginning.
bradley13 3y ago
Memory safe languages are nearly irrelevant. Last time I looked, freaking injection attacks still held the top place among vulnerabilities. Even companies that take testing seriously rarely test for security problems. This needs to change.
- joemazerino 3y ago
  Injection attacks holding a top place means the adoption of memory-safe languages is working.
  - bradley13 3y ago
    No. Injection attacks have held the top place for literally decades. They are kindergarten level: validate your inputs. Lazy or incompetent developers still fail to do so.
- RajT88 3y ago
  Injection attacks AFAIK have held the top place since forever. It is why people keep buying WAF's.
  - nanocode 3y ago
    On the other hand, WAFs are another kind of security theater. They won't stop any determined attacker. Usually you just need to change your payload to make it work. Unless you tweak the rules a lot, to the point where you could encode then in your application as well (for example "user_id" field in the POST data must consist only of decimal numbers)
    - RajT88 3y ago
      Counterpoint: Just because they won't stop any determined attacker, doesn't mean they don't have value. Stopping casual attackers is one talking point, but still not the real value. In my opinion, the real value is making you look less like "low-hanging fruit" to automated scans - throwing a bunch of 403's makes you less likely for a follow-up after an automated scan. I actually have a side project when I get the time to try and prove it statistically using a honeypot. I would bet the overall volume of attacks is lower with WAF enabled, and inversely correlates with the 403's thrown. Just my 2 cents.
logicprog 3y ago
> "Memory unsafe languages" is maybe one percent of one percent of the problem. Multiple distinct large scale software projects have found that 60-70% of severe CVEs are due to memory safety violations[1]. The White House has called for projects to use memory safe languages [2]. The Android Project has seen an incredibly substantial drop in security vulnerabilities concurrent with their rapid shift to using memory safe languages in New code, with the correlation being so tight and the number of vulnerabilities having been so constant before that they are forced to conclude that memory safe languages have helped[3]. So your claim that memory unsafe languages are maybe 1% of 1% of the problem is not only completely unsubstantiated, but almost certainly false given all of the available information. And your jab presumably at Rust for being a "fad" similarly holds no water. It is the only language that has actually offered a practical means of eliminating memory safety violations at compile time, statically, without needing a runtime or garbage collector or to give up zero cost abstractions, meaning that is the only relatively memory safe language with a solid shot at working in the fields where C and C++ were ordinarily used. That really doesn't seem like a fad to me. Or stupid. As I've said many a time, this sort of denial often seems like the cantankerous lashing out of someone who doesn't want to learn something new and can't be bothered to look past the occasionally superficially annoying antics of a community to see the actual technical merits of the software, and perhaps even can't stand to be confronted with the fact that their hard won knowledge in a needlessly difficult language might eventually be less in demand than it was before, and whose fragile elitist self-mythology about being better than everyone else because they can "write C code without making mistakes" is in danger of collapsing under the weight of evidence that it is a delusion. [1]: https://alexgaynor.net/2020/may/27/science-on-memory-unsafety-and-security/ https://alexgaynor.net/2020/may/27/science-on-memory-unsafet... [2]: https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/press-release-technical-report/ https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/pre... [3]: https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html?m=1 https://security.googleblog.com/2022/12/memory-safe-language...
- FreakLegion 3y ago
  >60-70% of severe CVEs are due to memory safety violations...So your claim that memory unsafe languages are maybe 1% of 1% of the problem is not only completely unsubstantiated, but almost certainly false given all of the available information Based on your tone and profile you probably aren't interested in better information here, but I'll offer anyway. The vast majority of cybersecurity attacks, and especially the vast majority of actual incidents, don't involve CVEs. Think recent breaches at Okta, Microsoft, Uber, even SolarWinds a few years ago. When CVEs do come into play, they're as likely to be logic flaws as anything else. Think Sandworm, Log4Shell, that Apache Struts vulnerability that Equifax didn't patch. And when memory safety problems do bubble up, well, there are still a bunch of issues that existing memory-safe languages don't actually address. They're real, flawed tools made by real, flawed people, not magic. So, big picture, memory-safe languages shouldn't be a top-10 priority for very many teams at this point. Maybe someday, though.
Kharacternyk 3y ago
I'm fascinated by C. I agree that using almost anything else automatically eliminates entire classes of bugs and vulnerabilities, but it's so much _fun_ to be close to the machine and avoid those bugs and vulnerabilities myself. Judging by the fact that even some greenfield projects are still written in C, I'm not alone.
- logicprog 3y ago
  I am as much of a rust shill as you'll ever meet, but I agree that there is something beautiful and alluring and simple and engaging about C that few other languages match. It's basically an advanced macro assembler for an abstract machine, so there's all of the allure of using 6502 or 68000 assembly language but with none of the portability problems, and a vast ecosystem of libraries and amazing books to back it up.
  - Kharacternyk 3y ago
    I've enjoyed writing a few projects in x86-64 assembly as well, for what it's worth. Even though I'm sure that any C compiler would generate better assembly than my handwritten one. Flat assembler is great, by the way.
    - saulpw 3y ago
      Any C compiler can generate better assembly for a function. But there's often some whole program optimizations that you can make, which the C compiler isn't allowed to do (because of the ABI/linker). For example, a Forth interpreter can thread its way through "words" (its subroutines) with the top-of-stack element in a dedicated register. This simplifies many of the core words; for example, "DUP" becomes a single x86 push instruction, instead of having to load the value from the stack first. And the "NEXT" snippet which drives the threaded execution can be inlined in every core word. And so on. You can write a Forth interpreter loop in C (I have), and it can be clever. But a C compiler can't optimize it to the hilt. Of course it may not be necessary, and the actual solution is to design your interpreted language such that it benefits from decades of C compiler optimizations, but nevertheless, there are many things that can be radically streamlined if you sympathize with the hardware platform.
bitwize 3y ago
No. Put C out to pasture -- or just take it behind the barn and shoot it. Entire classes of severe bugs Just Go Away when you switch to a memory-safe language. Not all bugs, obviously, but the vast majority of the low-hanging fruit.
- nanocode 3y ago
  Well if I could shake my magic wand and instantly convert all my (and other) C code to some kind of MemorySafeC code, I would. Unfortunately, there is no such magic wand, and all we can do is to rewrite tens of millions of lines of C code to another language with different tradeoffs and different compatibility. It is, in other words, usually not possible.
  - deleted 3y ago
    [deleted]
- otabdeveloper4 3y ago
  I mostly agree with this sentiment, but please let's not pretend like we're doing it because we care about "security", and not just because we don't like some of C's 1970's legacy crap.

candiddevmike 3y ago

From what I've seen, we're going to rewrite everything in memory safe languages, miss all of the corner case logic and tests, and end up less secure than we were at the beginning.

bradley13 3y ago

Memory safe languages are nearly irrelevant. Last time I looked, freaking injection attacks still held the top place among vulnerabilities. Even companies that take testing seriously rarely test for security problems. This needs to change.

joemazerino 3y ago
Injection attacks holding a top place means the adoption of memory-safe languages is working.
- bradley13 3y ago
  No. Injection attacks have held the top place for literally decades. They are kindergarten level: validate your inputs. Lazy or incompetent developers still fail to do so.
RajT88 3y ago
Injection attacks AFAIK have held the top place since forever. It is why people keep buying WAF's.
- nanocode 3y ago
  On the other hand, WAFs are another kind of security theater. They won't stop any determined attacker. Usually you just need to change your payload to make it work. Unless you tweak the rules a lot, to the point where you could encode then in your application as well (for example "user_id" field in the POST data must consist only of decimal numbers)
  - RajT88 3y ago
    Counterpoint: Just because they won't stop any determined attacker, doesn't mean they don't have value. Stopping casual attackers is one talking point, but still not the real value. In my opinion, the real value is making you look less like "low-hanging fruit" to automated scans - throwing a bunch of 403's makes you less likely for a follow-up after an automated scan. I actually have a side project when I get the time to try and prove it statistically using a honeypot. I would bet the overall volume of attacks is lower with WAF enabled, and inversely correlates with the 403's thrown. Just my 2 cents.

logicprog 3y ago

> "Memory unsafe languages" is maybe one percent of one percent of the problem. Multiple distinct large scale software projects have found that 60-70% of severe CVEs are due to memory safety violations[1]. The White House has called for projects to use memory safe languages [2]. The Android Project has seen an incredibly substantial drop in security vulnerabilities concurrent with their rapid shift to using memory safe languages in New code, with the correlation being so tight and the number of vulnerabilities having been so constant before that they are forced to conclude that memory safe languages have helped[3]. So your claim that memory unsafe languages are maybe 1% of 1% of the problem is not only completely unsubstantiated, but almost certainly false given all of the available information. And your jab presumably at Rust for being a "fad" similarly holds no water. It is the only language that has actually offered a practical means of eliminating memory safety violations at compile time, statically, without needing a runtime or garbage collector or to give up zero cost abstractions, meaning that is the only relatively memory safe language with a solid shot at working in the fields where C and C++ were ordinarily used. That really doesn't seem like a fad to me. Or stupid. As I've said many a time, this sort of denial often seems like the cantankerous lashing out of someone who doesn't want to learn something new and can't be bothered to look past the occasionally superficially annoying antics of a community to see the actual technical merits of the software, and perhaps even can't stand to be confronted with the fact that their hard won knowledge in a needlessly difficult language might eventually be less in demand than it was before, and whose fragile elitist self-mythology about being better than everyone else because they can "write C code without making mistakes" is in danger of collapsing under the weight of evidence that it is a delusion. [1]: https://alexgaynor.net/2020/may/27/science-on-memory-unsafety-and-security/ https://alexgaynor.net/2020/may/27/science-on-memory-unsafet... [2]: https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/press-release-technical-report/ https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/pre... [3]: https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html?m=1 https://security.googleblog.com/2022/12/memory-safe-language...

FreakLegion 3y ago
>60-70% of severe CVEs are due to memory safety violations...So your claim that memory unsafe languages are maybe 1% of 1% of the problem is not only completely unsubstantiated, but almost certainly false given all of the available information Based on your tone and profile you probably aren't interested in better information here, but I'll offer anyway. The vast majority of cybersecurity attacks, and especially the vast majority of actual incidents, don't involve CVEs. Think recent breaches at Okta, Microsoft, Uber, even SolarWinds a few years ago. When CVEs do come into play, they're as likely to be logic flaws as anything else. Think Sandworm, Log4Shell, that Apache Struts vulnerability that Equifax didn't patch. And when memory safety problems do bubble up, well, there are still a bunch of issues that existing memory-safe languages don't actually address. They're real, flawed tools made by real, flawed people, not magic. So, big picture, memory-safe languages shouldn't be a top-10 priority for very many teams at this point. Maybe someday, though.

Kharacternyk 3y ago

I'm fascinated by C. I agree that using almost anything else automatically eliminates entire classes of bugs and vulnerabilities, but it's so much _fun_ to be close to the machine and avoid those bugs and vulnerabilities myself. Judging by the fact that even some greenfield projects are still written in C, I'm not alone.

logicprog 3y ago
I am as much of a rust shill as you'll ever meet, but I agree that there is something beautiful and alluring and simple and engaging about C that few other languages match. It's basically an advanced macro assembler for an abstract machine, so there's all of the allure of using 6502 or 68000 assembly language but with none of the portability problems, and a vast ecosystem of libraries and amazing books to back it up.
- Kharacternyk 3y ago
  I've enjoyed writing a few projects in x86-64 assembly as well, for what it's worth. Even though I'm sure that any C compiler would generate better assembly than my handwritten one. Flat assembler is great, by the way.
  - saulpw 3y ago
    Any C compiler can generate better assembly for a function. But there's often some whole program optimizations that you can make, which the C compiler isn't allowed to do (because of the ABI/linker). For example, a Forth interpreter can thread its way through "words" (its subroutines) with the top-of-stack element in a dedicated register. This simplifies many of the core words; for example, "DUP" becomes a single x86 push instruction, instead of having to load the value from the stack first. And the "NEXT" snippet which drives the threaded execution can be inlined in every core word. And so on. You can write a Forth interpreter loop in C (I have), and it can be clever. But a C compiler can't optimize it to the hilt. Of course it may not be necessary, and the actual solution is to design your interpreted language such that it benefits from decades of C compiler optimizations, but nevertheless, there are many things that can be radically streamlined if you sympathize with the hardware platform.

bitwize 3y ago

No. Put C out to pasture -- or just take it behind the barn and shoot it. Entire classes of severe bugs Just Go Away when you switch to a memory-safe language. Not all bugs, obviously, but the vast majority of the low-hanging fruit.

nanocode 3y ago
Well if I could shake my magic wand and instantly convert all my (and other) C code to some kind of MemorySafeC code, I would. Unfortunately, there is no such magic wand, and all we can do is to rewrite tens of millions of lines of C code to another language with different tradeoffs and different compatibility. It is, in other words, usually not possible.
- deleted 3y ago
  [deleted]
otabdeveloper4 3y ago
I mostly agree with this sentiment, but please let's not pretend like we're doing it because we care about "security", and not just because we don't like some of C's 1970's legacy crap.