6 ms·

I think this is the breaking point where replacing our code written in C for code written in memory safe languages is becoming urgent. The vast majority of vul

I think this is the breaking point where replacing our code written in C for code written in memory safe languages is becoming urgent. The vast majority of vulnerabilities found recently are directly related to being written in memory unsafe languages, it's very difficult to justify that a DNS/DHCP server can't be written in rust or go and without using unsafe (well, maybe a few unsafe calls are still needed, but these will be a very small amount)...

x3n0ph3n3 4mo ago
I disagree -- we're clearly getting better safeguards by way of AI agents to spot potential vulnerabilities!
- nullsanity 4mo ago
  [dead]
- jabl 4mo ago
  The question is whether the current situation is a short burst of action, and once those most critical bugs get fixed the hype around AI vulnerability scanning will die down, or whether the current crop of system/infra software written in vulnerable languages like C are beyond redemption and they will provide an endless source of critical bugs for AI to find until we fix them by rewriting them in Rust/Go/whatever.
  - yardstick 4mo ago
    An eternal summer of CVEs is upon us
    - KronisLV 4mo ago
      Seems like those “rewrite in Rust” folks had a point after all (the viability of it for any number of projects being another thing entirely).
    - LtWorf 4mo ago
      https://www.securityweek.com/tanstack-mistral-ai-uipath-hit-in-fresh-supply-chain-attack/ https://www.securityweek.com/tanstack-mistral-ai-uipath-hit-...
- Terr_ 4mo ago
  A better use of LLMs: To help translate the vast majority of C/C++ developers' output into memory-safe languages. :p
  - lionkor 4mo ago
    You're likely joking, but in case someone else misunderstands; this is not going to work. Rust with unsafe{} is the only thing you can translate directly to, even with LLMs. Rust with extensive unsafe{} is not something anyone wants to debug or maintain, and is near impossible to improve quickly.
- sieabahlpark 4mo ago
  [dead]
turpentine 4mo ago
https://news.ycombinator.com/item?id=47943499 https://news.ycombinator.com/item?id=47943499 - 44 CVEs trying to replace coreutils with a greenfield rust rewrite. There's no free lunch.
- Orygin 4mo ago
  How many CVEs in coreutils over the years? The project has the advantage of being old enough for them to be fixed. Call me when the rust rewrite has been there that long and still has more CVEs than the GNU counterpart.
  - kokada 4mo ago
    Not sure how reliable this site is, but if it is correct it looks like 10: https://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-5075/GNU-Coreutils.html https://www.cvedetails.com/vulnerability-list/vendor_id-72/p.... Maybe coreutils is so old that most security vulnerabilities was solved before CVE even existed. But I think this is also a good argument why we are replacing a solid piece of C code to Rust just because it is "memory safe" and then have lots of CVEs related to things like TOCTOUs (that Rust will not save you).
    - bayindirh 4mo ago
      People thinking that using a superior tool (on paper) enables them to automatically write better tools than the ones who are battle tested over the years baffles me to no end. Yes, you can go further, possibly faster. OTOH, nothing replaces experience and in-depth knowledge. GNU Coreutils embodies that knowledge and experience. uutils has none, and just tries to distill it with tests against the GNU one. ...and they get 44 CVEs as a result in their first test.
      - hombre_fatal 4mo ago
        There was an article posted to HN recently that enumerated bugs in the rust rewrite. Iirc the bugs had to do with linux system details like fs toctou and other things you'd only find out about in production. Ideally we'd have a better way of navigating platform idiosyncrasies or better system APIs, so that every project doesn't have to relearn them at runtime. But the rewrite isn't pure downside.
