5 ms·

I wonder if Apple's devs are just going to say, screw it, we'll rewrite the whole thing in Rust with audits and formal analysis the whole way...

brobinson 5y ago
Apple had job postings last year looking for Rust developers to rewrite a service that was written in C so it's not without precedent. Job posting links are dead now, but there was a reddit thread about it: https://old.reddit.com/r/rust/comments/fkngza/apple_hiring_rust_engineers_for_storage_and/ https://old.reddit.com/r/rust/comments/fkngza/apple_hiring_r...
- est31 5y ago
  A more fresh job posting from Apple: https://old.reddit.com/r/rust/comments/ou5szr/official_rrust_whos_hiring_thread_for_jobseekers/h8q9449/ https://old.reddit.com/r/rust/comments/ou5szr/official_rrust... Also: https://jobs.apple.com/en-us/search?search=rust&sort=relevance https://jobs.apple.com/en-us/search?search=rust&sort=relevan...
raspasov 5y ago
Rust or Swift. I am not a security expert, but I'd bet that re-writing in either would reduce the amount of such embarrassing exploits at least 10x. From what I can tell, the combination of unsafe-by-default languages like C/C++/Obj-C and the way the human brain works is Not-A-Good-Combination© . Too many opportunities for error.
- coldcode 5y ago
  Some Apple devs still seem to love C and Obj-C (at least the ones my former employer worked with directly) and hate on Swift. Both Swift and Rust can be written to a much higher standard where the language protects you from stupidity, but only if you give up the past and use them. While you can write pretty good C-ish code (i.e. Linux), its far too easy to slip up once and the language does nothing to save your ass. Some of Apple's OS code is pretty ancient. Switching to Swift or Rust is not necessarily a panacea if you call too many OS routines still in C-ish.
  - raspasov 5y ago
    I agree. Swift is a nice language, compared to the alternatives. I have a few months experience in it, and I can definitely agree that if you're writing Swift-only, it's very nice. The emphasis on values, and value semantics is definitely a differentiator from most other languages. However, anytime you have to use/interop with an older API designed for Obj-C (for example, AVFoundation), it's much more of a pain. Effectively, you're writing Obj-C in Swift. If someone is insisting on Obj-C instead of Swift in 2021, I would attribute it to a form of a Stockholm Syndrome. Many people form psychological bonds with whatever they are familiar with.
    - setpatchaddress 5y ago
      Yes, there are some people who simply prefer Objective-C, but you need to also realize that Swift is still not ready for system-level programming. Analysis tools aren’t ready; debugging basically means you go to printing variables to stderr and praying. The standard library defaults to crashing at runtime for simple float <-> integer conversion bounds errors which you’d think would be caught statically with more thoughtful design. Still a lot of rough edges. SwiftUI in particular is excellent and if you can use it you should. But you can’t say Swift in general is ready to replace Objective-C. It’s not.
      - saagarjha 5y ago
        Swift is not ready, but it's not for those reasons. The real problem is that Swift needs a hefty runtime and is fairly slow due to excessive ARC traffic, plus it has no way of recovering from memory exhaustion. So you can't really use it in the kernel, but it's perfectly fine for writing system frameworks and daemons.
        stephencanon 5y ago
        Realistically none of the commonly used systems languages have a mechanism to recover from memory exhaustion. Some pretend to, but if you actually try to use them, yeeeeech The big missing features (from my perspective) are fixed-size arrays, placement allocation, and the ability to guarantee that no allocations or refcount operations occur in a marked critical section. There’s a lot of other stuff I would like to have, but those are the things I can’t live without.
- simondotau 5y ago
  Low level library stuff like JPEG and PNG parsing/decoding is exactly where Rust could offer massive security wins for a relatively modest change of code. The main requirement would be to ensure that the Rust versions had absolute feature parity with zero regressions.
CyberRage 5y ago
Well I would dare to say iMessage isn't the biggest target to convert to Rust. At the end of the day, it is still an app with app level permissions, sandbox etc. Kernel\Kernel modules are far more likely to be written as they allow for vastly more access than an app.
- dylan604 5y ago
  Unless someone applies the squeaky wheel rule. The thing causing everyone to look at you gets pushed to the top of the list.
- saagarjha 5y ago
  It's a great target considering that a lot of other exploits go through the kernel just to get access to your iMessages.
  - CyberRage 5y ago
    If you successfully exploit a kernel vulnerability, you don't need an iMessage bug.... you can pretty much access whatever you want.
    - saagarjha 5y ago
      My point is that the thing you would often do after that is go after people's iMessages anyways.
      - CyberRage 5y ago
        I think you misunderstand how things work on modern mobile OS. You don't need to access the messages app in order to get access to the messages. it's the opposite actually, the messaging app needs permissions for the system level messaging component.
        saagarjha 5y ago
        I assure you that I know enough to at least hold an intelligent conversation on mobile security. On iOS there is no "system level messaging component". (i)Messages are stored in a SQLite database that is protected via entitlements and sandboxing; the Messages app is given the ability to access it legitimately. Attackers can either exploit the Messages itself and (via code execution in that process) grab a user's messages, or they can exploit something else (such as the web content process) and then escalate privileges from there to bypass the sandbox.
stefan_ 5y ago
You are talking about the same company that shoved their proprietary WiFi protocol full of holes straight into the kernel. Judging from the kind of messages it emits, the latter is a true masterpiece by the way.

