Colin O'Brien retweeted
Re: the widely circulated blog claiming the PHP bugs aren't easily exploitable: @trailofbits has a working exploit that gets a shell on an unmodified MediaWiki installation.
eliastaylor.com/noexploit/
Incredible that php is trying to shift blame to chainguard.
Imagine releasing unsafe, dogshit software for decades and then when someone patches it a few hours early you go "yeah this is their fault".
I forked wasmtime to add additional optimizations but it's all vibecoded (explored mem64-specific opts).
I feel like this isn't something that would be interesting to send upstream, and I don't want to spend much time on prepping it. But also, significant mem64 wins.
I seriously doubt that ASLR is a meaningful mitigation here. 0 chance there aren't tons of infoleaks in a C codebase the size of php.
*Maybe* infoleaking/ controlling the heap is particularly annoying because of the nature of the vulns though.
Current information I have on php2Shell:
- The RCEs requires the attacker to obtain memory addresses which are typically protected by ASLR.
- I suspect the original author (lcfr_hax) likely has a reliable exploit which leads to stable code execution.
- Most of the PoCs being posted are completely non-functional AI slop.
- There is at least 1 working non-slop exploit being passed around, but it's reliant on bruteforcing for ASLR bypass, so not particularly impactful.
- Rumor of ITW exploitation are patchy. There are attempts being seen using the non-functional leaked RCE, or variants that are config / system specific.
- Some rumors point towards a known-working exploit being used by threat actors (I've personally confirmed this specific exploit works, but the ASLR bypass technique is unreliable at best and massively limits the potential impact).
- I'd expect heavy ITW exploitation in the next few weeks based on how many people are looking at this. Though, success rates will vary heavily based on the specific exploit chain.
I believe pretty strongly that vulnerabilities in software will be inexhaustible, regardless of whether you use proofs, AI, fuzzers, etc.
I'm adding `unsafe` to witchy, except it's going to:
1. Require proofs.
2. Break up `unsafe` into `unsafe` and `trust`.
3. Tests always run with address sanitization.
4. Can't be used in build scripts.
5. Safe constructs to reduce the need (ie: what zerocopy provides in rust).
Me 5 minutes ago: "I wonder how long it will take to build a POC"
I need to start checking ToB before I tweet, this happens too often.
Re: the widely circulated blog claiming the PHP bugs aren't easily exploitable: @trailofbits has a working exploit that gets a shell on an unmodified MediaWiki installation.
eliastaylor.com/noexploit/
I'm curious to see how long it takes to get php2shell exploitable, if at all. Obviously *someone* is working on this, right?
I honest to god don't care that chainguard broke the php vuln embargo, if you want to call it a break even.
I actually don't care if anyone breaks any embargo ever.
Good on the vendors who just shut their services down while they sort out the php vuln. That's the right call.
Attack surface reduction is very cool but also it's like... the least tractable option.
"Oh just build less" yes, yes, I'll totally sell leadership on this when a customer says a feature is required for a sale lol
A major step in preventing supply chain worms is to separate "build/test" steps from "publish with creds" steps. In Github Actions this is basically:
1. Job to do build/test. Publish as a github actions artifact. `permissions: {}`.
2. Download the artifact, deploy it.
fulcrumsec.vg/pingcap/
> Four years before we walked in, their own security team had documented that any member of a customer organisation — including a billing-only role — could take over every cluster in that organisation as root
Hurts to read. Sorry buds.