36 ms·

"No way to prevent this" say users of only language where this regularly happens

53 points by blackhole 3y ago

saagarjha 3y ago
> users of the only programming language in the world where these vulnerabilities regularly happen once or twice per quarter for the last eight years I wish!
marcus0x62 3y ago
For anyone who doesn't regularly follow The Onion, the verbiage in this post is directly copied from the story The Onion posts after every major mass-shooting in the United States. An example: https://www.theonion.com/no-way-to-prevent-this-says-only-nation-where-this-r-1848971668 https://www.theonion.com/no-way-to-prevent-this-says-only-na...
- trevoristall 3y ago
  I knew I recognized it from somewhere, thanks for the context
stonogo 3y ago
I'm almost positive the project being dunked on here is older than the author. There are plenty of reasons to hate glibc, but nothing productive comes of this kind of noise. It's not like heap overflows are impossible in other languages. Consult https://github.com/rust-lang/rust/issues/80894 https://github.com/rust-lang/rust/issues/80894 or consult your preferred CVE database. Would love to know what language the author thinks glibc should have been written in in the late eighties.
- wrs 3y ago
  Good point, since of course we’re all using the version of glibc written in the late eighties. (???)
  - stonogo 3y ago
    Where in the intervening time would you have recommended a rewrite? Into which language? The other successful libc projects for linux -- bionic and musl -- are also written in C. Which language should they have been written in? Why do you suppose they weren't?
    - wrs 3y ago
      There may be other reasons it’s the way it is, I’m just saying the language choice made 40 years ago is not one of the valid reasons. People do rewrite things, even complicated things, in different languages all the time when there’s sufficient benefit. There have been plenty of other major changes to glibc in that time.
      - marcus0x62 3y ago
        So they should rewrite an implementation of the C standard library in not-C?
        wrs 3y ago
        It’s a component with very, very high leverage. If you improve glibc then you’ve improved millions of other programs. So I would think all options are on the table.
- ivancho 3y ago
  I think the dunk is funny, and at the same time recognize that glibc is invaluable. At least here the attackers had to do some memory tricks - in other (apparently safer) languages they just get arbitrary code execution directly implemented in the logger!
Gyurantula 3y ago
[flagged]
ChrisArchitect 3y ago
Related (as linked in the article): CVE-2023-6246: Heap-based buffer overflow in the glibc's syslog() https://news.ycombinator.com/item?id=39194093 https://news.ycombinator.com/item?id=39194093
MattPalmer1086 3y ago
Very funny! I just did some coding on C for the first time in years. Now, ok, i'm out of practice, but I'm generally a fairly cautious programmer. I got so many seg faults and weird memory errors in my code. Valgrind found some more that I hadn't spotted. It's just too easy to screw it up. Much better to use languages that remove entire classes of bug without you having to even think about it.
Gow8876 3y ago
Rewrite in Rust?

53 points by blackhole 3y ago

> users of the only programming language in the world where these vulnerabilities regularly happen once or twice per quarter for the last eight years I wish!

marcus0x62 3y ago

For anyone who doesn't regularly follow The Onion, the verbiage in this post is directly copied from the story The Onion posts after every major mass-shooting in the United States. An example: https://www.theonion.com/no-way-to-prevent-this-says-only-nation-where-this-r-1848971668 https://www.theonion.com/no-way-to-prevent-this-says-only-na...

trevoristall 3y ago
I knew I recognized it from somewhere, thanks for the context

stonogo 3y ago

I'm almost positive the project being dunked on here is older than the author. There are plenty of reasons to hate glibc, but nothing productive comes of this kind of noise. It's not like heap overflows are impossible in other languages. Consult https://github.com/rust-lang/rust/issues/80894 https://github.com/rust-lang/rust/issues/80894 or consult your preferred CVE database. Would love to know what language the author thinks glibc should have been written in in the late eighties.

wrs 3y ago
Good point, since of course we’re all using the version of glibc written in the late eighties. (???)
- stonogo 3y ago
  Where in the intervening time would you have recommended a rewrite? Into which language? The other successful libc projects for linux -- bionic and musl -- are also written in C. Which language should they have been written in? Why do you suppose they weren't?
  - wrs 3y ago
    There may be other reasons it’s the way it is, I’m just saying the language choice made 40 years ago is not one of the valid reasons. People do rewrite things, even complicated things, in different languages all the time when there’s sufficient benefit. There have been plenty of other major changes to glibc in that time.
    - marcus0x62 3y ago
      So they should rewrite an implementation of the C standard library in not-C?
      - wrs 3y ago
        It’s a component with very, very high leverage. If you improve glibc then you’ve improved millions of other programs. So I would think all options are on the table.
ivancho 3y ago
I think the dunk is funny, and at the same time recognize that glibc is invaluable. At least here the attackers had to do some memory tricks - in other (apparently safer) languages they just get arbitrary code execution directly implemented in the logger!

Gyurantula 3y ago

[flagged]

ChrisArchitect 3y ago

Related (as linked in the article): CVE-2023-6246: Heap-based buffer overflow in the glibc's syslog() https://news.ycombinator.com/item?id=39194093 https://news.ycombinator.com/item?id=39194093

MattPalmer1086 3y ago

Very funny! I just did some coding on C for the first time in years. Now, ok, i'm out of practice, but I'm generally a fairly cautious programmer. I got so many seg faults and weird memory errors in my code. Valgrind found some more that I hadn't spotted. It's just too easy to screw it up. Much better to use languages that remove entire classes of bug without you having to even think about it.

Gow8876 3y ago

Rewrite in Rust?