ls /etc | sh making root passwd empty in my linux box.
Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
No, that is not a vulnerability, that is misuse. As I already told you root always have the possibility to change/modify/remove its own password. Just by executing the command passwd. There are a lot of other commands (like that ls /etc | sh) which may or may not change the root password (accidentally/occasionally) and you will not be able to block all of them.
You can make a filesystem read only using the mount command. But root can also remount it and will be able to change password again.
Finally, DO NOT DISCONNECT from the hardened server until you 100% certain you can log back in. From your “IP”, open a new tab in terminal and start a fresh session to the server as verification after editing /etc/ssh/sshd_config on the hardened server.
I just tried this as myself. It tried to change my personal password! What is happening obviously is that the name of the users file /etc/passwd is being misinterpreted by the shell as the passwd command.
Like the OP I find this a bit worrying. It could lead in some circumstances to users being "frozen out" of their own accounts.
Actually, you are [all ...] pretty much mistaken. Let's try a perfectly safe series of commands, to see what's really going on here:
Code:
cd ~
mkdir foo
cd foo
touch me
ls | sh
Here, I first make sure that we're in the home directory. I create a directory called foo, enter it, and create an empty file named me. Then, I pipe the output of the ls command (which defaults to the current directory, and so will produce exactly one line: me ...) into the sh command, just to see what it does.
The output will be:
Code:
sh: 1: me: not found
Now you can clean-up with:
Code:
rm me
cd ..
rmdir foo
... first removing the empty-file, then removing the directory that we just created.
Okay, so what did we learn? Piping lines into sh causes it to attempt to execute each line as a command. (Here, it dutifully attempted to execute a command called me.)
It is fairly-nonsensical to do this using the content of the /etc directory, but you can in fact do it. (You could pipe a copy of Lincoln's Gettysburg Address into sh and it would do its execute each line as a command.)
What it will not do is, as you suggest, "magically remove the password from the root user." There is no security hole here.
Last edited by sundialsvcs; 08-19-2016 at 09:09 AM.
What it will not do is, as you suggest, "magically remove the password from the root user." There is no security hole here.
Do it as root.
Root does not require the initial password to set a new one so piping an ls into sh may change the root password depending on the list of files in the folder. (Although it would likely require two files with the same name)
I don't have a VM handy to risk it at the moment but may try tonight
If you want to "fsck things up real quick" as root, why not try this, instead:
Code:
cd /
rm -rf *
Quote:
I'm joking, of course! I'm joking! Don't actually do this!!
After all, "it's your foot!" Shoot it off if you want to, but don't come a'hobblin' to me ...
root doesn't have to "pipe commands into a shell" to remove the password from anyone he pleases, in a typical system configuration where a central authorization-authority is not being used. He can "just do it."
- - - - - Footnote: In partial recognition of this, some recent Linux releases (and Apple's latest OS/X ...) now limit the powers of the "once all-powerful root user." There are now some things that you will find that even root can't do ... some files that even root can't touch. The implementation is similar in some ways to UEFI: to impose limits that can't be overridden while the system is running.
Last edited by sundialsvcs; 08-19-2016 at 09:54 AM.
If you want to "fsck things up real quick" as root, why not try this, instead:
Code:
cd /
rm -rf *
After all, "it's your foot!" Shoot it off if you want to, but don't come a'hobblin' to me ...
I'm well aware that as root you can break things easily, however the point of the OP is that he is allowing users to access a CLI as root, hence the original post.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.