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

Anonymous GitHub account mass-dropping undisclosed 0-days

github.com

Post reply on HN
Print view View original

381–390 of 407 posts

Re: Anonymous GitHub account mass-dropping undisclosed 0-days

#381

Post by blazespin »

tyrells wrote: post #357
simonpure wrote: post #350

The readme was recently updated. > In regard to AI usage, my fuzzing workflow was automated by AI with a strict harness. I used GPT-5.5-3-Codex-Spark for ALL the fuzzing, as barely any "thought" is necessary when provided with an efficient harness. Contrary to the growing narrative that I'm just some random child burning tokens, I DO actually have a degree in the subject and have published multiple papers on fuzzing…

Any thoughts on what type of harness this would be?

Just optimized AI driven fuzzing. Do a search on arxiv you'll find a lot.

Re: Anonymous GitHub account mass-dropping undisclosed 0-days

#382

Post by blazespin »

drob518 wrote: post #30

There is going to be a flurry of this sort of stuff as the AIs get smart enough to find them. It will naturally die down as the legitimate ones are fixed. Yes, there will always be some level of this, but I’d expect it to be low and the exploits found to be increasingly complex. This is a time of transition.

Yeah, I am seeing this as well, especially as people use AI to code review stuff more so this sort of thing slips through. On one very large project I am looking at, it's already becoming harder to find issues.

These people whinging about slop don't realize everything that doesn't come from a credible source gets ignored.

Credible people are using AI and once these issues are fixed, it will die down.

The threat of AI zero days will persist though, but they will be much more expensive and subtle to find.

Re: Anonymous GitHub account mass-dropping undisclosed 0-days

#383

Post by commandersaki »

iamnothere wrote: post #364
zahlman wrote: post #290

Earlier quoted context omitted.

Do you feel the same way about seeing "Segmentation fault (core dumped)" in the terminal from some other arbitrary program? If not, why not?

Because people often use VLC to view untrusted content. Video is a great vector for distributing malware, especially sought-after grey area content like porn, conflict videos, celebrity leaks, pirated films, etc. Not enough people pay attention to the impact of video as a vector for compromise. All downloaded video should be sandboxed!

How many victims are known to be exploited by video codecs? Compare that with the wider landscape of how victims are being exploited.

Re: Anonymous GitHub account mass-dropping undisclosed 0-days

#384

Post by commandersaki »

Wowfunhappy wrote: post #189
jeffbee wrote: post #152

Earlier quoted context omitted.

I mean, that's how people get hacked. If vlc crashed on my computer, and every day I should raise thanks to my gods that I do not use vlc, I would immediately unplug it and thoughtfully consider the circumstances under which it would be safe to turn it back on.

> I mean, that's how people get hacked. ...when was the last documented case of an in-the-wild hack targeting VNC?

I'm guessing none to be honest. It sounds plausible but in practice it's probably too difficult to do anything useful compared to other tried and true vectors.

Everyone goes to the extremes when it comes to these theories and throws out all aspects of pragmatism.

Re: Anonymous GitHub account mass-dropping undisclosed 0-days

#385

Post by K0balt »

blazespin wrote: post #379
K0balt wrote: post #352

Earlier quoted context omitted.

The point is that anyone looking for zero days has them in spades, in this age of LLM use. So, knowing that bad actors have an unending river of cheaply acquired zero days, the best response is to publish them so that maintainers also have access to them. Existing methods of slow disclosure cannot keep up with the AI firehose. It’s ugly, but it will force needed change. A thorough AI red team effort is the lowest bar…

This is ludicrous logic. We already know that there is an AI firehose. You don't need to do this. They should have used proper disclosure. All this is doing is making the AI firehose worse.

You are assuming that most projects are responsive in today’s ai firehose climate. They are not. This at least Tells users of those Projects to either find developers or write their own.

I’m onboard with this being suboptimal. But as someone who has filed >10 significant disclosures in the last month resulting from reviewing my codebase and had exactly zero responses, I can relate to the decision.

Re: Anonymous GitHub account mass-dropping undisclosed 0-days

#386

Post by albroland »

breadwinner8 wrote: post #276
albroland wrote: post #254

Earlier quoted context omitted.

Maybe I'm missing something but the ffmpeg buffer "exploit" involves passing a custom exploited buffer callback to parse a RASC file that presumably has been crafted to contain a packet that can exploit the custom buffer passed in? I don't see how this would be used in practice in the wild as to achieve the first step (custom buffer invocation) would require you to already have access to the machine to even invoke ff…

