4 ms·

Caused by Apple copy pasting networking BSD code, missing a crucial bounds check in the process (as noted by another reply ITT). Here: https://news.ycombinator

Caused by Apple copy pasting networking BSD code, missing a crucial bounds check in the process (as noted by another reply ITT). Here: https://news.ycombinator.com/item?id=18351533 https://news.ycombinator.com/item?id=18351533

pjmlp 8y ago
Which in a language with bounds checking would usually mean a panic instead of a memory corruption leading to possible exploit. Unless the same mistake would have been done inside an unsafe code block/module. If anything, C's history of memory corruption errors and how they come to be, proves that even the best aren't able to follow best practices that apparently all good C coders do. Linux kernel is full of such CVEs in spite of the approval processes in place to accept new code into the kernel, and I assume Apple does have similar practices in place.
- int0x80 8y ago
  Yeah. C gives you little safety nets. But the problem here is a missing check. Do the same (logic mistakes) in Rust, Java, C#, JavaScript etc and you will, sooner or later, give access to your admin account, to your DB, to a command shell or to memory, writting not permitted values by omiting a validation check etc. I see your point, and I agree partly, some languages can avoid the particular secuence of events in this bug or make it more difficult. In this case, imagine: - Sloppiness getting code into the icmp module (this is speculation, to be fair). - Buffer overrun leading to RCE. - Solution: 1 You rewrite in rust because you think the root cause is that C is unsafe. 2 You don't write sloppy code, higher your standars, more audit/testing/verification. To me, if you don't fix #2, you are going to have big problems anyway even if you have safer tools.
  - pjmlp 8y ago
    That is the typical defense argument I keep getting from C crowd since the mid-90's. The thing is, Σ logic errors < Σ logic errors + Σ memory corruption errors So while errors don't go away, the exploit area is considerably dimished. Naturally it gets hand waved as errors are errors. Which is why I really do look forward for harder lawsuits when security exploits happen. When money starts speaking, more companies will take security more seriously.
    - int0x80 8y ago
      Fine. I agree. Less is better. Now, I don't want to have a c vs rust like discussion, I think we will agree in fact mostly. But, all I was saying in the beginning (and I later digressed) is that just blaming 'C memory model' is not fair. (Dramatization) "Hey, boss, yes... an RCE, what a pitty. Yeah, missing check. But don't blame me. Is C it is at fault". That is just not realistic/ridiculous. Is like saying is the parents of Denis Ritchie that are at fault here.
      - pjmlp 8y ago
        It is fair blaming C memory model because safer systems programming languages exist since 1961, and C only got where it is thanks for Bell Labs not being able to sell UNIX for the first 10 years of its existence. Even Multics had less exploits than earlier UNIX versions, as stated on a DoD report about inexistence of memory corruption issues thanks to PL/I. If you bother to read the early C history document written by Richie, they were aware of such shortcomings and thus lint was born in 1979. A tool that to this day many devs still ignore. As for alternative languages I haven't named a single one on this thread. There are plenty to chose from since 1961.
        int0x80 8y ago
        Interesting, I will read the article, thanks for mentioning it. As for alternatives, I was just giving examples, you didn't say anything yes.

pjmlp 8y ago

Which in a language with bounds checking would usually mean a panic instead of a memory corruption leading to possible exploit. Unless the same mistake would have been done inside an unsafe code block/module. If anything, C's history of memory corruption errors and how they come to be, proves that even the best aren't able to follow best practices that apparently all good C coders do. Linux kernel is full of such CVEs in spite of the approval processes in place to accept new code into the kernel, and I assume Apple does have similar practices in place.

int0x80 8y ago
Yeah. C gives you little safety nets. But the problem here is a missing check. Do the same (logic mistakes) in Rust, Java, C#, JavaScript etc and you will, sooner or later, give access to your admin account, to your DB, to a command shell or to memory, writting not permitted values by omiting a validation check etc. I see your point, and I agree partly, some languages can avoid the particular secuence of events in this bug or make it more difficult. In this case, imagine: - Sloppiness getting code into the icmp module (this is speculation, to be fair). - Buffer overrun leading to RCE. - Solution: 1 You rewrite in rust because you think the root cause is that C is unsafe. 2 You don't write sloppy code, higher your standars, more audit/testing/verification. To me, if you don't fix #2, you are going to have big problems anyway even if you have safer tools.
- pjmlp 8y ago
  That is the typical defense argument I keep getting from C crowd since the mid-90's. The thing is, Σ logic errors < Σ logic errors + Σ memory corruption errors So while errors don't go away, the exploit area is considerably dimished. Naturally it gets hand waved as errors are errors. Which is why I really do look forward for harder lawsuits when security exploits happen. When money starts speaking, more companies will take security more seriously.
  - int0x80 8y ago
    Fine. I agree. Less is better. Now, I don't want to have a c vs rust like discussion, I think we will agree in fact mostly. But, all I was saying in the beginning (and I later digressed) is that just blaming 'C memory model' is not fair. (Dramatization) "Hey, boss, yes... an RCE, what a pitty. Yeah, missing check. But don't blame me. Is C it is at fault". That is just not realistic/ridiculous. Is like saying is the parents of Denis Ritchie that are at fault here.
    - pjmlp 8y ago
      It is fair blaming C memory model because safer systems programming languages exist since 1961, and C only got where it is thanks for Bell Labs not being able to sell UNIX for the first 10 years of its existence. Even Multics had less exploits than earlier UNIX versions, as stated on a DoD report about inexistence of memory corruption issues thanks to PL/I. If you bother to read the early C history document written by Richie, they were aware of such shortcomings and thus lint was born in 1979. A tool that to this day many devs still ignore. As for alternative languages I haven't named a single one on this thread. There are plenty to chose from since 1961.
      - int0x80 8y ago
        Interesting, I will read the article, thanks for mentioning it. As for alternatives, I was just giving examples, you didn't say anything yes.