Fedora has user writable directories by default in the PATH variable, this can be abused to shadow a legitimate binary like sudo and easily obtain the user password.
The exploit needs that the attacker have write access to the user home, which is already bad if it has gone this far (since the attacker could modify .bashrc). I wonder why Fedora has this kind of insecure default while Debian and Ubuntu doesn’t seem to have it.
$HOME/bin and $HOME/.local/bin don’t exist by default, so attackers have to create them first. If they can create these directories in the user’s home directory, they can perform the attacks mentioned in your post, regardless of Fedora’s default PATH variable.
It appears that some user installed python files using pip end up in $HOME/.local/bin, so I see why these exist in the PATH. Isn’t it better to at least have the user directories at the end of the PATH to avoid shadowing?
The shadowing is a feature not a bug.
I often shadow a command for all sorts of reasons.
The security issue is installing from sources that are not trusted, not the PATH.
If you change the default PATH then users will simply adding the user bin dirs themselves. It been that way in my .bash_profile forever, as an example.
Another feature that provides security should the suggested happen is both SELinux and the ability to write to protected areas of the file system.
The installed sudo command is setuid and operates as root. It also has specific selinux attributes as do all the files in the system area of the machine. For an attacker to: 1. create the directory, 2. write the command file there, 3. change ownership of the file, 4. set the proper selinux content, 5. set the setuid bit, 6. then execute it with the proper permissions ; all seems a very complex and difficult to achieve chain of events.
In in any case, the first line of defense is, and always has been, a responsible user with reasonable security habits that avoids actions which would allow malware on the system. Proper browsing habits and avoiding downloading suspicious files is the first line of defense. System security with selinux enabled and proper operating habits with installed software is the next line of defense, as is the firewall which is enabled by default and restrictive to external attack paths.
As was noted above, being able to shadow system commands with user commands is a feature that has been in place since the very beginning.
If the noted attack vector were a major security breach the millions of users of linux would already be screaming for it to be fixed – and they are not. @td211 , this seems an unwarranted concern since system security has always had the user as the first line of defense, and the $PATH has been the same (or very nearly so) for many many years.
This is why I asked here. I know Fedora takes security seriously (and so does most other distros) so I wanted to know how bad is having this on someone’s system.
Some of these are unnecessary. I created a simple bash script that echoes something, called it sudo, set it as executable and put it in my ‘$HOME/.local/bin’. Launched an interactive shell and the realsudo was not executed.
That is the shadowing of system commands that has been noted as a feature. For it to do any harm it would need to have the proper permissions and access to the system.
Admittedly it could launch a key logger or other malware, but the user would certainly know if ANY command did not perform as expected and should then investigate. Once again, that falls back to the firs line of defense – the user needs to be alert and understand what is expected with any command they use as well as avoiding the download of malware.
Any malware that may be downloaded would only have the users permissions and access by default.
Many suggest that a user should have at least 2 accounts on their home system. One would have sudo access and only be used when performing admin tasks. The second would be the username used for daily use and would not have sudo access. By following this process any malware that may inadvertently be downloaded would still not have a means of gaining root access.
I believe at least Ubuntu has it, but in .profile ~/bin and ~/.local/bin are only added to the path if they exist.
At this point the system is already heavily compromised considering that point 3. and 5. requires super-user privileges, and probably point 4. as well. Also, the rouge program must be a compiled binary for the setuid bit to have any effect.
Thus indicating that the concern about shadowing of commands is mostly just indication of not understanding system functionality and security as well as an excess of paranoia.
That is a good idea.
I’m getting started in cybersecurity and wanted to know more about this subject, since this is considered a privilege escalation vector.
Thanks for the answers everyone.
System scripts will either set the PATH explicitly to exclude user directories or use the full path to commands. Like /usr/bin/sudo not sudo.
On servers its rare to have end users having access at all to the shell.
Agreed, The end users mostly only have access through the apps and only admins have shell access. Added to that is very few servers ever run a gui desktop and admin is done from the command line.