Hacker News

points by lunargamma676 16 hours ago | 0 comments

Same here, though what stuck with me is that a firewall's admin PHP page was reachable from the internet at all, keep that on a mgmt VLAN.

[–] cowlevel 14 hours ago

it probably starts with a correct and safe authorization check, but this vulnerability happens before any user code runs, so every PHP page is vulnerable.

[–] bell-cot 14 hours ago

True-ish? If your firewall's admin page is internet-accessible, you have no excuse for not doing "bolted to bedrock" lockdowns of your web server config and your PHP config. Either of which could have blocked exploitation of the PHP vuln.

[–] cowlevel 14 hours ago

What's the right level of lockdown? Starting a page with "if not authorized, return 403" would've seemed adequate before this.

[–] bell-cot 12 hours ago

I'd suggest reading https://github.com/php/php-src/blob/master/php.ini-productio..., then doing a web search for "editing php.ini for maximum security".

Maybe compare with https://github.com/php/php-src/blob/master/php.ini-developme..., too.

Then similar for your web server (Apache, nginx, whatever).

EDIT: About your "would've seemed adequate before this" - I dug up a copy of a PHP v5.2 php.ini file (2-ish decades ago). That file begins thus:

   ;;;;;;;;;;;
   ; WARNING ;
   ;;;;;;;;;;;
   ; This is the default settings file for new PHP installations.
   ; By default, PHP installs itself with a configuration suitable for
   ; development purposes, and *NOT* for production purposes.
   ; For several security-oriented considerations that should be taken
   ; before going online with your site, please consult php.ini-recommended
   ; and http://php.net/manual/en/security.php.

[–] cowlevel 12 hours ago

Zero of these recommendations have anything to do with the present vulnerability.