Live data from Hacker News

A buffer overflow in the XNU kernel

jprx.io

21–30 of 40 posts

Re: A buffer overflow in the XNU kernel

#21
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.

Llm powered / guided fuzzer would be pretty cool though.

Re: A buffer overflow in the XNU kernel

#22

[flagged]

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 show that LLM agents can autonomously exploit one-day vulnerabilities in real-world systems. To show this, we collected a dataset of 15 one-day vulnerabilities that include ones categorized as critical severity in the CVE description. When given the CVE description, GPT-4 is capable of exploiting 87% of these vulnerabilities compared to 0% for every other model we test (GPT-3.5, open-source LLMs) and open-source vulnerability scanners (ZAP and Metasploit). Fortunately, our GPT-4 agent requires the CVE description for high performance: without the description, GPT-4 can exploit only 7% of the vulnerabilities."[1]

[0] https://www.theregister.com/2024/04/17/gpt4_can_exploit_real...

[1] https://arxiv.org/pdf/2404.08144

Re: A buffer overflow in the XNU kernel

#24
post #18
post #13

Earlier quoted context omitted.

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.

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

Re: A buffer overflow in the XNU kernel

#25
post #9

Earlier quoted context omitted.

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.

Llm powered / guided fuzzer would be pretty cool though.

https://github.com/google/oss-fuzz-gen

Re: A buffer overflow in the XNU kernel

#26
post #24
post #18

Earlier quoted context omitted.

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.

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.

Post reply on HN