-
Notifications
You must be signed in to change notification settings - Fork 246
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Setting SSH_ROOT_PASSWORD exposes the root password #560
Comments
@schlomo, I see your point. However, several questions comes to mind: 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?? |
By default the config files are:
@schlomo @sanderu Perhaps it is enough if we describe in the |
@gdha Agreed. The most elegant simple solution. |
@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. |
@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. |
@gdha what do you think? For 1.17.1? |
cleaned up script |
…assword. * explained in default.conf how we want it now * rescue/default/50_ssh.sh copies the hashed pw to the rescue /etc/shadow file, * and we still keep the old method too for backward compatability reasons with older releases of rear See issue #560
@schlomo do you want some additional security measurements or are the added fixes enough to satisfy your concerns? |
@gdha great solution, thanks a lot! Safe by default and even backward compatible. |
Hi:
|
@tbsky could you elaborate a bit more in detail what you did to fix it? And what do you think is missing with |
hi gdha:
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. |
hi gdha: 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..? |
@tbsky we can add the lib to the list to copy to the ramdisk |
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
the line at default.conf:
thanks a lot for your kindly help!! |
@tbsky could you verify the fix? Feedback is welcome (as always:) |
hi gdha: |
@tbsky thank you - I also added the 32-bit version a minute ago |
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.
The text was updated successfully, but these errors were encountered: