Hacker News new | ask | show | jobs
by s_q_b 3487 days ago
I have had four zero-days affecting 5.5 million devices sitting on a public code repository for two months now, for a project maintained by dozens of corporations employing high-end PHP programmers, who do write PHP for a living.

The fixes are code reviewed, but not merged, because the developers don't seem to understand PHP-into-C null string terminator vulnerabilities, or type juggling, or strict comparison, or... I could go on.

PHP is unsafe at any speed, because it almost invites arbitrary code execution through a number of vectors. It isn't inherently bad if used correctly, as most Facebook developers will tell you, but the language structure involves quite a number of insecure practices.

After all, most programmers don't expect:

<?php 0 == "string"; ?> to be true.

4 comments

> After all, most programmers don't expect: <?php 0 == "string"; ?> to be true.

nobody would expect that

Experienced Perl programmers would, and PHP took inspiration (altough in crippled way) from Perl.
Anyone who ever programs in a weakly-typed language should be aware that comparing two values with different types will involve type coercion, that there are obviously strange edge cases when that happens, and that comparing with a strict comparison operator such as === is good defensive programming in those contexts.
Wait, is GP saying that IS true in php?!?!
My favorite is that two obviously different hexadecimal values in strings (e.g. checking password hashes) can be "equal" with the weaker == comparison.

This occurs if PHP thinks both strings could be numbers in scientific notation. "0e123" == "00e45"

It gets worse: https://3v4l.org/Slvpp

Note that PHP also has a JavaScript-style triple-equals comparison, which does not attempt type conversion and does not exhibit this bizarre behaviour.

Yeah, go check in a sandbox.
Can I see a link? Just curious about the vulnerabilites. What's a PHP-into-C null string terminator vulnerability?
Google null-byte injection.

As for the framework, that's RDK-B. http://rdkcentral.com http://code.rdkcentral.com https://github.com/rdkcmf

The deeper you look, the worse it gets. Those php issues are very trivial, first glance type stuff. Some need a bit of a twist to make exploitable, but another will strip the encryption right off the hidden network.

I have others I wish to disclose, but I can't seem to get them to respond to my requests for a PoC. Quite frankly, I'm shocked that I can't seem to get anyone to realize how serious the impact of an RCE vulnerability in a framework fielded that widely truly is.

If you find any of more serious things I'm talking about on your own, wait for the vendors to fix them. Please don't brick the world.

>PHP-into-C null string terminator vulnerabilities

They should still be fixed, but I believe these bugs are no longer an issue in PHP after 5.3.

> It isn't inherently bad if used correctly

Is BAD. Imagine if a car was made with the same "design".

A tool is BAD if the user must patch to overcome the inherent behaviour it show.

The parent poster already referenced "unsafe at any speed" so I think they are already aware of the car analogy :)
The parent poster already referenced "unsafe at any speed" so I think they are already aware of the car analogy :)