8 ms·

I'm seeing 42 CVEs, of those, 24 are solved at a foundational level by memory-safe languages (I'm talking out-of-bounds, use-after-free, race conditions/locking

I'm seeing 42 CVEs, of those, 24 are solved at a foundational level by memory-safe languages (I'm talking out-of-bounds, use-after-free, race conditions/locking issues) I wonder how long the same story will repeat before the balance shifts in favor of just rewriting in more modern languages. It's expensive work with a long ROI, but sounds like a lot of these are in foundational libraries that you want to be robust in the long run.

varenc 5y ago
Isn't Swift, which came from Apple, memory-safe in a single thread environment? It can't prevent data races at compile time like Rust, but I thought it was far safer in practice than C/C++/ObjC where I suspect all these vulns originate.
- grishka 5y ago
  Swift is their "user-facing" language because this trendy stuff with "smart" languages is apparently very important for PR. I would be surprised if most of the OS itself is written in something other than C/C++/ObjC.
  - smilespray 5y ago
    I take it you're not a big fan of Swift, but there's little need to veer over into borderline conspiracy theories. I do think Apple is honestly committed to Swift over the long term, but it takes loads of time and care to replace the foundations of a building that's in daily use.
    - grishka 5y ago
      I'm not a fan of these "smart" languages in general. I'm one of those who believes that the syntax of the language itself should be dumb, but all the smarts should be in the standard library. Like in Java for example. It's much easier to reason about what the code actually does when the language is dumb and calls into its standard library are explicit. It's bad when some benign-looking syntactic constructs trigger some kind of complex behavior. They might be committed to it, but I'm doubtful that it's at all possible to write e.g. parts of the kernel in it. And maybe, just maybe, they should direct all their efforts toward rewriting the OS in a safer language instead of making their UIs uglier with nonsensical paddings and messy-looking icons that pretend that there's no pixel grid.
    - pjmlp 5y ago
      Metal and Driver Kit came after Swift, they happen to be written in a mix of C++ and Objective-C, with Swift bindings.
      - smilespray 5y ago
        Fair point. Is it fair to guess that development started before Swift was ready for prime time, and before Apple's own devs of these were up to skill?
        pjmlp 5y ago
        Only a couple of macOS frameworks are pure Swift, most of them are actually bindings via Objective-C runtime interop.
  - rdsnsca 5y ago
    The dock was rewritten in Swift, a few other parts of macOS have been too.
    - grishka 5y ago
      Oh so I guess that's why I'm seeing "ghosts" of finder windows under the dock sometimes, especially right after taking a screenshot? And they disappear if I switch to finder. I kept thinking "how could they've possibly broken that". Updated to 12.1 today, will see whether that improves anything. But it would be more interesting to see the parts that deal with untrusted data (file format parsers, protocol handlers) rewritten in Swift.
- AceJohnny2 5y ago
  Absolutely, but Apple clearly hasn't decided to switch their foundation libraries to it. I suspect it'll be a decade-long effort, but it can't happen too soon.
pjmlp 5y ago
Morris worm came out in the mid-1980´s, it will only be fixed when proper liability is in place.
- AceJohnny2 5y ago
  Eh, only recently did we really have, in the consumer space, the computational and memory margin to seriously consider spending on more memory-safe languages. Certainly in the 80s through 00s, switching to a language that gave you nebulous "safety" improvements wasn't worth losing even 10% performance. The competition would eat you up over it. (There were absolutely spaces where robustness and safety were the priority, but those weren't consumer, and their cost reflected it.) Even today, I'm not sure we have the engineering margin spend on such efforts (time-to-market is still the priority), though I think the pressure is slowly increasing to do it (again, in consumer spaces, which macOS definitely is).
  - pjmlp 5y ago
    Hence why we need liability, everyone pays the same for faulty software. No one would enjoy paying for a fridge that leaks water, why should they do the same for software. Bad programming shops taught them that way, that is why.
    - GhettoComputers 5y ago
      >Bad programming shops taught them that way, that is why. Most of these programming languages when they were created did not have online connectivity or hackers as a threat. It would be ridiculous to expect them to protect against a threat that didn't exist like calling Japanese idiots for not making nuclear defenses and their bad teachers are the reason. In embedded hardware I still don't see the benefit for memory safety.
      - pjmlp 5y ago
        Security and safety in programming languages is a know issue since the 1950's, as anyone that actually cares about this subject is aware. In fact it was one of the sales pitch for Burroughs (1961), still being sold by Unisys, which not surprisingly keeps using its safety over classical POSIX as sales pitch.
