Описание
password_verify can erroneously return true, opening ATO risk
Summary
If a password stored with password_hash
starts with a null byte (\x00
), testing a blank string as the password via password_verify
will incorrectly return true
.
If a user were able to create a password with a leading null byte (unlikely, but syntactically valid), an attacker could trivially compromise the victim's account by attempting to sign in with a blank string.
Details
This appears to exist at least back to 8.1.0: https://3v4l.org/Z0pcl
PoC
$ cat pw_bug.php
$ php pw_bug.php
Impact
Medium?
This could be catastrophic in the right circumstance, but the chance of that circumstance existing is extremely low. Typically a user would get blocked from setting a password containing (never mind starting with) binary data through input filtering and application-specific password rules. Similar rules are likely employed on the checking side, though usually less strict.
Пакеты
< 8.1.28
8.1.28
< 8.2.18
8.2.18
< 8.3.5
8.3.6
Связанные уязвимости
In PHP version 8.1.* before 8.1.28, 8.2.* before 8.2.18, 8.3.* before 8.3.5, if a password stored with password_hash() starts with a null byte (\x00), testing a blank string as the password via password_verify() will incorrectly return true.
In PHP version 8.1.* before 8.1.28, 8.2.* before 8.2.18, 8.3.* before 8.3.5, if a password stored with password_hash() starts with a null byte (\x00), testing a blank string as the password via password_verify() will incorrectly return true.
In PHP version 8.1.* before 8.1.28, 8.2.* before 8.2.18, 8.3.* before 8.3.5, if a password stored with password_hash() starts with a null byte (\x00), testing a blank string as the password via password_verify() will incorrectly return true.
In PHP version 8.1.* before 8.1.28, 8.2.* before 8.2.18, 8.3.* before ...