33 ms·

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 Blowfi

by Zr40 4y 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 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-0567

bawolff 4y 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 4y 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.
  - donatj 4y ago
    That requires a database vulnerability to be exploited though, the average user can’t go setting hashes.
    - masklinn 4y ago
      Chaining vulnerabilities is a common way to exploit systems.
      - ircmaxell 4y ago
        True, but in this case if you can write an invalid hash into a database, you can likewise write a valid one, and as such this doesn't really enable anything. 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"...
        masklinn 4y ago
        Which is one thing it enables: silent co-use. If your goals are related to long-term use or surveillance, this is useful.
    - eptcyka 4y ago
      PHP is the king of SQL injections, they are often not too hard to come by on a lot of deployments. Sure, if you use modern PHP with modern toolkits/frameworks/libraries and you follow OWASP and are a competent developer, you might never introduce such vulnerabilities in your codebase. But PHP didn't gain popularity because it had frameworks that were concerned about security or that it had a trove of security conscious developers - it thrived because any 13 year old could string together a website that was as minimum of a viable product as possible.
      - donatj 4y ago
        If you have a sql injection vulnerability they literally already have the keys to the castle. This in addition gets you nothing you didn’t already have simply by setting the hash to a known value.
        brookst 4y ago
        How would you persistently log into another user’s account, without them knowing anything was wrong and without knowing their password, with just sql injection?
        bawolff 4y ago
        Well i kind of agree with you that the covert persistence aspect makes this a borderline low severity bug, but pivoting from DB->access isn't exactly unheard of. 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.
- madsbuch 4y 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.
  - bawolff 4y ago
    > I smell an underlying sentiment of "if the attacker has access to the DB, then it is broken anyways" 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.
    - madsbuch 4y ago
      Again, not necessarily. This depends on the hashing scheme you use. Eg. if setting a correct password hash relies on you having access to private keys.
      - bawolff 4y ago
        No it does not. Either you allow bcrypt hashes, or this bug is inapplicable. If you are encrypting your hashes or something, then this bug cannot be leveraged.
        madsbuch 4y ago
        Yes, for this very specific bug. This thread taked about having access to the database as a general attack vector.
  - donatj 4y ago
    Nope. Blowfish doesn’t use a manually defined salt. It generates one itself randomly every time and includes it in the hash result string which you generally store the entire string in the database. No secret salt involved.
- perlgeek 4y 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 4y 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.
  - bawolff 4y ago
    That's like arguing everything causes cancer, therefore smoking is fine.
    - tialaramex 4y ago
      The equivalent of an argument that everything causes cancer => smoking is fine would be all bugs are security bugs => don't bother fixing the bug underpinning a known a remote code execution exploit. 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.

by Zr40 4y ago

bawolff 4y 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 4y 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.
- donatj 4y ago
  That requires a database vulnerability to be exploited though, the average user can’t go setting hashes.
  - masklinn 4y ago
    Chaining vulnerabilities is a common way to exploit systems.
    - ircmaxell 4y ago
      True, but in this case if you can write an invalid hash into a database, you can likewise write a valid one, and as such this doesn't really enable anything. 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"...
      - masklinn 4y ago
        Which is one thing it enables: silent co-use. If your goals are related to long-term use or surveillance, this is useful.
  - eptcyka 4y ago
    PHP is the king of SQL injections, they are often not too hard to come by on a lot of deployments. Sure, if you use modern PHP with modern toolkits/frameworks/libraries and you follow OWASP and are a competent developer, you might never introduce such vulnerabilities in your codebase. But PHP didn't gain popularity because it had frameworks that were concerned about security or that it had a trove of security conscious developers - it thrived because any 13 year old could string together a website that was as minimum of a viable product as possible.
    - donatj 4y ago
      If you have a sql injection vulnerability they literally already have the keys to the castle. This in addition gets you nothing you didn’t already have simply by setting the hash to a known value.
      - brookst 4y ago
        How would you persistently log into another user’s account, without them knowing anything was wrong and without knowing their password, with just sql injection?
        bawolff 4y ago
        Well i kind of agree with you that the covert persistence aspect makes this a borderline low severity bug, but pivoting from DB->access isn't exactly unheard of. 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.
madsbuch 4y 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.
- bawolff 4y ago
  > I smell an underlying sentiment of "if the attacker has access to the DB, then it is broken anyways" 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.
  - madsbuch 4y ago
    Again, not necessarily. This depends on the hashing scheme you use. Eg. if setting a correct password hash relies on you having access to private keys.
    - bawolff 4y ago
      No it does not. Either you allow bcrypt hashes, or this bug is inapplicable. If you are encrypting your hashes or something, then this bug cannot be leveraged.
      - madsbuch 4y ago
        Yes, for this very specific bug. This thread taked about having access to the database as a general attack vector.
- donatj 4y ago
  Nope. Blowfish doesn’t use a manually defined salt. It generates one itself randomly every time and includes it in the hash result string which you generally store the entire string in the database. No secret salt involved.
perlgeek 4y 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 4y 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.
- bawolff 4y ago
  That's like arguing everything causes cancer, therefore smoking is fine.
  - tialaramex 4y ago
    The equivalent of an argument that everything causes cancer => smoking is fine would be all bugs are security bugs => don't bother fixing the bug underpinning a known a remote code execution exploit. 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.