Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A buffer overflow in the XNU kernel

jprx.io

Post reply on HN
Print view View original

31–40 of 40 posts

Re: A buffer overflow in the XNU kernel

#31

Post by saagarjha »

sillywalk wrote: post #22
saagarjha wrote: post #4

Earlier quoted context omitted.

It’s definitely nowhere near capable of doing that.

Apparently GPT-4 has some capacity to conduct exploits this by "reading" CVE reports. I don't know if it can autonomously create exploits though: GPT-4 can exploit vulnerabilities by reading CVEs (theregister.com) 81 points by ignoramous 60 days ago | hide | past | favorite | 29 comments https://news.ycombinator.com/item?id=40101846 which links to a Register Article[0], which links to a paper[1]: "In this work, we sh…

Yes, that sounds about right. LLMs aren’t quite good enough to find novel bugs and exploit them like a human would.

Re: A buffer overflow in the XNU kernel

#32

Post by tedunangst »

sillywalk wrote: post #22
saagarjha wrote: post #4

Earlier quoted context omitted.

It’s definitely nowhere near capable of doing that.

Apparently GPT-4 has some capacity to conduct exploits this by "reading" CVE reports. I don't know if it can autonomously create exploits though: GPT-4 can exploit vulnerabilities by reading CVEs (theregister.com) 81 points by ignoramous 60 days ago | hide | past | favorite | 29 comments https://news.ycombinator.com/item?id=40101846 which links to a Register Article[0], which links to a paper[1]: "In this work, we sh…

Yeah, that works for web vulns where the vuln description is practically the exploit anyway. I could write a perl script that parses out variable names and writes sql injections for it.

Re: A buffer overflow in the XNU kernel

#33

Post by [deleted] »

chad1n wrote: post #9
throwaway71271 wrote: post #3

[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.

[deleted]

Re: A buffer overflow in the XNU kernel

#35

Post by TheDong »

bartvk wrote: 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.

> Also, this has been public for months:

Posting the hash to twitter as a proof that "something" exists reveals no actual information, so it's not considered making the exploit "public" in any meaningful way.

From the blog's timeline, it's been visible in code diffs since ~April, but only called out as a CVE since 10 days ago, so I'd consider this one hot off the presses.

Re: A buffer overflow in the XNU kernel

#36

Post by poincaredisk »

tedunangst wrote: post #32
sillywalk wrote: post #22

Earlier quoted context omitted.

Apparently GPT-4 has some capacity to conduct exploits this by "reading" CVE reports. I don't know if it can autonomously create exploits though: GPT-4 can exploit vulnerabilities by reading CVEs (theregister.com) 81 points by ignoramous 60 days ago | hide | past | favorite | 29 comments https://news.ycombinator.com/item?id=40101846 which links to a Register Article[0], which links to a paper[1]: "In this work, we sh…

Yeah, that works for web vulns where the vuln description is practically the exploit anyway. I could write a perl script that parses out variable names and writes sql injections for it.

For comparison, in the native world program is considered vulnerable when someone finds arbitrary write primitive (even without leak), use after free, and even double free. There is a huge gap between these and actually having a working RCE exploit. Most CVEs in this space are given without a working exploit ever written.

Re: A buffer overflow in the XNU kernel

#37

Post by poincaredisk »

axoltl wrote: post #26
TylerE wrote: post #24

Earlier quoted context omitted.

Ok, so add "and generate a C program to exploit it" to the prompt.

You're either being sarcastic or wildly underestimating how hard it is to write an exploit. I haven't written about exploit dev publicly for a _long_ time, but I invite you to read https://fail0verflow.com/blog/2014/hubcap-chromecast-root-pt... for what I consider to be a pretty trivial exploit of a very "squishy" (industry term) target. XNU isn't the hardest target to pop but it is far from the easiest.

There's nobody more confident in the world, than HN poster wiring about a topic they have no experience with.

There is a huge gap (in the binary exploitation world) between identifying a problematic code pattern and having a workable bug (a reproduction), and even larger one between a reproducible crash and a working exploit (because we're not in the 90s anymore and complier/hardware mitigations are literally always enabled). Current LLMs can cross neither gap, and are not even close to bridging the second one.

Re: A buffer overflow in the XNU kernel

#38

Post by mschuster91 »

throwaway71271 wrote: post #3

[flagged]

> Like when you can just send one icmp packet with `+++ath0` and just disconnect someone's modem

Oh, I remember the "XDCC SEND KEYLOGGER 0 0 0" exploit from IRC era ~2010... dumbass middleboxes would yeet anyone whose packets crossed them.

Post reply on HN