what did you learn today? (part 2)

w00key

Ars Tribunus Angusticlavius
9,960
Subscriptor
Script kiddies calling a local php evil_script.php "proven RCE" is just 🤦🏻‍♂️

https://github.com/dinosn/php-8.5.5-var_destroy-uaf/

I was like, Claude, am I going crazy or is this bullshit?

You're not going crazy. The README itself concedes the point in a few places — it calls it a proven, reliable, local RCE exploit and says the chain works whenever the attacker controls the PHP script (local, eval, file upload + include, etc.).

That is "arbitrary PHP code → arbitrary native code," which is a sandbox escape / privilege boundary break, not remote code execution in the normal sense. If you can already run PHP on the box, you can already call system without any UAF.

"Local remote code execution" fucking lol. Dumbass with a Claude subscription roleplaying security researcher.
 

Entegy

Ars Legatus Legionis
18,250
Longtime Microsoft developer Raymond Chen posts this kind of thing every once in a while. Someone sends in a "vulnerability report" to Microsoft and it starts with "run this as admin". The "vulnerability" is not that you gained admin rights when you shouldn't, it's that you're doing stuff to the system as administrator. Example.

There was a meme comic I saw a long time ago about someone trying to run an infected pirated game, and every Windows security feature under the sun was stopping it from executing. The user forcibly disables every security feature in his way, then goes shockedpikachu.jpg when his computer is infected. It ends with "Fuck Microsoft for making Windows so insecure".

Some people think too highly of themselves.
 

Tremere

Ars Centurion
345
Subscriptor
It's nice that we don't run PHP anywhere so not impacted by the current shenanigans. It's less nice that we still have to go through everything we run and collect explanations of why it's not vulnerable, including documentation, because everyone is losing their mind over it.
This is my day too. I’m pretty sure my director either can’t or won’t read at this point.

The few things we do have are running it on the management side and we of course follow best practices limiting that access. Patches don’t even exist for them yet as they are virtual appliances. Director has been told this 3 times now. Maybe if I write it out in crayon the 4th time.
 
  • Hug
Reactions: Vince-RA

Dzov

Ars Legatus Legionis
16,278
Subscriptor++
Longtime Microsoft developer Raymond Chen posts this kind of thing every once in a while. Someone sends in a "vulnerability report" to Microsoft and it starts with "run this as admin". The "vulnerability" is not that you gained admin rights when you shouldn't, it's that you're doing stuff to the system as administrator. Example.

There was a meme comic I saw a long time ago about someone trying to run an infected pirated game, and every Windows security feature under the sun was stopping it from executing. The user forcibly disables every security feature in his way, then goes shockedpikachu.jpg when his computer is infected. It ends with "Fuck Microsoft for making Windows so insecure".

