Professional Shitposter

Joined June 2013
Since my posts have been shared here ~30 times in the past few weeks, it seems like I'm going to be contributing to Space Karen's Ketamine Extravaganza whether I like it or not. I don't really intend to be active here, but I'll post some of the more important cybersecurity-focused stuff, since it gets screenshotted anyway. That way, people don't have to read post a week late and out of context.
29
16
10
498
41,981
This is 100% correct when looking at it from a single-system perspective. ASLR does not create a significant barrier to successful exploitation. But when looking at it from a mass-exploitation perspective, there are a lot of hidden complexities that come into play. Vulnerability research is one of the few fields where you tend to make more money on the right side of the law. There isn't a huge demand for black market exploits. Most of the money is in bug bounty, working as a vulnerability researcher, or selling to grey-market exploit brokers. This means that even the smallest bit of added complexity can take a vulnerability from 'cybercriminal free-for-all' to 'unlikely to be widely exploited'. Mass-exploitation events are almost always preceded by someone publishing fully-weaponized point-and-click exploit code. It's extremely rare for criminal groups to successfully develop exploit for higher-complexity vulnerabilities on their own, even with AI. So, less researchers capable of exploiting the bug means less chance of a working weaponized exploit being posted online. But also, the increased difficulty of exploitation, thus increased time/effort, discourages those who can exploit the bug from giving it away for free. There's also per-target variability (which I don't know for sure is the case with this bug). But with more complex bugs, it'll sometimes be impossible to make universal exploits. In extreme cases, attackers may need to build exploit for each specific system or software version, or each specific config, or maybe even both. So, while it's correct that it's not hard to find an ASLR bypass, it is difficult to find a bypass that works reliably at scale. So far, most of the working exploits I've seen are limited to just a handful of PHP versions, or bruteforcing ASLR. And that makes all the difference when it comes to the risk of threat actors spraying exploits at the entire internet. For this specific exploit, the honest answer is, I don't know. It's above my pay grade. But I'm almost 100% certain that the level of bad this will be will be directly dependent on what kind of exploits security researchers make public.
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.
1
7
66
4,410
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.
18
161
16
1,199
103,864