emodendroket 5y ago
I imagine the failure of the C# Windows project looms large in such discussions.
roca 5y ago
The ROI on rewriting existing code may be questionable, but the long-term ROI on writing new projects in safe languages seems unassailable. Choosing C or C++ for new infrastructure projects is madness at this point.
- AceJohnny2 5y ago
  It's still way easier to find experienced C++ coders than Rust coders. :\
  - paavohtl 5y ago
    An experienced C++ programmer can learn Rust quite easily. The hard part (ownership & lifetimes) is what experienced C++ developers should already know by heart, but the primary difference is that the compiler enforces the same rules.
    - _0w8t 5y ago
      It is hard to write in Rust style in C++ since many libraries are hostile to it. Iterators require at least two mutable references or mixing mutable and non-mutable references. Move-only types require a lot of boiler plate and accidental usage of moved thing is not detected by the compiler. Using std::variant feels like a trolling from the language designers who refused to provide proper type-safe unions into the language.
      - eru 5y ago
        > Using std::variant feels like a trolling from the language designers who refused to provide proper type-safe unions into the language. And, alas, deliberate trolling would be preferable to reality. Deliberate trolling would indicate a conscious design. C++ accumulated cruft over the years in what looks like brownian motion in retrospect, and almost never shed any.
- GhettoComputers 5y ago
  Depends on what its for. I wouldn't mind any unsafe non network connected device, if they really want to hack my programmable thermometer with no network access, or my wired keyboard, they can be my guest! If my server is on intranet, I don't have any fears either, without memory safety hacks can happen, but spectre and meltdown haven't been seen in the wild. For OS and browsers though, I agree completely if infrastructure as long as its not always connected to the open internet, it doesn't seem to be much of a threat, and even though I don't care about memory safety, the performance of rust tools impresses me! I wish people talked about performance of rust more than its memory safety, I don't care as much about that, but everything being faster? Who wouldn't want that? I made this thread a few days ago. https://news.ycombinator.com/item?id=29456115 https://news.ycombinator.com/item?id=29456115
roca 5y ago
It's interesting to see the number of bugs related to race conditions here, and it would be very interesting to know if Rust's protection against race conditions would have been relevant ... there are plenty of good modern memory-safe languages, but not many with Rust-style freedom from data-races.
- eru 5y ago
  > [...] there are plenty of good modern memory-safe languages, but not many with Rust-style freedom from data-races. Haskell's Software-Transactional-Memory (and general focus on immutability-by-default) are another interesting approach towards the same goal. Software Transactional Memory (STM) is perhaps much easier to get started with than Rust's model. (Though the same can not be said for the rest of Haskell.) The failure model with STM is that your stuff runs slow, if you don't know what you are doing.
  - miohtama 5y ago
    STM is super exciting, but also an old concept. Is the runtime penalty too high, or is there any other reason it has not gained popularity? I remember Intel touting CPU STM extensiona back in a day.
