What are the security implications of passing binary data to a non-binary-safe function?

Question

In PHP, the term "binary-safe" sounds to me like a security feature to help defend against binary exploitation such as a buffer overflow, etc.

I'm also aware that some functions have "multi-byte aware" alternatives that are prefixed with mb_. For example, substr and mb_substr. These functions are able to handle characters that consume more than one byte.

However, what are the implications of passing binary data into a function that is not binary safe? Is this an inherent security risk, or will the function just return a warning/error?

I am not talking about the output of the function that may be passed into SQL, HTML, etc, I'm talking about the actual processing of the function within PHP itself.

Are non-binary-safe functions only designed to securely handle text, and there is a risk of a buffer overflow or other form of binary exploitation when passing binary data into them?

safe means it will not bork out.. has nothing to do with security. Dupe of: https://stackoverflow.com/questions/3264514/in-php-what-does-it-mean-by-a-function-being-binary-safe — Lawrence Cherone, Mar 19 '18 at 21:22
The output and/or behavior of functions that are not binary-safe is undefined if given binary input. As Lawrence said, safety != security. — Peter, Mar 19 '18 at 21:25
No, binary safe doesn't mean "it's safe against random kid entering some random sequence of weird characters that gives them root access to your machine". It's.. not that. — N.B., Mar 19 '18 at 21:25
Possible duplicate of [In PHP what does it mean by a function being binary-safe?](https://stackoverflow.com/questions/3264514/in-php-what-does-it-mean-by-a-function-being-binary-safe) — Peter, Mar 19 '18 at 21:26
Thank you for the clarifications. @N.B. what can I do specifically to protect against that? Is that just validating user input before it is passed out of PHP, or do I need to do something while it is handled within PHP? For example using the `mb_` functions? — jamieweb, Mar 19 '18 at 21:31
There's nothing inherently wrong with PHP itself that would expose your machine in such a way. You can always configure your web server and sanitize requests, such as deny everything larger than a few kilobytes, but there's so many different ways, techniques, bugs and exploits floating around that PHP is the least of your worry. Don't trust random blogs out there, PHP isn't a bad language nor is it insecure. — N.B., Mar 19 '18 at 23:14
@N.B. Thank you for your help. The reason I'm asking is because I have some code that reads data using `fgets()` straight from `fsockopen()` - I'm expecting ASCII text, but anything can be sent, so I was concerned that some carefully crafted bits could exploit the functions used for input validation (`substr`, `rtrim`, `strtolower`, `filter_var`, etc) or something else. I guess that'd require a serious vulnerability in PHP though? In that case, we'd all be in the same boat. (I'm aware that using those functions could also allow an attacker to construct a particular string, eg: GBK `0xbf27`.) — jamieweb, Mar 19 '18 at 23:32

score 0 · Answer 1 · answered Sep 11 '18 at 20:36

What are the security implications of passing binary data to a non-binary-safe function?

It really depends on what you're doing.

When Facebook was trying to remove the mbstring requirement from their PHP-Graph-SDK repository, they accidentally introduced the risk of message forgery:

function sammy_hash_equals($knownString, $userString)
{
    $kLen = strlen($knownString);
    $uLen = strlen($userString);
    if ($kLen !== $uLen) {
        return false;
    }
    $result = 0;
    for ($i = 0; $i < $kLen; $i++) {
        $result |= (ord($knownString[$i]) ^ ord($userString[$i]));
    }
    // They are only identical strings if $result is exactly 0...
    return 0 === $result;
}
// 8 chars but 32 bytes
$hashA = "\xF0\x9D\x92\xB3" . "\xF0\x9D\xA5\xB3" .
         "\xF0\x9D\x92\xB3" . "\xF0\x9D\xA5\xB3" .
         "\xF0\x9D\x92\xB3" . "\xF0\x9D\xA5\xB3" .
         "\xF0\x9D\x92\xB3" . "\xF0\x9D\xA5\xB3";

$hashB = "\xF0\x9D\x92\xB3" . "\xF0\x9D\xA5\xB3" .
         "\xF0\xAD\x9F\xC0" . "\xF0\xAD\x9F\xC0" .
         "\xF0\xAD\x9F\xC0" . "\xF0\xAD\x9F\xC0" .
         "\xF0\xAD\x9F\xC0" . "\xF0\xAD\x9F\xC0";

var_dump(sammy_hash_equals($hashA, $hashB));

In this case, the configuration setting mbstring.func_overload would have dictated whether or not this was exploitable. And then it would have only been exploitable if someone tried to use hash_equals() in a PHP 5.5 (or earlier) project with this configuration and used the earlier version of Sammy's patch.

The most you'll run into is that your data gets corrupted (a.k.a. mangled) and you have to deal with the challenging task of recovering it and/or cleaning it up. It's not fun.

Are non-binary-safe functions only designed to securely handle text, and there is a risk of a buffer overflow or other form of binary exploitation when passing binary data into them?

No, there's no buffer overflow risk here.

What are the security implications of passing binary data to a non-binary-safe function?

1 Answers1