[DannyBee]

Yes - you can't run untrusted native code in the first place outside of the emulator ;)

That's why the bug says: "The overall impact of this bug is pretty minimal in our current set of supported products, since none support running untrusted native code, and if you can run your own code on the system, then (at present) you can also use other existing supported workflows to obtain kernel logs, but it does seem to be a useful stepping stone towards privilege escalation if you have already obtained code-exec in some process through another exploit."

So while not awesome, also not possible on a real device right now without a code-exec exploit.

[londons_explore]

Don't forget that the use-after-free used was also artificial - ie. OP didn't discover one, he added a UAF bug to go exploit.

The fact he got KASAN working and talks about fuzzing suggests he looked for one, but couldn't find one, which is a good sign.

[phlip9]

From the article, it looks like the syzkaller fuzzer integration was stale and not working, so there might still be some juice to squeeze if someone can get that running again : )

[fay59]

The intent of the post isn’t to claim that any Fuschia device currently sold is vulnerable. Unless Fuschia never graduates to running third-party code, that seemed like the right assessment to me.

[DannyBee]

Sure - but he also added the vulnerability he exploited in the first place?

[fay59]

That’s not really a “but” to the comment, which was that you need to find one bug and it’s game over. We’ve known for a long time that best practices aren’t enough to prevent memory corruption in large enough C++ code bases, so it’s likely a motivated attacker would eventually find something.

[DannyBee]

Sure - look i'm not gonna argue about C++ memory safety - i've funded and spent time trying to ensure we are funding figuring out how to get off of C++.

I just assume C++ code is unsafe, because it's really really hard to make it safe.

However, at the same time, the privilege escalation issues would have happened in any language - if you don't implement the check, you don't implement the check.

(and you could make it equally automatic in most languages)

[fay59]

What the missing access check protected was a stream of information that could defeat ASLR. If Zircon was written in a memory-safe language, that would have been the end of the issue. Logic bugs and missing access checks are still possible, but defeating them has fairly well definable consequences. Since Zircon isn’t written in a memory-safe language, the author was able to use that to fully compromise the kernel instead. I don’t mean that you can’t write bugs in memory-safe languages, but in the end the attacker still has to play by your rules. With a memory safety bug, attackers play by no one’s rules.

[DannyBee]

I admire your optimism, but the notion that missing access checks are somehow less dangerous in a memory safe language is nonsense on its face.

Yes, this particular one enabled a defeat of ASLR, but so what? Missing access checks enable privilege escalation no matter what the language.

Your claim that "has well-definable consequences" is equally true in C++ as anywhere else. Whether you miss your access check in rust, or C++, or python, or whatever, the definable consequences are "privilege escalation".

Let's not pretend memory safe languages solve logic problems. They help with memory safety - that's awesome but not a complete solution.

If we want better verification of access contracts, we'd need a language with contracts or some other verifiable mechanism.

Those exist, and i'd support their use in this sort of case.

[ncmncm]

The code exploited was very, very far from any "best practice" in this decade, and probably the previous one.

[pjmlp]

Unfortunately still a common reality across many corporations.