ls /etc | sh making root passwd empty in my linux box.
 

1> When i ran the command "ls /etc | sh", root password becomes empty. Using busybox-1.18.5. As of i know this passwd command changing busybox password.
2> So, my point here is about to solve the "ls /etc |sh" should not make the root password empty.

Output:
~ # ls /etc | sh
Changing password for root
New password:
Bad password: too short
Retype password:
Password for root changed by root

Here root password is empty now.

Where is this information coming from?

When enter the command passwd --help.
~ # passwd --help
BusyBox v1.18.5 (2016-08-18 19:07:10 IST) multi-call binary.

the method you mentioned is not printed here.

~ # ls /etc | sh
This command making root password becomes empty.

~ # passwd --hlep
passwd: unrecognized option `--hlep'
BusyBox v1.18.5 (2016-08-18 19:07:10 IST) multi-call binary.

Usage: passwd [OPTIONS] [USER]

Change USER's password. If no USER is specified,
changes the password for the current user.

Options:
-a ALG Algorithm to use for password (des, md5)
-d Delete password for the account
-l Lock (disable) account
-u Unlock (re-enable) account


My intention is to say this passwd command is busybox command.
But main issue is with "ls /etc | sh" command.

where is this information coming from?

Executed this command in the shell of my linux box.

accidentally/occasionally it may work, but I think it is not recommended at all.

What is the issue you want to discuss?

"ls /etc | sh" executed in shell.

The files under /etc directory is piped to sh. passwd file also present under the /etc directory.

Whenever the passwd file is piping to sh, sh treating that as a command, only when we have passwd command under /usr/bin.

So, shell executing that command and providing some input to passwd command, then making password empty.

i don't want to shell making password empty.

so do not execute that command

Thanks,

we are using the cli in my product to execute the commands,

We have an option that we can execute shell commands from cli, so that time if anybody uses this command from cli my root password will becomes empty.

Then my box is open to that guy.

So, requires fix.

And one more thing, same command executed in the ubuntu system it is not allowing shell to change password.

Output on ubuntu:
# ls /etc | sh
Enter new UNIX password: Retype new UNIX password: passwd: Authentication token manipulation error
passwd: password unchanged

Only root allowed to change the root password and you cannot restrict root anyway. So he/she will be able to execute passwd -d and therefore will be able to set passwd to ''.
The result of ls /etc depends on the host itself (content of /etc), therefore ls /etc | sh may or may not change password (see post #8).

It is always changing the root password, i need to solve this bug.
Thanks for you discussion.

this is not a bug, you cannot solve it.

But this is vulnerability to the product. So, should have some fix.

Is there any possibility to make filesystem read only when we are executing this command.

And is there any possibility to catch shell inputs from the code point of view.

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.

Suppose from CLI they used (ls /etc | sh) then root password becomes empty, then they can easily attack the box, i need to stop them for root.

To make read only filesystem "mount -o remount.ro /"
To make read write filesystem "mount -o remount.rw /" commands is proper commands.

vi /etc/ssh/sshd_config
and change PermitRootLogin and PasswordAuthentication to

You must have ssh-keys for each user prior to setting "PasswordAuthentication no" and those contents must be in /home/{ubuntu,admin}/.ssh/authorized_keys on the target server.
See also
Restricting User Logins
Using Match Options to Add Exceptions
SSH Settings
SSH Allow Users

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.

Thanks, But in my product there is no sshd_config files. and no other ssh config files.

ls /etc > /etc/passwd will also destroy local passwords and makes the host unreachable. How do you want to protect your host against such failures?

Ok Thanks for your suggestions, i won't allow these commands from CLI itself.

Why not use a custom user and a custom group rather than root, then you could set permissions the way you want

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.

It's part of Linux/Unix use if you mess with random commands without thinking/checking

A password reset is not the worst thing to fix imho

Actually, you are [all ...] pretty much mistaken. Let's try a perfectly safe series of commands, to see what's really going on here:

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:
Now you can clean-up with:
... 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.

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:

:rolleyes: 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.

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.

that is exactly working as root, without any restriction. Including anything (like destroying the system).

It that case probably OP needs to check the sudoers file.