Yokohiii 4mo ago
The problem is the lack of talent that is willing to work on this, not the language. AI Security researchers at least do something. If it was so easy to rewrite everything in rust, I don't know why the response to this incidents isn't a rock solid replacement in rust, the next day. I tell you why that is. Working on these things doesn't give you stars on github.
- bluedragon1221 4mo ago
  That is a very pretentious opinion. Dnsmasq is a ubiquitous project, ~14 years old, and has maintainers that are very experienced in c and in the codebase. Telling them to rewrite in a language they are (maybe) unfamiliar with, even with the help of AI, will make these maintainers' experience worthless. People seem to think that rewriting in rust just magically fixes all issues, but that's not how it works (See recent uutils CVEs). Rewrites tend to have more bugs because the code is new and hasn't been reviewed as much.
  - bigiain 4mo ago
    I'm pretty sure we are getting close to the point where a few thousand bucks worth of tokens is enough for an agent coding session to reproduce a significant sized (but not linux kernel sized) C codebase in Rust that's 100% security bug for security bug compatible with the original. And _maybe_ "given enough eyeballs, all bugs are shallow" was true or even close top true once. But non of the "new code" ever has a _single_ eyeball cast over it. You know how sometimes you can stare into the code you wrote for weeks, but as soon as somebody else sees it they go "Hmmm, that bit looks odd. Are you sure it's right?" For most vibe coders or agents coders, it's all the same tool that generated the code that's looking for the bugs - it seems reasonable to assume that if a particular LLM generated the buggy code in the first place, it's at least as unlikely to find the bugs as a human who write buggy code?
    - swiftcoder 4mo ago
      > I'm pretty sure we are getting close to the point where a few thousand bucks worth of tokens is enough for an agent coding session to reproduce a significant sized (but not linux kernel sized) C codebase in Rust Given a comprehensive test suite for the original, probably, yes. if the test suite isn't great, you are still going to spend a lot of time/tokens chasing edge cases. > that's 100% security bug for security bug compatible with the original You can do this part without AI. c2rust will give you a translation that retains all the security bugs (and all the memory unsafety). The hope is that the AI in the loop will let you convert it to idiomatic rust (and hence avoid the memory unsafely, and in doing so, also resolve some of the security issues).
user3939382 4mo ago
Maybe the problem is the way we think of dynamic memory. “Oh I don’t know what my maximum size for this is going to be, everything has to be dynamic” Is that really true? Is it really the end of the world for programs to declare maximum acceptable sizes for their inputs, and after that error out or use a ring buffer? If sizes were known you could design around that when using them. Your ram bank is finite, why is every layer inside of it then designed to pretend to be infinite? The rust thing strikes me as a massive waste of time and doesn’t solve the fundamental problem of modeling our programs correctly for reality which is finite system resources, and not just memory. c.f. Chrome loading 4 GB models onto people’s machines.
- ok123456 4mo ago
  This is exactly how people thought before 1995. Then everyone started "smashing the stack for fun and profit." In the end, you're trading one set of bugs (dynamic memory bugs and hard to reliably exploit) for another (overflow and easy to reliably exploit).
  - megous 4mo ago
    Yeah, you still have to check for the limits, not just declare them. Then have fun smashing anything.
- account42 4mo ago
  > Is it really the end of the world for programs to declare maximum acceptable sizes for their inputs, and after that error out It's supremely annoying when you run into arbitrary limits like that as a user. Often it's like a deliberate expiration date for the software as the world moves on to larger files/etc.
deleted 4mo ago
[deleted]

x3n0ph3n3 4mo ago

I disagree -- we're clearly getting better safeguards by way of AI agents to spot potential vulnerabilities!

nullsanity 4mo ago
[dead]
jabl 4mo ago
The question is whether the current situation is a short burst of action, and once those most critical bugs get fixed the hype around AI vulnerability scanning will die down, or whether the current crop of system/infra software written in vulnerable languages like C are beyond redemption and they will provide an endless source of critical bugs for AI to find until we fix them by rewriting them in Rust/Go/whatever.
- yardstick 4mo ago
  An eternal summer of CVEs is upon us
  - KronisLV 4mo ago
    Seems like those “rewrite in Rust” folks had a point after all (the viability of it for any number of projects being another thing entirely).
  - LtWorf 4mo ago
    https://www.securityweek.com/tanstack-mistral-ai-uipath-hit-in-fresh-supply-chain-attack/ https://www.securityweek.com/tanstack-mistral-ai-uipath-hit-...
Terr_ 4mo ago
A better use of LLMs: To help translate the vast majority of C/C++ developers' output into memory-safe languages. :p
- lionkor 4mo ago
  You're likely joking, but in case someone else misunderstands; this is not going to work. Rust with unsafe{} is the only thing you can translate directly to, even with LLMs. Rust with extensive unsafe{} is not something anyone wants to debug or maintain, and is near impossible to improve quickly.
sieabahlpark 4mo ago
[dead]

turpentine 4mo ago

https://news.ycombinator.com/item?id=47943499 https://news.ycombinator.com/item?id=47943499 - 44 CVEs trying to replace coreutils with a greenfield rust rewrite. There's no free lunch.

