Live data from Hacker News

A buffer overflow in the XNU kernel

jprx.io

11–20 of 40 posts

Re: A buffer overflow in the XNU kernel

#11

[flagged]

It’s definitely nowhere near capable of doing that.

GPT-5, maybe not. But somebody somewhere is building something that can do that. And if they can't do it _now_ they have a plan that tells them what's missing. TLDR; it's coming, soon.

Re: A buffer overflow in the XNU kernel

#12

Earlier quoted context omitted.

It’s definitely nowhere near capable of doing that.

Is "with a sufficiently smart LLM" the new "with a sufficiently smart compiler?"

"imagine feeding this into an LLM/ChatGPT" is the new "imagine a Beowulf cluster of these"

Re: A buffer overflow in the XNU kernel

#13

Earlier quoted context omitted.

It’s definitely nowhere near capable of doing that.

GPT-5, maybe not. But somebody somewhere is building something that can do that. And if they can't do it _now_ they have a plan that tells them what's missing. TLDR; it's coming, soon.

and lots of people are spending lots of time and money on AI Coding Assitants... which is more or less the knowledge base you need.

If they could use that structural training to answer queries like "Is there any code path where some_dangerous_func() is called without it's return value being checked"...

Re: A buffer overflow in the XNU kernel

#15
post #2

If you're still running the affected kernel, what are the possible consequences? Also, this has been public for months: - February 17, 2024: I posted the hash of TURPENTINE.c to X on Feb 17, 2024. - May 13, 2024: macOS Sonoma 14.5 (23F79) shipped with xnu-10063.121.3, the first public release containing a fix.

The syscalls involved are in a lot of sandboxes, so worst (or best, depending on your point of view) case scenario it's a pretty universal privesc. There's a lot of steps to get there though. I'm not super familiar with the mbuf subsystem specifically but I'm going to guess mbufs are in their own allocator zone. That means you're guaranteed to overwrite an adjacent m_hdr structure. Those contains pointers that form a linked list and at first glance I don't see linked list hardening or zone checks in the MBUF macros. One could envision being able to turn this bug into a kASLR leak as well as a kernel r/w primitive and while that isn't the silver bullet it used to be on XNU (because of a whole host of hardening Apple put in) it's still pretty powerful.

Re: A buffer overflow in the XNU kernel

#16

Earlier quoted context omitted.

It’s definitely nowhere near capable of doing that.

GPT-5, maybe not. But somebody somewhere is building something that can do that. And if they can't do it _now_ they have a plan that tells them what's missing. TLDR; it's coming, soon.

Writing exploits is a bit of an art-form. Current incarnations of GPT have trouble writing code at a level more advanced than a junior developer.

Re: A buffer overflow in the XNU kernel

#18
post #13

Earlier quoted context omitted.

GPT-5, maybe not. But somebody somewhere is building something that can do that. And if they can't do it _now_ they have a plan that tells them what's missing. TLDR; it's coming, soon.

and lots of people are spending lots of time and money on AI Coding Assitants... which is more or less the knowledge base you need. If they could use that structural training to answer queries like "Is there any code path where some_dangerous_func() is called without it's return value being checked"...

You can do this today by querying the AST output by a compiler. Regardless, the parent comment was talking about exploits, not vulnerabilities/bugs. Vulns are a dime-a-dozen compared to even PoC exploits let alone shippable exploits.

Re: A buffer overflow in the XNU kernel

#19
post #9

[flagged]

There is a bigger chance that a toddler smashing a keyboard finds a bug than gpt5. LLMs can't understand intent, so they literally work like `grep` with little to no understanding of the context, so most of the time it will false flag good code. There are already a lot of tools already to find bugs, like fuzzers, but I am sure that LLMs won't be one of them.

they don't need to understand intent, they just need to find exploits. they don't even need to do it by reading code alone - give them a vm running the code and let them throw excrement at it until something sticks!
Post reply on HN