top | item 34909789

(no title)

Zr40 | 3 years ago

As described in the CVE[0]:

> In PHP 8.0.X before 8.0.28, 8.1.X before 8.1.16 and 8.2.X before 8.2.3, password_verify() function may accept some invalid Blowfish hashes as valid. If such invalid hash ever ends up in the password database, it may lead to an application allowing any password for this entry as valid.

[0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-0567

discuss

order

bawolff|3 years ago

> If such invalid hash ever ends up in the password database, it may lead to an application allowing any password for this entry as valid

Again - how would that possibly be a security vulnerability? Like, its a really interesting security adjacent bug, but clearly not a security issue.

If the attacker has the ability to set a hash, they can just set the hash to a known password.

brookst|3 years ago

One scenario would be setting another user’s password to the invalid hash so they can continue to log in with their existing password, and you can also log in without knowing that password.

perlgeek|3 years ago

There are scenarios, but they are pretty out there.

For example, a service might import hashed passwords from a directory, and an attacker has limited influence on the network connection to cause some random-ish data corruption.

> Like, its a really interesting security adjacent bug, but clearly not a security issue.

I kinda disagree. We often think of security in layers, and an unexpected fail-open behavior in any layer should be treated as a (potential) security issue.

The impact might be low because you expect another layer (like protection of the password database) to prevent exploits, but there could always be corner cases where that assumption doesn't hold 100%, especially in something as fundamental as a language built-in, a system call or something like that.

So IMHO it's pretty low severity, but still a security issue.

tialaramex|3 years ago

In effect all bugs are security bugs. When people offer an excuse, what they're telling you is that they don't care about correctness, which in turn means they don't actually care about security only about appearances.

Why are all bugs security bugs? Because security depends on the actual behaviour of the software, and bugs cause this behaviour to deviate from your intended and documented behaviour in unknown ways which means they have unknown impact on security. Figuring out whether any user of the software actually incurs a security impact as a result of any particular bug is likely to be far more work than fixing it, so just fix it.

madsbuch|3 years ago

> If the attacker has the ability to set a hash, they can just set the hash to a known password.

That requires the attacker top also have access to the salt

I smell an underlying sentiment of "if the attacker has access to the DB, then it is broken anyways". This is not entirely true. Think a gateway service that lets the user to something on another service with access without access to the database immediately giving access to the system.

This is definitely a security bug.