I am not surprised. Several people have been nagging me to run this. I’ve always told them that I already run unbound(8), and that pi-hole is PHP, so it’s a non-starter.
If they knew what they’re doing they’d use something else than php.
Sure, and the blog post itself is on Wordpress… so also PHP.
I did appreciate the effort put into the post to see how exploitable it might be, including the limitations in this particular case. I’m also not a massive fan of PHP, but it’s part of a few things I use, and I’m aware that it’s there. In my case, it’s Pi-Hole, pfSense and TTRSS.
The thing that ties into both aspects here is that this is an authenticated issue. In other words, you would have to be currently logged in to do perform the RCE. For my uses, I’m the only person logged into any of these PHP services, though everyone on my home network gets the benefit of the first two. The vulnerability is present in this case, but in the theme of, “authenticated admin user has elevated access.” Of course they do, and that same admin probably installed the service in the first place.
And there appears to be a CSRF check, which is pretty important - otherwise even if it’s on a private LAN and authenticated-only, visiting any site that carries the payload is enough to cause this to fire.
Excellent point. That’s the sort of thing that makes home routers such a target too, along with default admin credentials and default internal IP addresses.
I haven’t checked, but Pi-Hole also has a fairly short session time-out, meaning that the window that someone might exploit this issue (if there was no CSRF check) should be short.
To be fair, the bug was missing regex anchoring followed by missing quoting of shell arguments, both of which unfortunately are very common in programming in general, independent of the chosen language.
I would blame PHP for the various command execution APIs that just take a string to feed into the shell and very few ones that take an arguments array which then are also inconvenient one way or another, but that’s also true for many other languages.
I think it’s bad that stuff like this still happens at all, but even after years of experience and even though I’m somewhat sensitized to such issues, they do still happen even to myself. Rarely, but they happen.
Security is hard. You only need to screw up once to have the same security as if you screwed up everywhere :-(
unbound has had its fair share of CVEs too, so what’s your point? (and for the record, I also run unbound)
And yet not all languages are equal. For different problems, some languages can be said to be objectively better than other languages.
Sure, but that is not what this is about. PHP is objectively better for writing webby things than, say, assembly or COBOL or APL. For writing an operating system I’d rather use assembly and other low-level languages, etc. What this is about is the generic whinging which some are wont to produce when confronted with popular-unpopular languages.
So why is a complaint annoying that could, if one is being gracious, be read as a criticism of PHP in the network stack and DNS space? Wouldn’t that be within the bounds of acceptable discourse, into which your comment comes just to remind everybody how such comments are to be read?
Generic comments referring to opinionated refutations of languages are always annoying since they do not add anything of value to the discussion, they’re the language version of ‘Windoze sucks’, ‘leenucks sucks even more’, ‘Macs are drool-proof because they are made for babies’ and such.
It would be different if they criticism was pointed and accurate, i.e. if the CVE was clearly caused by some deficiency in PHP which would have been avoided had the developers only used $language_a or $language_b.