First public macOS kernel memory corruption exploit on Apple M5
1–10 of 140 posts
Re: First public macOS kernel memory corruption exploit on Apple M5
#2unfortunately a little light on the details. I'm very curious how the bug survived through MTE
Re: First public macOS kernel memory corruption exploit on Apple M5
#3unfortunately a little light on the details. I'm very curious how the bug survived through MTE
Memory Tagging Extension
Arm published the Memory Tagging Extension (MTE) specification in 2019 as a tool for hardware to help find memory corruption bugs. MTE is a memory tagging and tag-checking system, where every memory allocation is tagged with a secret. The hardware guarantees that later requests to access memory are granted only if the request contains the correct secret. If the secrets don’t match, the app crashes, and the event is logged. This allows developers to identify memory corruption bugs immediately as they occur.
https://support.apple.com/guide/security/operating-system-in...
Re: First public macOS kernel memory corruption exploit on Apple M5
#4unfortunately a little light on the details. I'm very curious how the bug survived through MTE
Upon further reading on data only attacks
(https://www.usenix.org/publications/loginonline/data-only-at...)
This makes more sense. You don't trigger MTE since you're not doing anything for force MTE to take action the program isn't actually changing.
My other question would be, why didn't apple use fbounds checking here? They've been doing it aggressively everywhere else.
MTE plus fbounds checking everywhere should lead to an extremly hardened OS
Re: First public macOS kernel memory corruption exploit on Apple M5
#5unfortunately a little light on the details. I'm very curious how the bug survived through MTE
GPU memory/shaders/etc. isn't protected by MTE or PAC. They said "data-only", so I guess GPU commands could fit into this description.
Re: First public macOS kernel memory corruption exploit on Apple M5
#6[flagged]
Re: First public macOS kernel memory corruption exploit on Apple M5
#7Did the article get edited? There is not much description of the field trip.
Re: First public macOS kernel memory corruption exploit on Apple M5
#8unfortunately a little light on the details. I'm very curious how the bug survived through MTE
Upon further reading on data only attacks ( https://www.usenix.org/publications/loginonline/data-only-at... ) This makes more sense. You don't trigger MTE since you're not doing anything for force MTE to take action the program isn't actually changing. My other question would be, why didn't apple use fbounds checking here? They've been doing it aggressively everywhere else. MTE plus fbounds checking everywhere should…
Quite strange indeed, given that was one of the main points on their security conference a few months ago.
Re: First public macOS kernel memory corruption exploit on Apple M5
#9[flagged]
Cisco put up a totally bogus 10.0 CVE just for this reason, too
Re: First public macOS kernel memory corruption exploit on Apple M5
#10Earlier quoted context omitted.
Upon further reading on data only attacks ( https://www.usenix.org/publications/loginonline/data-only-at... ) This makes more sense. You don't trigger MTE since you're not doing anything for force MTE to take action the program isn't actually changing. My other question would be, why didn't apple use fbounds checking here? They've been doing it aggressively everywhere else. MTE plus fbounds checking everywhere should…
Quite strange indeed, given that was one of the main points on their security conference a few months ago.
I can only imagine that
1. it’s to performance sensitive
Or
2. The os is so darn large it’s hard to recompile everything