"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]
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.
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.
"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]
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
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.
> The security boundary is at the login processing. If it processes requests differently from certain systems then it's misbehaving.
Which is my point. More code, more complexity, more bugs. If you are correct, the security boundary you are referring to got stretched out to accommodate a separate system.
As for your strategy on separating concerns and carefully crafting important code – don't you think that's what they originally had in mind when they first designed it?