Some people think too highly of themselves.
Shoot. I've heard of intrusion testers that require you disable your security so they can actually intrude.
(Maybe that's SOP. We don't process credit cards, so aren't required to do these tests)
 

Dzov

Ars Legatus Legionis
16,278
Subscriptor++
This is my day too. I’m pretty sure my director either can’t or won’t read at this point.

The few things we do have are running it on the management side and we of course follow best practices limiting that access. Patches don’t even exist for them yet as they are virtual appliances. Director has been told this 3 times now. Maybe if I write it out in crayon the 4th time.
You could always block those appliances until patched if you want to be maliciously compliant.
 

sryan2k1

Ars Legatus Legionis
46,815
Subscriptor++
Shoot. I've heard of intrusion testers that require you disable your security so they can actually intrude.
This is normal and it really depends on what they are testing. They want to find all the vulnerabilities you have inside, not just if they broke past some outer defense.
 

sryan2k1

Ars Legatus Legionis
46,815
Subscriptor++
Right. There are 100 vectors of getting inside that might not just be hammering at the firewall, like some idiot user starts a go to remote session with a fake helpdesk call.

You want to know where all the weaknesses are, and if the tester said "Couldn't get in the front door" that doesn't really tell you a lot.
 

kperrier

Ars Legatus Legionis
21,458
Subscriptor++
The whole revocation of public/private keys has never really worked, unfortunately. We educate customers how to change the cert store to move those to the "untrusted" cert store for immediate action/remediation and we have updated certificate stores to install were we have done that. PKC has never really met the promise it initially had.
 
  • Like
Reactions: Vince-RA
The whole revocation of public/private keys has never really worked, unfortunately. We educate customers how to change the cert store to move those to the "untrusted" cert store for immediate action/remediation and we have updated certificate stores to install were we have done that. PKC has never really met the promise it initially had.
you are right. I suppose I'm just flagging that if they understood/could do revocation the implementation for it is also broke now it seems on a very large swathe of hardware. Happened to watch
View: https://www.youtube.com/watch?v=-9KiLFr8_hI
(can't remember if it was linked here or not) tonight and then this just landed so perfect swarm for me, hence the post
 

tigas

Ars Tribunus Angusticlavius
7,539
Subscriptor
There's a small chance of revocation working as designed on an intranet.
On the Internet it's so broken that continuous automated renewal is becoming the only path forward.
https://axelspire.com/vault/operations/certificate-revocation-crl-ocsp/

Problem Statement​

  • Soft-fail lets attackers block OCSP and still get connections—users assume “green lock = safe.”
  • CRL size and cache staleness delay propagation even when CRLs are correct.
  • Non-browser stacks (OpenSSL, curl) often skip revocation unless explicitly configured—VPN/proxy gear may differ and break on CA policy changes.
  • Stapling fails silently when responders are down—Must-Staple did not save the ecosystem.
  • Short-lived certs require reliable automation—failure mode is outage, not slow revocation.
  • Private PKI still uses CRL/OCSP patterns you control—different tradeoffs than browsers.
Failure scenario: Team staples OCSP for monitoring; CA migrates to CRL-only; stapling stops; nobody notices until a compliance scan flags missing stapling—while browser trust was never dependent on it.
https://my-ssl.com/learn/certificate-revocation-crl-vs-ocsp

What browsers actually do​

Faced with soft-fail and OCSP's privacy cost, the major browsers stopped relying on live, per-connection checks and built their own pre-computed revocation data instead — downloaded in advance, checked locally, with no request to any CA at connection time.

Chrome — CRLSets​

Chrome long ago disabled online OCSP and CRL checks for most certificates and instead ships CRLSets: a curated list of revoked certificates that Google compiles and pushes out through Chrome's component-update channel. It's fast and private, but it's deliberately not comprehensive — Google curates which revocations make the cut, so CRLSets function mainly as an emergency block-list for high-impact revocations rather than a complete record of everything every CA has revoked.

Firefox — CRLite​

Mozilla took the more ambitious route. CRLite crawls the CRLs of all publicly-trusted CAs and compresses the entire set of revoked certificates into a compact filter — only a few megabytes — that ships to the browser and is queried locally. It aims for the comprehensiveness of CRLs with the speed and privacy of a local check. Mozilla enabled CRLite for all desktop Firefox users in 2025 and began turning off live OCSP for domain-validated certificates in favor of it.
The common thread: revocation moved from "ask the CA at connection time" to "download a compressed snapshot ahead of time and check it locally." That's faster, leaks nothing to the CA, and — crucially — can be made hard-fail, because a local lookup never has a network hiccup to soft-fail on. It also explains why the raw CRL, the oldest mechanism, turned out to be the right source data after all.
 

Paladin

Ars Legatus Legionis
33,786
Subscriptor
... And continuous automated renewal (short-lived certs) means you have a new vulnerable point at the centralized (or external) validation and issuing system, the distribution system, etc. No more eyes on for the renewal, so you have to make sure the automation is intelligent enough to be both hard to crack and easy to fail loudly so someone knows about it quickly. Increased frequency of 'hey, this says the cert is no good but I can just continue anyway and do what I need to do' means users become less likely to mention it when they see it, admins more exhausted from dealing with the increased workload and fragility, etc.
 

Vince-RA

Ars Praefectus
5,468
Subscriptor++
Well that's fun, we're starting an Azure Virtual Desktop pilot, and just as we turned the first users loose on it, it seems like MS has some kind of dysfunction going on. I can't even review sign-in logs because "the server is receiving too many requests". Seems like it might be fuck-this-shit-o'clock right about now.