php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #76272 hash_hmac improper handling invalid parameter types
Submitted: 2018-04-25 20:21 UTC Modified: 2018-04-26 14:42 UTC
From: sven at rtbg dot de Assigned:
Status: Open Package: hash related
PHP Version: 5.6.35 OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: sven at rtbg dot de
New email:
PHP Version: OS:

 

 [2018-04-25 20:21 UTC] sven at rtbg dot de
Description:
------------
The "hash_hmac" function does not properly handle passing anything else than strings as their parameters.

Is is especially problematic for the second parameter "$data", because usually you'd be likely to pass externally controlled data into it.

Calling the function with something like an array instead of a string will trigger a warning, and return "NULL" as the function result. This is not documented.

The behavior is present since the introduction of the function in PHP 5.1.2.

Test script:
---------------
<?php
var_dump(hash_hmac('sha256', array(), 'secret'));
?>

See this in action at https://3v4l.org/7QtjC

For an interesting video examining a bug hunting challenge that is based on this behaviour, see https://www.youtube.com/watch?v=MpeaSNERwQA

Note that the actual result (below) is the same if you pass the array as first or third parameter (with different parameter count, of course).

Expected result:
----------------
A security related function should stop working and terminate the script with an error if something is wrong in their input parameters.

I cannot see any valid use case in letting "hash_hmac" operate on parameter types different from strings.

Actual result:
--------------
Warning: hash_hmac() expects parameter 2 to be string, array given in /in/7QtjC on line 3
NULL

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-04-26 14:42 UTC] cmb@php.net
> Calling the function with something like an array instead of a
> string will trigger a warning, and return "NULL" as the function
> result. This is not documented.

It is, see <http://www.php.net/manual/en/functions.internal>.

Note that this is standard behavior for most functions, so we
can't change that generally due to BC concerns.  Changing It
individually for some functions might be an option, but would
certainly require discussion on internals@ and likely the RFC
process[1].

Note also that as of PHP 7.0.0 strict_types is supported, which
will throw an exception for unexpected input types[2].

[1] <https://wiki.php.net/rfc/howto>
[2] <https://3v4l.org/sqII8>
 
PHP Copyright © 2001-2018 The PHP Group
All rights reserved.
Last updated: Fri Oct 19 16:01:25 2018 UTC