5 ms·

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 min

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 4y ago
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 4y ago
  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 : )
- deleted 4y ago
  [deleted]
fay59 4y ago
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 4y ago
  Sure - but he also added the vulnerability he exploited in the first place?
  - fay59 4y ago
    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.
    - ncmncm 4y ago
      The code exploited was very, very far from any "best practice" in this decade, and probably the previous one.
      - pjmlp 4y ago
        Unfortunately still a common reality across many corporations.
    - DannyBee 4y ago
      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 4y ago
        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.

londons_explore 4y ago

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 4y ago
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 : )
deleted 4y ago
[deleted]

fay59 4y ago

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 4y ago
Sure - but he also added the vulnerability he exploited in the first place?
- fay59 4y ago
  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.
  - ncmncm 4y ago
    The code exploited was very, very far from any "best practice" in this decade, and probably the previous one.
    - pjmlp 4y ago
      Unfortunately still a common reality across many corporations.
  - DannyBee 4y ago
    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 4y ago
      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.