brobinson 5y ago

Apple had job postings last year looking for Rust developers to rewrite a service that was written in C so it's not without precedent. Job posting links are dead now, but there was a reddit thread about it: https://old.reddit.com/r/rust/comments/fkngza/apple_hiring_rust_engineers_for_storage_and/ https://old.reddit.com/r/rust/comments/fkngza/apple_hiring_r...

est31 5y ago
A more fresh job posting from Apple: https://old.reddit.com/r/rust/comments/ou5szr/official_rrust_whos_hiring_thread_for_jobseekers/h8q9449/ https://old.reddit.com/r/rust/comments/ou5szr/official_rrust... Also: https://jobs.apple.com/en-us/search?search=rust&sort=relevance https://jobs.apple.com/en-us/search?search=rust&sort=relevan...

raspasov 5y ago

Rust or Swift. I am not a security expert, but I'd bet that re-writing in either would reduce the amount of such embarrassing exploits at least 10x. From what I can tell, the combination of unsafe-by-default languages like C/C++/Obj-C and the way the human brain works is Not-A-Good-Combination© . Too many opportunities for error.

coldcode 5y ago
Some Apple devs still seem to love C and Obj-C (at least the ones my former employer worked with directly) and hate on Swift. Both Swift and Rust can be written to a much higher standard where the language protects you from stupidity, but only if you give up the past and use them. While you can write pretty good C-ish code (i.e. Linux), its far too easy to slip up once and the language does nothing to save your ass. Some of Apple's OS code is pretty ancient. Switching to Swift or Rust is not necessarily a panacea if you call too many OS routines still in C-ish.
- raspasov 5y ago
  I agree. Swift is a nice language, compared to the alternatives. I have a few months experience in it, and I can definitely agree that if you're writing Swift-only, it's very nice. The emphasis on values, and value semantics is definitely a differentiator from most other languages. However, anytime you have to use/interop with an older API designed for Obj-C (for example, AVFoundation), it's much more of a pain. Effectively, you're writing Obj-C in Swift. If someone is insisting on Obj-C instead of Swift in 2021, I would attribute it to a form of a Stockholm Syndrome. Many people form psychological bonds with whatever they are familiar with.
  - setpatchaddress 5y ago
    Yes, there are some people who simply prefer Objective-C, but you need to also realize that Swift is still not ready for system-level programming. Analysis tools aren’t ready; debugging basically means you go to printing variables to stderr and praying. The standard library defaults to crashing at runtime for simple float <-> integer conversion bounds errors which you’d think would be caught statically with more thoughtful design. Still a lot of rough edges. SwiftUI in particular is excellent and if you can use it you should. But you can’t say Swift in general is ready to replace Objective-C. It’s not.
    - saagarjha 5y ago
      Swift is not ready, but it's not for those reasons. The real problem is that Swift needs a hefty runtime and is fairly slow due to excessive ARC traffic, plus it has no way of recovering from memory exhaustion. So you can't really use it in the kernel, but it's perfectly fine for writing system frameworks and daemons.
      - stephencanon 5y ago
        Realistically none of the commonly used systems languages have a mechanism to recover from memory exhaustion. Some pretend to, but if you actually try to use them, yeeeeech The big missing features (from my perspective) are fixed-size arrays, placement allocation, and the ability to guarantee that no allocations or refcount operations occur in a marked critical section. There’s a lot of other stuff I would like to have, but those are the things I can’t live without.
simondotau 5y ago
Low level library stuff like JPEG and PNG parsing/decoding is exactly where Rust could offer massive security wins for a relatively modest change of code. The main requirement would be to ensure that the Rust versions had absolute feature parity with zero regressions.

CyberRage 5y ago

Well I would dare to say iMessage isn't the biggest target to convert to Rust. At the end of the day, it is still an app with app level permissions, sandbox etc. Kernel\Kernel modules are far more likely to be written as they allow for vastly more access than an app.

dylan604 5y ago
Unless someone applies the squeaky wheel rule. The thing causing everyone to look at you gets pushed to the top of the list.
saagarjha 5y ago
It's a great target considering that a lot of other exploits go through the kernel just to get access to your iMessages.
- CyberRage 5y ago
  If you successfully exploit a kernel vulnerability, you don't need an iMessage bug.... you can pretty much access whatever you want.
  - saagarjha 5y ago
    My point is that the thing you would often do after that is go after people's iMessages anyways.
    - CyberRage 5y ago
      I think you misunderstand how things work on modern mobile OS. You don't need to access the messages app in order to get access to the messages. it's the opposite actually, the messaging app needs permissions for the system level messaging component.
      - saagarjha 5y ago
        I assure you that I know enough to at least hold an intelligent conversation on mobile security. On iOS there is no "system level messaging component". (i)Messages are stored in a SQLite database that is protected via entitlements and sandboxing; the Messages app is given the ability to access it legitimately. Attackers can either exploit the Messages itself and (via code execution in that process) grab a user's messages, or they can exploit something else (such as the web content process) and then escalate privileges from there to bypass the sandbox.

stefan_ 5y ago

You are talking about the same company that shoved their proprietary WiFi protocol full of holes straight into the kernel. Judging from the kind of messages it emits, the latter is a true masterpiece by the way.