Orygin 4mo ago
How many CVEs in coreutils over the years? The project has the advantage of being old enough for them to be fixed. Call me when the rust rewrite has been there that long and still has more CVEs than the GNU counterpart.
- kokada 4mo ago
  Not sure how reliable this site is, but if it is correct it looks like 10: https://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-5075/GNU-Coreutils.html https://www.cvedetails.com/vulnerability-list/vendor_id-72/p.... Maybe coreutils is so old that most security vulnerabilities was solved before CVE even existed. But I think this is also a good argument why we are replacing a solid piece of C code to Rust just because it is "memory safe" and then have lots of CVEs related to things like TOCTOUs (that Rust will not save you).
  - bayindirh 4mo ago
    People thinking that using a superior tool (on paper) enables them to automatically write better tools than the ones who are battle tested over the years baffles me to no end. Yes, you can go further, possibly faster. OTOH, nothing replaces experience and in-depth knowledge. GNU Coreutils embodies that knowledge and experience. uutils has none, and just tries to distill it with tests against the GNU one. ...and they get 44 CVEs as a result in their first test.
    - hombre_fatal 4mo ago
      There was an article posted to HN recently that enumerated bugs in the rust rewrite. Iirc the bugs had to do with linux system details like fs toctou and other things you'd only find out about in production. Ideally we'd have a better way of navigating platform idiosyncrasies or better system APIs, so that every project doesn't have to relearn them at runtime. But the rewrite isn't pure downside.

Yokohiii 4mo ago

The problem is the lack of talent that is willing to work on this, not the language. AI Security researchers at least do something. If it was so easy to rewrite everything in rust, I don't know why the response to this incidents isn't a rock solid replacement in rust, the next day. I tell you why that is. Working on these things doesn't give you stars on github.

bluedragon1221 4mo ago
That is a very pretentious opinion. Dnsmasq is a ubiquitous project, ~14 years old, and has maintainers that are very experienced in c and in the codebase. Telling them to rewrite in a language they are (maybe) unfamiliar with, even with the help of AI, will make these maintainers' experience worthless. People seem to think that rewriting in rust just magically fixes all issues, but that's not how it works (See recent uutils CVEs). Rewrites tend to have more bugs because the code is new and hasn't been reviewed as much.
- bigiain 4mo ago
  I'm pretty sure we are getting close to the point where a few thousand bucks worth of tokens is enough for an agent coding session to reproduce a significant sized (but not linux kernel sized) C codebase in Rust that's 100% security bug for security bug compatible with the original. And _maybe_ "given enough eyeballs, all bugs are shallow" was true or even close top true once. But non of the "new code" ever has a _single_ eyeball cast over it. You know how sometimes you can stare into the code you wrote for weeks, but as soon as somebody else sees it they go "Hmmm, that bit looks odd. Are you sure it's right?" For most vibe coders or agents coders, it's all the same tool that generated the code that's looking for the bugs - it seems reasonable to assume that if a particular LLM generated the buggy code in the first place, it's at least as unlikely to find the bugs as a human who write buggy code?
  - swiftcoder 4mo ago
    > I'm pretty sure we are getting close to the point where a few thousand bucks worth of tokens is enough for an agent coding session to reproduce a significant sized (but not linux kernel sized) C codebase in Rust Given a comprehensive test suite for the original, probably, yes. if the test suite isn't great, you are still going to spend a lot of time/tokens chasing edge cases. > that's 100% security bug for security bug compatible with the original You can do this part without AI. c2rust will give you a translation that retains all the security bugs (and all the memory unsafety). The hope is that the AI in the loop will let you convert it to idiomatic rust (and hence avoid the memory unsafely, and in doing so, also resolve some of the security issues).

user3939382 4mo ago

Maybe the problem is the way we think of dynamic memory. “Oh I don’t know what my maximum size for this is going to be, everything has to be dynamic” Is that really true? Is it really the end of the world for programs to declare maximum acceptable sizes for their inputs, and after that error out or use a ring buffer? If sizes were known you could design around that when using them. Your ram bank is finite, why is every layer inside of it then designed to pretend to be infinite? The rust thing strikes me as a massive waste of time and doesn’t solve the fundamental problem of modeling our programs correctly for reality which is finite system resources, and not just memory. c.f. Chrome loading 4 GB models onto people’s machines.

ok123456 4mo ago
This is exactly how people thought before 1995. Then everyone started "smashing the stack for fun and profit." In the end, you're trading one set of bugs (dynamic memory bugs and hard to reliably exploit) for another (overflow and easy to reliably exploit).
- megous 4mo ago
  Yeah, you still have to check for the limits, not just declare them. Then have fun smashing anything.
account42 4mo ago
> Is it really the end of the world for programs to declare maximum acceptable sizes for their inputs, and after that error out It's supremely annoying when you run into arbitrary limits like that as a user. Often it's like a deliberate expiration date for the software as the world moves on to larger files/etc.

deleted 4mo ago

[deleted]