#560 Issue `closed`: Setting SSH_ROOT_PASSWORD exposes the root password¶

Labels: bug, fixed / solved / done

schlomo opened issue at 2015-03-05 21:28:¶

I just realized that if a user uses the SSH_ROOT_PASSWORD feature he actually breaks the security concept of ReaR. The concept is that the rescue media should not contain any secrets that can be used to exploit the server during recovery.

The motivation for this approach is that in real life it is really hard to truly protect the rescue media from beeing copied. If the media does not contain dangerous secrets then it does not need to be protected against copying.

With SSH keys there is no danger as possession of the authorized_keys file does not grant access to the server.

However, when the SSH_ROOT_PASSWORD is set then the rescue media actually contains this password twice: Once encrypted in /etc/shadow and once not encrypted in the ReaR configuration!

Therefore using this option is a very dangerous thing. Especially since normally the ReaR configuration is world readable on the source system so that an attacker in the same network without root access could read the ReaR configuration, somehow trick the admin into recovering the server and then use the recovery time to access the server with the known root password and inject malware at root level into the recovered system. After it comes back the attacker will have root privileges on it.

I don't remember who wanted to have this feature, I only saw that @sanderu added some fixes in #362, #360 and #359.

Let's use this issue to discuss the impact of this feature and how we will deal with it. I can imagine for example that we print a stern warning about the security issue. Or that the user must supply the password already encrypted and not plain text. Or that we introduce a new variable ALLOW_INSECURE_FEATURES that must be set to actually enable this (and maybe other similarly insecure) feature.

Please let me know your opinion.

sanderu commented at 2015-03-06 06:33:¶

@schlomo, I see your point.

However, several questions comes to mind:
If you have an attacker in the same network, isn't it pretty much "game over"?? If they have been able to gain access to a server, then they could also spend time escalating privileges instead of having to trick the admin into recover a server as this much more likely expose the attackers?

The SSH_ROOT_PASSWORD itself is only set if you want to allow an SSH connection to do the recovery - and it should of course NEVER EVER be the same as the OS root password! Goes without saying! But a stern warning to the user could be given to avoid any mishaps here.

Having the ALLOW_INSECURE_FEATURES would be acceptable as this would just be one more variable to set and is the least "intrusive" change.

BTW: is there any reason for having the ReaR config file world readable??

gdha commented at 2015-03-06 06:41:¶

By default the config files are:

$ ls -l /etc/rear/
total 8
-rw-------. 1 root root 534 Dec 26  2013 local.conf
-rw-------. 1 root root  46 Feb 17 20:57 os.conf

@schlomo @sanderu Perhaps it is enough if we describe in the default.conf that setting SSH_ROOT_PASSWORD is insecure. Why another variable - there are more then enough already?

sanderu commented at 2015-03-06 07:48:¶

@gdha Agreed. The most elegant simple solution.

schlomo commented at 2015-03-06 07:51:¶

@sanderu With SELinux and App Armor "hacking" a running OS could be indeed difficult or impossible. The disaster recovery process offers a convenient side channel attack where security is traditionally lower.

What about having the user to supply the password already encrypted? IMHO that would solve all the problems and is actually also practiced with many other tools where you must provide a static password.

andreas-tarp commented at 2015-03-13 14:55:¶

@schlomo In my point of view supplying the password already encrypted would be the perfect solution. It does not add much complexity for a rear user when configuring rear, but improves security.
Maybe a short hint in default.conf file how to encrypt an password in the correct way would help some people in the beginning.

schlomo commented at 2015-03-13 15:24:¶

@gdha what do you think? For 1.17.1?

gdha commented at 2015-04-08 14:47:¶

cleaned up script build/default/50_patch_sshd_config.sh (has not much to do with this issue content, but is worth to mention it)

gdha commented at 2015-05-31 15:40:¶

@schlomo do you want some additional security measurements or are the added fixes enough to satisfy your concerns?

schlomo commented at 2015-05-31 15:47:¶

@gdha great solution, thanks a lot! Safe by default and even backward compatible.

tbsky commented at 2015-07-24 13:23:¶

Hi:
I need to use "SSH_ROOT_PASSWORD" today, and I found the current situation of 1.17.1 is not working under rhel 6.6/7.1. reason below:

the generated md5 password string is begin with '$1$', so the script should use single quote to handle it, or the special character '$' will cause problem. but the script use double quote to handle it.
even I modify the script to handle the string correctly, the result password won't work under rhel 6.6/7.1. I don't know why. it seems rhel need "/etc/pam.d/*" to use md5/sha password. under rhel 6.6/7.1 the standard "crypt" password hash works, but md5/sha password hash failed.
so I think maybe we can add a variable "SSH_ROOT_PASSWORD_HASH" so user can use correct password hash for their own distribution? or other better ways?

gdha commented at 2015-07-24 14:02:¶

@tbsky could you elaborate a bit more in detail what you did to fix it? And what do you think is missing with /etc/pam.d/*?

tbsky commented at 2015-07-24 14:20:¶

hi gdha:
sure. the original script fix is easy. just fix the line at 50_ssh.sh

-        "$1$*") echo "root:$SSH_ROOT_PASSWORD:::::::" > $ROOTFS_DIR/etc/shadow ;;
+        '$1$'* ) echo "root:$SSH_ROOT_PASSWORD:::::::" > $ROOTFS_DIR/etc/shadow ;;

but I am not sure how to deal the rhel situation? should we fix the configuration so rhel can use md5 password hash? or just let it use the crypto hash? I am not sure if we can find a way so every distribution can use md5 hash correctly. so I think maybe let user add their own working hash to rear system.

tbsky commented at 2015-07-24 16:56:¶

hi gdha:
after try & error, I finally found the missing part: "/lib64/libfreeblpriv3.so". both rhel 6.6 and 7.1 md5 password hash will fail if the rear system didn't have that library.

I use ldd to check every file, and nobody need that library. hope someone can explain how the things are working so I can learn about it.

so how do you want to fix the problem? use md5 hash and fix the linux environment or something else..?

gdha commented at 2015-07-24 18:56:¶

@tbsky we can add the lib to the list to copy to the ramdisk

tbsky commented at 2015-07-25 04:25:¶

hi gdha:

I think it's ok to add that library to the list. just curious how is it working. could you also fix the script and document together? the document also has single/double quote problem:

the line at 50_ssh.sh

-        "$1$*") echo "root:$SSH_ROOT_PASSWORD:::::::" > $ROOTFS_DIR/etc/shadow ;;
+        '$1$'* ) echo "root:$SSH_ROOT_PASSWORD:::::::" > $ROOTFS_DIR/etc/shadow ;;

the line at default.conf:

-# and copy paste the output of openssl to variable SSH_ROOT_PASSWORD="..."
+# and copy paste the output of openssl to variable SSH_ROOT_PASSWORD='...'

thanks a lot for your kindly help!!

gdha commented at 2015-07-27 09:00:¶

@tbsky could you verify the fix? Feedback is welcome (as always:)

tbsky commented at 2015-07-27 09:12:¶

hi gdha:
I have not really test it but I think it wil work for me. however rhel6 also has 32bit versions.so add the "/lib64/libfreeblpriv3.so" will not work for it. I don't know if there are better ways to handle library in rear system?

gdha commented at 2015-08-06 13:01:¶

@tbsky thank you - I also added the 32-bit version a minute ago

[Export of Github issue for rear/rear.]

#560 Issue closed: Setting SSH_ROOT_PASSWORD exposes the root password¶