deleted 5y ago
[deleted]
_0w8t 5y ago
Alternatively one can do the same that Mozilla does for a few components in Firefox [1]. That is, sandbox C/C++ libraries/components at the compilation time so memory-safety bugs will not be able to escape the sandbox. The big plus is that this avoids code re-write for the price of slower execution due to extra checks in the generated code. This is especially applicable for various parsers that are typically self-contained code that is not performance critical but very prone to bugs with nasty consequences like the article demonstrated again. [1] - https://hacks.mozilla.org/2021/12/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/ https://hacks.mozilla.org/2021/12/webassembly-and-back-again...
- saagarjha 5y ago
  Apple is indeed doing both, but it turns out that sandboxing is an attack surface just like any other code.
lordnacho 5y ago
Is there some Ship-of-Theseus way to do this? Redo each component that needs it as it comes up?
- eru 5y ago
  To a certain extent. Though some problems require more thorough surgery.
luch 5y ago
If you missed the news, the Log4Shell RCE vulnerability in Log4j impacts a memory-safe language (Java). It's too early to tell -it dropped last friday - but it will probably be marked as one of the most egregious vulnerability to date due to the sheer omnipresence of Log4j in production java's code and the simplicity of its exploitation. We are talking Heartbleed/EternalBlue/Struts2 vulnerability level here. The difference of ROI of memory-unsafe/memory-managed is not so evident. Usually memory-managed languages have fewer bugs, but those tend to be massively impactful
- AceJohnny2 5y ago
  Note that I didn't claim all bugs/vulns would be solved by a sweeping use of memory-safe languages. (Just that a distressingly large proportion of the ones in this security bulletin would be) The log4j bug fits in the "other" category. Also, it's a fallacy to believe that memory-safe languages aren't that much better because their bugs are worse. All languages can have the worse bugs, it's just that memory-safe languages solved the easier type of bugs, so there isn't as much of them to bring the average down. It's like thinking that flying is riskier than driving, because plane crashes are so devastating. Driving kills more people overall, but they're spread across more, smaller events, so we're not as aware of them.
inkyoto 5y ago
I am also wondering how many of the disclosed CVE's are Intel x86 specific, and how many the ARM64 8.3+ authenticated pointers have prevented (even though the authenticated pointers would not preclude a DoS attack, but they would certainly render the remote code execution impossible).
- saagarjha 5y ago
  Look up how many of these appear in the iOS release notes, perhaps?
jmull 5y ago
It's not clear the ROI ever pays off. A rewrite will likely introduce plenty of CVEs that weren't present in the original code -- possibly more than are fixed, for many years to come.

varenc 5y ago

Isn't Swift, which came from Apple, memory-safe in a single thread environment? It can't prevent data races at compile time like Rust, but I thought it was far safer in practice than C/C++/ObjC where I suspect all these vulns originate.

grishka 5y ago
Swift is their "user-facing" language because this trendy stuff with "smart" languages is apparently very important for PR. I would be surprised if most of the OS itself is written in something other than C/C++/ObjC.
- smilespray 5y ago
  I take it you're not a big fan of Swift, but there's little need to veer over into borderline conspiracy theories. I do think Apple is honestly committed to Swift over the long term, but it takes loads of time and care to replace the foundations of a building that's in daily use.
  - grishka 5y ago
    I'm not a fan of these "smart" languages in general. I'm one of those who believes that the syntax of the language itself should be dumb, but all the smarts should be in the standard library. Like in Java for example. It's much easier to reason about what the code actually does when the language is dumb and calls into its standard library are explicit. It's bad when some benign-looking syntactic constructs trigger some kind of complex behavior. They might be committed to it, but I'm doubtful that it's at all possible to write e.g. parts of the kernel in it. And maybe, just maybe, they should direct all their efforts toward rewriting the OS in a safer language instead of making their UIs uglier with nonsensical paddings and messy-looking icons that pretend that there's no pixel grid.
  - pjmlp 5y ago
    Metal and Driver Kit came after Swift, they happen to be written in a mix of C++ and Objective-C, with Swift bindings.
    - smilespray 5y ago
      Fair point. Is it fair to guess that development started before Swift was ready for prime time, and before Apple's own devs of these were up to skill?
      - pjmlp 5y ago
        Only a couple of macOS frameworks are pure Swift, most of them are actually bindings via Objective-C runtime interop.
