[mikeash]

How much of that code is safety critical? I occasionally see misbehavior from my Tesla's center screen, like the network connection failing, or audio glitches, or even the occasional spontaneous reboot. This can be mildly annoying but it doesn't worry me because I know that the center screen is separate from the stuff where bugs can actually get me killed.

[michaelmcmillan]

"On Thursday October 24, 2013, an Oklahoma court ruled against Toyota in a case of unintended acceleration that lead to the death of one the occupants. Central to the trial was the Engine Control Module's (ECM) firmware.

Embedded software used to be low-level code we'd bang together using C or assembler. These days, even a relatively straightforward, albeit critical, task like throttle control is likely to use a sophisticated RTOS and tens of thousands of lines of code. " [1] [2]

[1] https://www.edn.com/design/automotive/4423428/Toyota-s-kille...

[2] https://www.embedded.com/electronics-blogs/barr-code/4214602...

[mikeash]

Sure. My point is just that you can't bring up the total number of lines of code here, because most of those lines aren't in any way related to any safety-critical system. If you want to talk about how much code there is which puts you at risk, you need to look at that particular subset of code.

[michaelmcmillan]

I think it is safe to assume that complexity is highly correlated with number of lines of code. And with complexity grows bugs.

On the surface, this particular exploit on macOS seems to be caused by a totally unrelated subsystem (security vs. GUI).

[mikeash]

I don't see any evidence that this exploit is related to the GUI at all. The GUI just happens to be the easiest way to do it. Other commenters have mentioned that you can use the exploit with `su`.

In any case, in a desktop system you shove everything together and then try to modularize it with good design and weak tools like UNIX processes. In a car, the safety-critical systems are literally running on separate hardware with limited communication over a specialized data bus. Of course it's still possible for them to have bugs or even exploits, but the complexity of the infotainment system is irrelevant, aside from making it a potential jumping-off point for using an exploit in the safety-critical systems.

Counting the infotainment system here makes about as much sense as counting the number of lines in Windows when talking about a Mac vulnerability because a Windows machine could be used to launch an attack.

[michaelmcmillan]

"Apple root bug appears to be triggered only by logins coming from com.apple.loginwindow. Running "su" with a blank password won't get you a root shell." [1]

As for your subsystem argument, explain this: https://www.youtube.com/watch?v=OobLb1McxnI&feature=youtu.be...

[1] https://twitter.com/0xAmit/status/935609423485169664

[mikeash]

There are a bunch of replies to that tweet saying that it does work, you just have to do it a certain way.

That video is explained by using the infotainment systems as a bridge, exactly as I described in my previous comment.

[Dylan16807]

> I think it is safe to assume that complexity is highly correlated with number of lines of code. And with complexity grows bugs.

But it's still wrong to focus on total complexity. You want to look at the complexity of the relevant system.

[michaelmcmillan]

Not so sure: "Apple root bug appears to be triggered only by logins coming from com.apple.loginwindow. Running "su" with a blank password won't get you a root shell." https://twitter.com/0xAmit/status/935609423485169664

[Dylan16807]

You can't blame com.apple.loginwindow for that. The security boundary is at the login processing. If it processes requests differently from certain systems then it's misbehaving. If we wanted to make this secure we would only need to carefully craft it, and even if com.apple.loginwindow was the most complex heap of bugs in the world it wouldn't matter.