[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.

[michaelmcmillan]

> 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?

[Dylan16807]

I don't think the security boundary was actually expanded, I think it had a hole punched in it. I doubt the bulk of com.apple.loginwindow was coded to enforce that particular security at all.

loginwindow is not doing the wrong thing because it's complex. It's doing the wrong thing because that was never its job.

> don't you think that's what they originally had in mind when they first designed it?

Probably, but they didn't fail because loginwindow itself was complex. They failed either for systemic reasons that would have happened with simple or complex code, or they failed because the actual secure part was too complex. That's why I think total complexity is the wrong thing to look it; it may or may not correlate with those two real causes.

[michaelmcmillan]

"Systemic reasons" sounds a lot like complexity to me. Do you have a counterexample of a simple system that blew up like this due to systemic reasons?