- rdsnsca 5y ago
  The dock was rewritten in Swift, a few other parts of macOS have been too.
  - grishka 5y ago
    Oh so I guess that's why I'm seeing "ghosts" of finder windows under the dock sometimes, especially right after taking a screenshot? And they disappear if I switch to finder. I kept thinking "how could they've possibly broken that". Updated to 12.1 today, will see whether that improves anything. But it would be more interesting to see the parts that deal with untrusted data (file format parsers, protocol handlers) rewritten in Swift.
AceJohnny2 5y ago
Absolutely, but Apple clearly hasn't decided to switch their foundation libraries to it. I suspect it'll be a decade-long effort, but it can't happen too soon.

pjmlp 5y ago

Morris worm came out in the mid-1980´s, it will only be fixed when proper liability is in place.

AceJohnny2 5y ago
Eh, only recently did we really have, in the consumer space, the computational and memory margin to seriously consider spending on more memory-safe languages. Certainly in the 80s through 00s, switching to a language that gave you nebulous "safety" improvements wasn't worth losing even 10% performance. The competition would eat you up over it. (There were absolutely spaces where robustness and safety were the priority, but those weren't consumer, and their cost reflected it.) Even today, I'm not sure we have the engineering margin spend on such efforts (time-to-market is still the priority), though I think the pressure is slowly increasing to do it (again, in consumer spaces, which macOS definitely is).
- pjmlp 5y ago
  Hence why we need liability, everyone pays the same for faulty software. No one would enjoy paying for a fridge that leaks water, why should they do the same for software. Bad programming shops taught them that way, that is why.
  - GhettoComputers 5y ago
    >Bad programming shops taught them that way, that is why. Most of these programming languages when they were created did not have online connectivity or hackers as a threat. It would be ridiculous to expect them to protect against a threat that didn't exist like calling Japanese idiots for not making nuclear defenses and their bad teachers are the reason. In embedded hardware I still don't see the benefit for memory safety.
    - pjmlp 5y ago
      Security and safety in programming languages is a know issue since the 1950's, as anyone that actually cares about this subject is aware. In fact it was one of the sales pitch for Burroughs (1961), still being sold by Unisys, which not surprisingly keeps using its safety over classical POSIX as sales pitch.

emodendroket 5y ago

I imagine the failure of the C# Windows project looms large in such discussions.

roca 5y ago

The ROI on rewriting existing code may be questionable, but the long-term ROI on writing new projects in safe languages seems unassailable. Choosing C or C++ for new infrastructure projects is madness at this point.

AceJohnny2 5y ago
It's still way easier to find experienced C++ coders than Rust coders. :\
- paavohtl 5y ago
  An experienced C++ programmer can learn Rust quite easily. The hard part (ownership & lifetimes) is what experienced C++ developers should already know by heart, but the primary difference is that the compiler enforces the same rules.
  - _0w8t 5y ago
    It is hard to write in Rust style in C++ since many libraries are hostile to it. Iterators require at least two mutable references or mixing mutable and non-mutable references. Move-only types require a lot of boiler plate and accidental usage of moved thing is not detected by the compiler. Using std::variant feels like a trolling from the language designers who refused to provide proper type-safe unions into the language.
    - eru 5y ago
      > Using std::variant feels like a trolling from the language designers who refused to provide proper type-safe unions into the language. And, alas, deliberate trolling would be preferable to reality. Deliberate trolling would indicate a conscious design. C++ accumulated cruft over the years in what looks like brownian motion in retrospect, and almost never shed any.
