Live data from Hacker News

First public macOS kernel memory corruption exploit on Apple M5

blog.calif.io

21–30 of 140 posts

Re: First public macOS kernel memory corruption exploit on Apple M5

#21

Earlier quoted context omitted.

This is an lpe I believe what you’re describing is a zero click rce.

how much do you think it is worth in the bug bounty program

They don’t seem to state lpe as one of the bugs. Maybe 100k? There’s alot of factors that go into it so I’m really not able to say. I could see it going for lots more or lots less

Re: First public macOS kernel memory corruption exploit on Apple M5

#22
post #20

The world is so not ready for the impact of LLMs on security issues. If true, congrats to the Calif team. It’s likely too technical for me to understand in details but looking forward to reading the 55 pages report

you're assuming that blue teams and engineers are sitting around twiddling their thumbs

Re: First public macOS kernel memory corruption exploit on Apple M5

#23
post #22
post #20

The world is so not ready for the impact of LLMs on security issues. If true, congrats to the Calif team. It’s likely too technical for me to understand in details but looking forward to reading the 55 pages report

you're assuming that blue teams and engineers are sitting around twiddling their thumbs

Not at all. I’m considering that the amount of vulnerable software in the wild is very, very large, with most organizations not managing their systems properly. Imagine all the small to medium size companies that do not have budgets for a dedicated, talented security team. And all the software that will never be patched. We are at the beginning of the exponential

Re: First public macOS kernel memory corruption exploit on Apple M5

#24
post #2

unfortunately a little light on the details. I'm very curious how the bug survived through MTE

> I'm very curious how the bug survived through MTE

Its not the first time bugs get past MTE, happened with Google Pixel last year ... https://github.blog/security/vulnerability-research/bypassin...

Re: First public macOS kernel memory corruption exploit on Apple M5

#25
post #22
post #20

The world is so not ready for the impact of LLMs on security issues. If true, congrats to the Calif team. It’s likely too technical for me to understand in details but looking forward to reading the 55 pages report

you're assuming that blue teams and engineers are sitting around twiddling their thumbs

Most companies in the world do not have “blue teams”. They barely have any kind of security employee.

Re: First public macOS kernel memory corruption exploit on Apple M5

#26
post #16
post #6

[flagged]

apple didn't "make up" this vulnerability, it was an external team reporting an issue

The commenter was being sarcastic to highlight the current trend of dismissing Mythos, and LLM’s finding security vulnerabilities in general, as a non issue.

Re: First public macOS kernel memory corruption exploit on Apple M5

#27
post #4
post #2

unfortunately 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…

could be a different type of data only attack, which doesnt override the boundaries

Re: First public macOS kernel memory corruption exploit on Apple M5

#28

I bought the M5 specifically cause of MIE. Now I feel dumb.

You shouldn’t, MTE blocks a large chunk of vulnerabilities and makes things like rop and jop very difficult if not impossible now.

I should've added /s.

Re: First public macOS kernel memory corruption exploit on Apple M5

#30
post #2

unfortunately 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 cr…

Thank you. I was about to ask.
Post reply on HN