I'm curious which sector of infosec you're referring to in which vulnerability researchers are not required to provide proofs of concept? Maybe internal product VR where there is already an established trust?

Yeah race conditions like that are always tricky to make reliable. And yeah I do realize that the purpose of the writeup was more about the efficacy of using LLMs vs the bug itself, and I did get a lot out of that part, I just hyper-focused on the bug because it's what I tend to care the most about. In the end I agree with your conclusion, I believe LLMs are going to become a key part of the VR workflow as they improve and I'm grateful for folks like yourself documenting a way forward for their integration.

Anyways, solid writeup and really appreciate the follow-up!

1) If it is actually a UAF or if there is some other mechanism missing from the context that prevents UAF. 2) The category and severity of the vulnerability. Is it even a DoS, RCE, or is the only impact causing a thread to segfault?

This is all part of the standard vulnerability research process. I'm honestly surprised it got merged in without a PoC, although with high profile projects even the suggestion of a vulnerability in code that can clearly be improved will probably end up getting merged.

But what if there's a missing piece of the puzzle that the author and devs missed or assumed o3 covered, but in fact was out of o3's context, that would invalidate this vulnerability?

I'm not saying there is, nor am I going to take the time to do the author's work for them, rather I am saying this report is not fully validated which feels like a dangerous precedent to set with what will likely be an influential blog post in the LLM VR space moving forward.

IMO the idea of PoC || GTFO should be applied more strictly than ever before to any vulnerability report generated by a model.

The underlying perspective that o3 is much better than previous or other current models still remains, and the methodology is still interesting. I understand the desire and need to get people to focus on something by wording it a specific way, it's the clickbait problem. But dammit, do better. Build a PoC and validate your claims, don't be lazy. If you're going to write a blog post that might influence how vulnerability researchers conduct their research, you should promote validation and not theoretical assumption. The alternative is the proliferation of ignorance through false-but-seemingly-true reporting, versus deepening the community's understanding of a system through vetted and provable reports.

The PDF could have been authored at any time.

Looks like the created date embedded in the metadata is as follows:

2023-12-18T21:21:19.000Z

Created with MS Word. But even that isn't definitive.

Comments URL: https://news.ycombinator.com/item?id=38600357

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=38498158

Points: 2

# Comments: 0

My approach is just setting proper firewall rules on a dedicated ESSID with a dedicated VLAN. A device on a restricted VLAN shouldn't be able talk to anything. The downside is its more work, but the plus side is it can be done on trusted firmware (OpenWRT) and not something that would require an entire code audit to determine if there are any logic flaws.

I still don't see a usecase for a unique PSK per guest, and even that can be achieved with most guest portal implementations.

What SPR seems to lack is backing and therefore trust. Pushing a product aggressively on HN is not the way to build that trust.

Second, does anyone known of any existing or planned implementations of this outside of the Apple ecosystem?

It seems like an immensely useful feature if you work with multiple laptops but want to use the hardware on your desktop computer.

Comments URL: https://news.ycombinator.com/item?id=38151354

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=38145205

Points: 55

# Comments: 33

Can it be bypassed? Yes.

Are the researchers whose entire company hinges on the correctness of their analysis doing their absolute best to attribute the attack to a threat actor? Yes.

So to your point, somebody could indeed reuse malware or attempt to replicate it. However, the researchers are likely analyzing the disassembly and bytecode, and replicating complex malware to perfectly imitate a known family of malware is exceptionally difficult and statistically very unlikely. This is how threat intel is able to make any sort of claim of attribution.

However, a lot of the comments here seem to be hailing VPNs in general as the solution to privacy on the internet.

I would like to remind people that VPNs only really protect you against two things: your ISP and the endpoint. And that's assuming that your ISP isn't doing some shady analytics.

That being said, knocking those two things off the board is a huge benefit to privacy and absolutely should be done.

Mullvad is a nice middle ground for those who don't see that as worth their time or don't know how. Its good to see they're at the very least trying to keep up appearances.