Hacker News Reader

Comment by Retr0id | Hacker News Reader

I took a look at the Ghidra ones (because I use Ghidra), and I'm unimpressed: https://github.com/bikini/exploitarium/blob/main/ghidra-12.1...

The first requires being able to overwrite binaries in the Swift tool directory. Yes, if you overwrite binaries executed by ghidra, you can trigger code execution. This is not a surprise.

The second, idk, I'm not familiar with TraceRMI (but it's probably worth noting that "RMI" stands for Remote Method Invocation).

The third is not a vulnerability in the slightest, they just demonstrate that native 7zip parsing code is reachable. Maybe there is a bug in the 7zip parser, but without that it's meaningless.

View on HN

> Yes, if you overwrite binaries executed by ghidra, you can trigger code execution.

> but it's probably worth noting that "RMI" stands for Remote Method Invocation

This reminds me of someone submitting a (clearly vibecoded) vulnerability report claiming to have found a way to execute arbitrary SQL. The project in question? An SQL server... https://github.com/tursodatabase/turso/pull/4322

lol, that's great...the "vulnerability" isn't even in turso itself, it's a helper method inside a unit test.

The Turso example is a little ironic because their homepage brands them as a product intended for use primarily by AI agents.

actually that is a valid vulnerability if it wasn't in test code but the correct fix would be to enclose the table name in "" with escaping

> ...Ghidra

Ah, MS07-052[1] ("code execution leads to code execution") strikes again. These sorts of "if you allow arbitrary code to be executed, code will be executed" "vulnerability" reports seem evergreen

[1]: https://devblogs.microsoft.com/oldnewthing/20070807-00/?p=25...

A glance at the nmap one seems potentially high severity. It might be a nothing in practice, but it being around parser code means the chances of preparing something to jump around are pretty high.

There'd be a certain irony being able to reverse shell anyone doing an nmap scan. If i had infinite tokens i'd throw claude on writing an exploit and dig through the history who made it possible because - if we take a moment to wildly speculate and assume it can ACE - this is the kind of bug an intelligence agency would love to have: Add a few ipv6 packets that then edit the trace being observed if the observer uses nmap / get access to any researcher pc who uses nmap.

Wireshark dissectors (protocol decoders) are basically all written in C, and anyone sending packets can pick a dissector.

I'm more worried about AV software. Code that also needs to be able to parse a large number of file formats, opens every file that enters your computer through one of many pathways, and generally runs at a high privilege level. A huge attack surface that's easy to reach and with far reaching consequences if it can be exploited. Add to this that it's in wide use, often even mandated by corporate IT and its recipe for disaster.

> I'm more worried about AV software

Media codecs pretty much, single-handedly even, drove about a new era of defenses and mitigations in Android: https://blog.isosceles.com/the-legacy-of-stagefright / https://archive.vn/x3d0Y

AV as in antivirus, not audio/visual

In theory the parsing could run at a low privilege level subprocess. Root/admin is only needed to get the bytes.

That’s generally too slow though; these things run in kernel space as they scan every I/O stream. Context switching and memory copies would kill performance.

https://i.imgur.com/t5jDXrt.png

"Why don't we unpack malware in the kernel" - "And so the search for intelligent life continues..."

These kind of tools have always had a broad attack surface. I've assumed state level actors already have exploits for them, mostly based on when I've used such tools for mundane network maintenance tasks and somehow do something that triggered an old-fashioned segfault.

>There'd be a certain irony being able to reverse shell anyone doing an nmap scan.

Every TV / movie hacker has known about this.

Was just thinking it would be hilarious if these were all known CVEs hiding the next Shai-Hulud inside of them and waiting to compromise security hobbyists rushing to download them.

It wouldn't be the first time!

The design purpose of Windows Sandbox :)

