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
Votes:2
Avg. Score:3.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: sven at rtbg dot de Assigned:
Status: Open Package: hash related
PHP Version: 5.6.35 OS:
Private report: No CVE-ID: None
 [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

Pull Requests

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-2024 The PHP Group
All rights reserved.
Last updated: Tue Nov 05 14:01:29 2024 UTC