That's interesting, but i don't see how this can actually be leveraged into a vulnerability.
But gosh, between this and the sha with null truncating bcrypt bug, php has had bad luck implementing password routines.
But gosh, between this and the sha with null truncating bcrypt bug, php has had bad luck implementing password routines.
> 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
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.
The one thing this does get you is that the original password would still work (technically any password would still work) so it may make it harder to detect since the user wouldn't "suddenly be locked out"...
I would first of all, wonder why i would want that. Why access someone's account when i could just dump the DB. Obviously it depends on context, but most of the time, DB access is more valuable than account access.
I would check if the DB is misconfigured (e.g. In mysql, does the DB user have File or Super rights?)
I would dump all the passwords and see if anyone's is weak enough to suffer from a crack attempt
I would check if there is anything in the DB that looks like php serialized data (People are saying unfair things about PHP like it being the king of sql injection, but its probably fair to say that unsafe deserialization is pretty common in php).
As a last resort, i would check if there is anything that looks like HTML or JS in the database, and see if i could get an XSS to leverage into an account take over.
you could say the same about python, javascript, ruby.. didn't implement a calculator at high school in C++?
> the king of SQL injections
that would be bob https://xkcd.com/327/
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.
To be more clear, my position is - if the service allows you to set the password for an arbitrary user, then it is broken anyways.
Either you allow bcrypt hashes, or this bug is inapplicable. If you are encrypting your hashes or something, then this bug cannot be leveraged.
Which you must presume they do. If any part of your security relies on the salt being secret, that's a much bigger vulnerability than this.
That said, I do think there's a potential vulnerability here, because it allows you to break in if you can only corrupt another user's password hash (rather than controlling it entirely). Think a rowhammer attack or something.
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.
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.
Which is not at all what I was getting at. Again, don't spend time trying to argue why this or that bug is probably fine actually and not "really" a security problem, fix it and then it isn't.