GhettoComputers 5y ago
Depends on what its for. I wouldn't mind any unsafe non network connected device, if they really want to hack my programmable thermometer with no network access, or my wired keyboard, they can be my guest! If my server is on intranet, I don't have any fears either, without memory safety hacks can happen, but spectre and meltdown haven't been seen in the wild. For OS and browsers though, I agree completely if infrastructure as long as its not always connected to the open internet, it doesn't seem to be much of a threat, and even though I don't care about memory safety, the performance of rust tools impresses me! I wish people talked about performance of rust more than its memory safety, I don't care as much about that, but everything being faster? Who wouldn't want that? I made this thread a few days ago. https://news.ycombinator.com/item?id=29456115 https://news.ycombinator.com/item?id=29456115

roca 5y ago

It's interesting to see the number of bugs related to race conditions here, and it would be very interesting to know if Rust's protection against race conditions would have been relevant ... there are plenty of good modern memory-safe languages, but not many with Rust-style freedom from data-races.

eru 5y ago
> [...] there are plenty of good modern memory-safe languages, but not many with Rust-style freedom from data-races. Haskell's Software-Transactional-Memory (and general focus on immutability-by-default) are another interesting approach towards the same goal. Software Transactional Memory (STM) is perhaps much easier to get started with than Rust's model. (Though the same can not be said for the rest of Haskell.) The failure model with STM is that your stuff runs slow, if you don't know what you are doing.
- miohtama 5y ago
  STM is super exciting, but also an old concept. Is the runtime penalty too high, or is there any other reason it has not gained popularity? I remember Intel touting CPU STM extensiona back in a day.

deleted 5y ago

[deleted]

_0w8t 5y ago

Alternatively one can do the same that Mozilla does for a few components in Firefox [1]. That is, sandbox C/C++ libraries/components at the compilation time so memory-safety bugs will not be able to escape the sandbox. The big plus is that this avoids code re-write for the price of slower execution due to extra checks in the generated code. This is especially applicable for various parsers that are typically self-contained code that is not performance critical but very prone to bugs with nasty consequences like the article demonstrated again. [1] - https://hacks.mozilla.org/2021/12/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/ https://hacks.mozilla.org/2021/12/webassembly-and-back-again...

saagarjha 5y ago
Apple is indeed doing both, but it turns out that sandboxing is an attack surface just like any other code.

lordnacho 5y ago

Is there some Ship-of-Theseus way to do this? Redo each component that needs it as it comes up?

eru 5y ago
To a certain extent. Though some problems require more thorough surgery.

luch 5y ago

If you missed the news, the Log4Shell RCE vulnerability in Log4j impacts a memory-safe language (Java). It's too early to tell -it dropped last friday - but it will probably be marked as one of the most egregious vulnerability to date due to the sheer omnipresence of Log4j in production java's code and the simplicity of its exploitation. We are talking Heartbleed/EternalBlue/Struts2 vulnerability level here. The difference of ROI of memory-unsafe/memory-managed is not so evident. Usually memory-managed languages have fewer bugs, but those tend to be massively impactful

AceJohnny2 5y ago
Note that I didn't claim all bugs/vulns would be solved by a sweeping use of memory-safe languages. (Just that a distressingly large proportion of the ones in this security bulletin would be) The log4j bug fits in the "other" category. Also, it's a fallacy to believe that memory-safe languages aren't that much better because their bugs are worse. All languages can have the worse bugs, it's just that memory-safe languages solved the easier type of bugs, so there isn't as much of them to bring the average down. It's like thinking that flying is riskier than driving, because plane crashes are so devastating. Driving kills more people overall, but they're spread across more, smaller events, so we're not as aware of them.

inkyoto 5y ago

I am also wondering how many of the disclosed CVE's are Intel x86 specific, and how many the ARM64 8.3+ authenticated pointers have prevented (even though the authenticated pointers would not preclude a DoS attack, but they would certainly render the remote code execution impossible).

saagarjha 5y ago
Look up how many of these appear in the iOS release notes, perhaps?

jmull 5y ago

It's not clear the ROI ever pays off. A rewrite will likely introduce plenty of CVEs that weren't present in the original code -- possibly more than are fixed, for many years to come.