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