Cnchi creates Passwords with Username as Salt

[philmmanjaro]

Problem:

The package cnchi is vulnerable due using weak password hashing as it creates users for your OS installation.

Steps To Reproduce:

Install Antergos with any version of current cnchi.

Resolution:

Users are advised to run passwd to reset their passwords on all systems installed with Cnchi. The password should be reset for both regular users and for the root user.

How To Check

• check your /etc/shadow for your user name. In this example bob
• you may find some like this: bob:$6$bob$<HASH>:<NUMBER>:<NUMBER>:<NUMBER>:<NUMBER>:::
• when you see <USERNAME>:$6$<USERNAME>$ you have a problem and should use passwd
• when fixed, you should see something like this: bob:$6$Xc7F0tzed.#f5P3r$<HASH>:<NUMBER>:<NUMBER>:<NUMBER>:<NUMBER>:::
• especially check for user root!

[lots0logs]

@philmmanjaro I agree that we should use a stronger salt for the passwords. However, I'm not convinced that this is a security concern for users who have already installed their systems using Cnchi. The /etc/shadow file is only readable by the root user. That means you would have to already know the user's password in order to access the hashed copy of said password (which makes accessing the hash pretty pointless)

@karasu @faidoc What are your thoughts on this??

Reference

• https://wiki.archlinux.org/index.php/Security#Password_hashes
• http://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils

[philmmanjaro]

Well, you use the same routine also for the user root. That is why we from Calamares development team considering it a risk.

[lots0logs]

Right but that really doesn't change anything. You must already know the password in order to access the hash. Do you disagree?

[philmmanjaro]

At least you should communicate it to your community. See also here.

It is also not a really big thing: for any given installation, the password is hashed with exactly one salt; we assume you're cracking based on $6$thesalt$hashvalue, so the salt is known. The effect re-using a salt has is mostly, when you collect multiple passwords, all with the same salt: then you compute a rainbow table beforehand.

So .. if you have the table, you can get root, if you can get at the hash and get into a given Antergos system. Or if you can collect shadow entries from a lot of machines, you can crack all the passwords in one go. It is a local issue and most likely not accessible from remote.

So weakness, yes. CVE-worthy? From our end we will create a CVE, since Calamares is similar affected. Other projects dealt the same way.

Better be save than sorry.

[lots0logs]

At least you should communicate it to your community.

Yes, of course. I think its important to identify the actual severity of the issue and explain that to users so that they understand it. We don't want to scare people when its not warranted.

[philmmanjaro]

I recommend to wait for our CVE. Adriaan is still consulting with people with domain expertise -- at FoxIt, or the university of Nijmegen. I'll keep you updated on the matter.

[philmmanjaro]

We have now finished our work. Lacking crypt.mksalt() isn't the way to go. At least use some like: crypt.crypt(new_password, crypt.mksalt(crypt.METHOD_SHA512)). Adriaan had written something himself, that uses std::random_device to generate a salt. Also read CWE-760 and MSA-201706-01. I'll link the CVE also, when online.

[lots0logs]

Alright. Thanks for the update. Btw, crypt.mksalt(crypt.METHOD_SHA512)) is the same thing as crypt.mksalt() because when you call it with no arguments it automatically uses the strongest hash method available on the system (just fyi).

[philmmanjaro]

@lots0logs: here you go for the communication from our end.

[lots0logs]

Ref: https://antergos.com/wiki/alerts/cnchi-installer-weak-password-hashes/