I don't know what methods where used to find these exploits but I am starting to think security through obscurity might not be a bad thing in this day and age, where someone can just let bots loose on your codebase.
something like nginx could arguably be more secure if it was closed source
(I am a proponent of and contributor to open source)
Maybe if it's some server-side software that you only use yourself...
I do not wish to undermine the philosophical underpinnings of free software and its net benefit to society. Without it we wouldn't even have the code generators we have today.
> A single archive of public exploit PoCs and vulnerability research writeups. At the time I post these, none have been reported. Feel free to report them yourself and take credit for the CVE if handed out lulz. Please do not abuse these. I do this so to allure people into the field, and I've always found this is the most efficient way.
Which is roughly the definition of zero day. Whether the contents of the repo reflect the above claim is something else entirely.
The problem ultimately came from not being able to prevent stale pointers. The attack works by figuring out the size of the stale pointer, then spraying memory with data of the same size, and finally achieving RCE (Remote Code Execution). How do people even come up with ideas like this?
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.
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.
functionmouse•28m ago