If only there was a tool that could automatically run tests as code is committed into source control.
GitLab on Thursday issued security updates for three versions of GitLab Community Edition (CE) and Enterprise Edition (EE) software that address, among other flaws, a critical hard-coded password bug. The cloud-hosted software version control service released versions 14.9.2, 14.8.5, and 14.7.7 of its self-hosted CE and EE …
Friday 1st April 2022 20:39 GMT HildyJ
Saturday 2nd April 2022 11:09 GMT low_resolution_foxxes
Re: Hard coded passwords
I admit I am predisposed to a cynical and paranoid nature, but let us step back and consider the nature and effect of this coding.
This bug is a very specific and intentional bug. It's not an obvious developer bug, a misfiring accidental software line or mild slipup.
To me, it looks like a deliberate backdoor effort that has gone to moderate lengths to avoid detection. Presumably it was leaked or discovered. What is odd, is that this is not a decades old bug, it seems to have been launched in January 2022.
"generated a fake strong password for testing by concatenating "123qweQWE!@#" with a number of "0"s equal to the difference of User.password_length.max"
I mean seriously....does that sound like an accidental bug to you?
Saturday 2nd April 2022 11:34 GMT gnasher729
I thought the principle would be that you don’t check the password, but that the password is used to decrypt some key.
For example, on an iPhone a 256 bit number inside the processor, a 256 bit number stored on your drive, and your passcode are hashed to gather and then used to decrypt a master key. So no matter what security you break, it’s impossible to break in without the passcode. There is additional security that can be broken, but you need the passcode to unlock.
Monday 4th April 2022 01:40 GMT Andrew Hodgkinson
That's correct, but...
...the way it works is that the unknown plain text password supplied by the user is hashed and compared with the existing one-way hashed database record. If there's a match, we deduce (via confidence in the unique-output-given-unique-input mathematics of our chosen hashing algorithm) that the input plain text value matches that which was given by the user when they first signed up.
The issue here is that the _plain text_ original value for a new account is being hard-coded as a first-time password that the user hasn't chosen (under doubtless some "less obvious than it sounds" set of conditions, else it'd have been spotted much sooner). It's stored hashed, but someone can still try to hack such accounts by making simple password guess attempts based on the known "default password" approach.