The custom get_buffer2 path is not something the attacker needs shell access to invoke. It is a normal public libavcodec API used by applications embedding FFmpeg. The attacker’s input is still just the crafted RASC/AVI media. The target application invokes FFmpeg/libavcodec during normal media processing. The PoC uses a custom buffer provider to make the heap layout deterministic and to place a demonstrable callback…

I'm sorry but again, I dont see how an 4 byte OOB write will realistically lead to RCE without the custom buffer in the POC that explicitly puts a function pointer directly where the overflow happens, then invokes it.

I'm happy to be shown what I'm missing but this seems like a memory corruption bug, not RCE, and if it was feasible w/o the custom buffer then why not provide that as the example? In the real world, a ffmpeg invocation would use the default buffer handler that will use padding/alignment/etc that makes the heap even less predictable, and incredibly unlikely to have a function pointer exactly following the frame buffer that will deterministically be invoked by a process placing it there?

It seems very far fetched.

Re: Anonymous GitHub account mass-dropping undisclosed 0-days

#387

Post by DrewADesign »

BlaDeKke wrote: post #265
fc417fc802 wrote: post #238

Earlier quoted context omitted.

I agree. They're voluntarily adding fingerprints to images so I expect the default voice is intentional and it wouldn't surprise me at all (though I have no evidence of this) if the output text has a fingerprint stenographically embedded in it.

In a video of Hank Green, he interviewed an AI expert (if there even is such a thing), and he said that in the thinking part of the conversation, LLMs seems to use code language to communicate with itself, like in the usage and ordering of words, and such. I think that there could be even more then a fingerprint in those messages. It’s this video: https://youtu.be/5CKuiuc5cJM?is=9VQ1FCxY_X3eNm-b Warning: They anthrop…

He’s not an expert in anybody’s estimation other than his own. He’s a blogger, tech booster, executive, SEO guy, etc. He was big into NFTs. He gloms onto every buzzy tech thing because squeezing all the “gee whiz” he can out of tech optimism is that guy’s career. He has no education in ML or anything related.

Re: Anonymous GitHub account mass-dropping undisclosed 0-days

#388

Post by newguy33 »

albroland wrote: post #386
breadwinner8 wrote: post #276

Earlier quoted context omitted.

The custom get_buffer2 path is not something the attacker needs shell access to invoke. It is a normal public libavcodec API used by applications embedding FFmpeg. The attacker’s input is still just the crafted RASC/AVI media. The target application invokes FFmpeg/libavcodec during normal media processing. The PoC uses a custom buffer provider to make the heap layout deterministic and to place a demonstrable callback…

I'm sorry but again, I dont see how an 4 byte OOB write will realistically lead to RCE without the custom buffer in the POC that explicitly puts a function pointer directly where the overflow happens, then invokes it. I'm happy to be shown what I'm missing but this seems like a memory corruption bug, not RCE, and if it was feasible w/o the custom buffer then why not provide that as the example? In the real world, a f…

[flagged]

Re: Anonymous GitHub account mass-dropping undisclosed 0-days

#389

Post by iamnothere »

commandersaki wrote: post #383
iamnothere wrote: post #364

Earlier quoted context omitted.

Because people often use VLC to view untrusted content. Video is a great vector for distributing malware, especially sought-after grey area content like porn, conflict videos, celebrity leaks, pirated films, etc. Not enough people pay attention to the impact of video as a vector for compromise. All downloaded video should be sandboxed!

How many victims are known to be exploited by video codecs? Compare that with the wider landscape of how victims are being exploited.

Codec vulnerabilities in the browser have been a recurring source of exploits, as have similar vulnerabilities in phone messenger apps. The phone ones are particularly bad because phones typically preprocess received media files (for thumbnailing etc) so a vulnerability here can sometimes be chained into a remotely triggered near-instant compromise.

I don’t know if there is data on exploits due to downloaded media but it would be an easy way to exploit specific target populations (find a video of interest to them and “leak” it somewhere).

Re: Anonymous GitHub account mass-dropping undisclosed 0-days

#390

Post by woodruffw »

m4rtink wrote: post #343
woodruffw wrote: post #142

Earlier quoted context omitted.

> The biggest mitigation is that gitea documentation discourages you from using action runners from untrusted users. This recommendation seems incompatible with third-party collaboration, at least on its face!

The idea is you first review PRs from external contributors before allowing the CI to run on them.

I understand the idea. The point was that it isn't good enough: humans are fallible, so you still want to provide a secure CI/CD environment for untrusted external contributors.
Post reply on HN