TIL about Windows Sandbox. Not a Windows user myself (it's the Year of Linux on the Desktop™!) but this sounds immensely useful for technical and nontechnical users -- sort of a super-disposable container with UI? https://learn.microsoft.com/en-us/windows/security/applicati...

The short lifetime of it really seems to limit the usefulness. I had a look at it before and really struggled to see what I would use it for.

Thank you. TIL. Shame you can’t run multiple simultaneously, but still it looks great!

Ghidra one is pretty weak, but I checked out the ones that were interesting to me (c-ares, libssh2, ffmpeg) and they seem to all work as of the latest upstream commit. Weird

The Gitea one looks marginally interesting, but is probably not exploitable in practice (unless Gitea or whoever else isn’t properly isolating jobs on dedicated VMs). I suspect GitHub Actions has similar behavior and is not considered exploitable because the user is assumed to already have local, non-namespaced root access.

Gitea action runner has a bunch of different ways to setup and doing the isolation properly looks tricky. The documentation doesn't provide any isolation tests to administrators, either.

The biggest mitigation is that gitea documentation discourages you from using action runners from untrusted users. Not flawless security, but it's something...

> 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!

Potentially, but for many projects things like that are tools that you want to control access to anyway. Anyone wanting to update the CI/CD process who isn't a trusted part of the project should be having their changes properly reviewed by someone who is anyway, at which point the reviewer is the trusted user not the random external entity.

I don’t disagree with that, but I think GitHub has shown that projects want to have their cake and eat it too. GitHub has also shown that it’s incredibly easy to design an insecure CI/CD that satisfies that goal, but I see that more as a symptom of them being first-to-market rather than an inherent quality of the problem.

Wait, isn't this about protecting the machine running the actions? If someone hosts a project on Github and allows anyone to run actions, it's Github's problem if there's a vulnerability to exploit. It's their installations that are going to get compromised, not necessarily the project's data.

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.

Many projects have CI setups that run code (Makefile can run any code, for example). Which means, an untrusted third-party contribution would allow that party to run arbitrary code on CI platform. Yes, the solution is to not let untrusted third-party code to be run without manual review.

So I've been wondering about whether there's a new vector that can come out of this? Or perhaps new vector isn't the right way of putting it, not a security expert :)

By mass sharing these kinds of gaps and utilising mythos tier LLM's ability to find and combine multiple disparate bits of information together, are we increasing it's capabilities and versatility?

I'm no expert on any of these programs, but that's kinda the problem, isn't it? No single person is an expert on every codebase supposedly exploited in this repo.

After a bit of research, the Firefox one seems plausible to me. But, I haven't actually tried the POC. The explanation about the private-data and untrusted-input flags is plausible but I'm not an expert on Firefox's internals, maybe that's not actually how it works.

This just sucks, all around. Are we going to need every open source project gawking at the same repo full of stuff that has nothing to do with them, on the off chance that someone discloses a vuln that does have to do with them? Is this some kind of performative complaint about high friction in responsible disclosure? Well great job dickhead, you've just made a system that's even worse. Nobody benefits from this. Yuck yuck yuck.

I actually prefer them being public than in some governments or corporations toolbox

> Nobody benefits from this

Disclosures always enable more secure software to theoretically exist,

even if nobody follows through creating it.

They often do.

The inputs are truncated to prevent malicious prompt injections. The PoC ignores this by using a fake model which is easily convinced.

>The first requires being able to overwrite binaries in the Swift tool directory.

Does it? Or does it need to be in the same directory you invoked ghidra?

I immediately saw the Ghidra one and was thinking: huh?

The bigger takeaway is someone that smart is pissed off and dropping their shit with zero warning... but hey, that's just like, my opinion man.

You don't need to be pissed off to decide that immediate public disclosure is the best option.

Ok, I don't know their emotional state. Fair point.

Maybe I'm projecting my own biases ;-)

Meanwhile, some dude was just playing with claude and accidentally made his repo public.

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 of releasing software responsibly in this day and age.

If only the AI tools didn't shut you down every time you were trying to red team your own tools. I've had to come up with all kinds of workaround scenarios, effectively bypassing the AI security processes in order to stress test my own systems.

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.

Approaching the maintainers would be ideal but time-consuming. Disclosing it like this is neutral I guess. Better than selling it in the darknet.

I do wonder though: if you can tell the AI to search for vulns, can't you also tell it to contact the right maintainer for each one found?

Unfortunately, yes.

7zip has been known to be buggy ,its very likely.

code execution js code execution, if reached through some bug or executing code that was not intended to be executed its bad, even if the mechanism is kind of obvious and trivial, it still can lead to unexpected code to be launched.

the repo also notes low quality of some POC like ones you noted.

its correct to be a bit wary and i wouldnt call it some crazy 0day dropping account or anything, but bugs/vulns are bugs an vulns and simply because you are not impressed by their complexity, it does not reduce them entirely. just makes em lil less scary.

the ghidra one, it reminds of things like unquoted service paths in windows services. its a silly thing and clearly its bad but it still happens and gets companies pwned :'). a lot of companies use ghidra actively and if you imagine what kind, you'd hope they will not allow the overwriting of those swift binaries ;p. some pentester bound to have a laugh.

Reply on news.ycombinator.com