No the punishment should be harsher, not for an hour but 40-60 hours, or fine of $1000-2000. Otherwise they will never learn to respect rules. Especially in the subway where you cannot "accidentally" jump over the turnstile.
I regularly see how people are not paying the bus fare (here in Russia). And the only reason why they do not pay is because the punishment is light (fine of ~25 USD) and chance of being caught and actually prosecuted is close to zero. So paying does not make economical sense.
To be fair, 2024's "PHP-CGI" and "Windows" are legacy features nobody is probably using. CGI was a technology to write servers using bash scripts (most popular programming language for Linux) and has been outdated for like what, 20 years?
That's not what CGI is. CGI is just mode of operation where full php process being spawned on each request and then killed. It's kind a less prone to security actually because no memory or state is reused ever.
But yeah since it's inefficient I doubt it used much after 2010 when php-fpm matured and nginx got popular.
No. I think writing PoC and exploits is a waste of time and nobody should do it. PoC brings zero value to society and only helps criminals. If there is use-after-free, it is potentially exploitable and needs to be fixed ASAP. If you don't believe the theory, just keep using the vulnerable version.
From my understanding, the vulnerability is a use-after-free, i.e. PHP allocates memory, stores pointer to it, frees it, maybe re-uses the memory for something new and then accesses the pointer. So totally exploitable.
Note that use-after-free would be prevented in memory-safe languages such as Java, Go or Rust.
PHP itself is a memory safe language, this is a bug in the language implementation and VM. Which happens in other memory safe languages like Java or C#. This is sort of the equivalent of a Rust compiler bug that allows unsafe behavior to slip through, which also exist.
No, PHP interpreter is written in C where such things happen every 100 lines of code. If PHP interpreter was written in Rust, this vulnerability wouldn't exist.
To be fair, C has simplicity as an attractive feature (compared to other languages) but being memory-unsafe is unacceptable, so we need either memory-safe C or stop using it.
Most interpreters or runtimes are written in unsafe languages. Including V8 (Chrome and Node), C#, and others. Also PHP is not really interpreted, it works just like C# or Java where it's compiled to bytecode that runs on a virtual machine.
Not all UAF are explotiable. It really depends on what code that uses the stale pointer does with it and how controllable the freed/re-used data are. Although when evaluating I'd count much more on the first condition, rather than the second one, which may not be so easy to ascertain.
> Note that use-after-free would be prevented in memory-safe languages such as Java, Go or Rust.
There are also hardened malloc/free implementations for C based runtimes. Of course none of that is perfect, the famous heartbleed exploit for example bypassed any outside memory protection as the library agressively reused already allocated buffers, none of the languages you named would protect against that.
Yeah? You got it working? Then why can't it pawn my webserver running php-5.6 and drupal 7? Should be pretty easy, those are both unpatched ancient versions.
Probably because you're too cheap to spend $5 on DeepSeek tokens? Its specifically labeled for a 8.4 version IIRC.
I'm not sure what your question is or what you're getting at. The only time-sink for general purpose exploit is to churn through previous PHP versions to get the right offsets/struct sizes and common memory configurations.
Do you think security is done by running obscure configurations?
I don't understand what you mean with demonstrate. You want me to post the php2shell for their set-up?
Its not "if" this is easily exploitable; its what you two want to define as easily exploitable.
It already is by my definition - that is also the clear majority opinion (unless you want to appeal to specific authorities that agree with your alternative definition).
As far as i can tell i've already posted more than enough proof with that github link for anybody that is a bit curious and with passing knowledge of exploits.
I'm stuck guessing at what more you want or expect of me in a random HN thread. I'm inclined to just wait 24h and there will be a public version that hacks this hypothetical php-5 set up as well.
You both clearly have a different definition of easily exploitable; and until somebody tells me what that definition is and what background knowledge I can assume I have very little I can do here except guess at what you're both ignorant off.
> I don't understand what you mean with demonstrate.
I was quiet clear I thought. I wanted a working exploit. Someone to demonstrate that my (or someone else's) server can be hacked with this exploit. So far what you've provided is a tightly constrained lab example where you have to control the amount of memory given to a server (significantly I might add), modify the apache and php configuration way outside sane values (exactly 1 worker, 8MB memory limits), have knowledge of the exact php build used on the server and how it is being ran (mod_php here).
In a standard webserver, you're not going to know any of that or have control to make any of that happen. Nobody is running a PHP website on a 128MB ram VPSs, nobody is running with exactly one apache worker. You're not going to know ahead of time which build of php they're using, or if they built from source.
I had to keep guessing at how much you actually know about this stuff, but given you brought up the workers as a constraint means you are either completely clueless and/or have absolutely 0 intention to think for yourself.
No 'proofs' like "demonstrate on someone else's server" or explanation of the exploit chain will ever be enough to convince you.
You dont want "a working exploit" - and we could have all saved some time if you were honest: You don't know what you're talking about and only after being given a complete exploit you can run against any target will you consider it easy by your standards.
Good talk. By your definition of easy, i can easily agree this exploit is not very easy. Though the settings dont matter/can be bisected remotely, you're right that - afaik - nobody has figured out how to avoid guessing the compile settings and version. Thus compiling it with custom settings is going to keep you safer in practice, while using a container is more dangerous.
I actually looked through PHP code responsible for parsing POST request body and it's pretty bad [1].
First, there is a huge function, that is hard to read and reason about. Second, instead of proper parsing of "Content-Type" header to extract "boundary" parameter, there is just a set of substring searches which is not correct. It doesn't mean there is a vulnerability but it means PHP can read the header in a way different from a standard-compliant implementation (such as web server, WAF etc).
The point is to prove you control a domain. If you are answering traffic to requests from clients at that domain, you control it. Whether you're supposed to have control over it is outside the scope of this validation
If you're answering traffic then it means some service has been delegated to you. And if you were delegated https I think it's fine to give you an https certificate.
But that's not controlling "the domain" in my book. You control the domain if you control the nameserver.
Agreed. On the other hand, these DV certificates only claim to verify who _controls_ the domain. Probably, you can agree that hosting provider and government can also control the domain, no? :)
Moreover, with dns-01, DNS provider can issue fake certificates - unless you self-host DNS - in which case, only your DNS registrar can... and a government.
> Moreover, with dns-01, DNS provider can issue fake certificates - unless you self-host DNS - in which case, only your DNS registrar can... and a government.
Which is what DNSSEC is supposed to help with: the registrar/government would have to replace your DS/KSK with their own. Without DNSSEC queries/replies could potentially be altered over the wire (or you're in a race condition as to whether the real or attacker's reply get back first).
I regularly see how people are not paying the bus fare (here in Russia). And the only reason why they do not pay is because the punishment is light (fine of ~25 USD) and chance of being caught and actually prosecuted is close to zero. So paying does not make economical sense.
reply