Red faces at SymantecSymantec Security Response Researcher Ron Bowes has written an article which claims that a unix based system that uses sudo can be compromised by manipulating the search path.
When you cut all the waffle about spelling mistakes, “.” in the path and scripts executed in error, what he is saying comes down to (using bourne shell) …
$ echo "echo 'exploited!'; whoami" > /tmp/mount
$ chmod +x /tmp/mount
$ PATH=/tmp:$PATH
$ export PATH
$ sudo mount /dev/cdrom
Password:
exploited!
root
$
However the writers of sudo(8) were not as dumb as all that. If it was that easy it would have been blown years ago and, in fact, would not have been worth creating at all. I don’t know if he actually tested the code that he wrote but if he did, and it worked, then he had a seriously broken sudo implementation.
The “main” protection offered by sudo, to pick up on a point made by Mr. Bowes, is that it checks that the path to the command about to be executed matches the one permitted by the sudoers(4) table. /tmp/mount does not match /sbin/mount so it will not be granted root authority—indeed it will not be executed at all by sudo, the real one will be.
Webmaster
Planète Béranger has picked up on this and seems to think that it is related to the sudo build option
--with-secure-pathwhich is described asI am not sure that this is even necessary (but I haven’t tested it). The issue here is not really hackers spoofing your users but malicious users themselves. If you could get around the sudo controls by merely changing your path then it would be pointless. The key is the sudoers file requiring fully qualified commands.
I respectfully don’t agree.
Where can you see that sudo requires a fully qualified path?!
As long as it used a secure PATH (–with-secure-path), this allows you only file names, but they will be searched for in safe places.
Perhaps I wasn’t clear. From the sudoers(4) man page
It is not that you have to type the command in fully qualified (that is clearly not true) but what sudo does is to locate the command using what ever path is specified and then compares that discovered FQN with the one in the sudoers table.
For example, if you have a command
fsckin/usr/binas well as/usr/sbinand your path (whether secure or not) has them in that order then the/usr/binone will be found first. If your sudoers file only says allow/usr/sbin/fsckthen it won’t match and the command will fail.Part of the problem is that Mr. Bowes has muddied the subject with a lot of irrelevant detail.
I don’t think paths have anything to do with it at all; sudo is about giving access to a list of specific commands. Whether they are typed in full or found via a path search (whatever path) is not relevant, only those particular commands and no others will be granted access. You don’t need to worry about the path used to find the command; when it is found, if it is not in the sudoers list then it will NOT be run.
The whole sudo concept relies on this.
“Part of the problem is that Mr. Bowes has muddied the subject with a lot of irrelevant detail.”
Oh come on, I have to make my word count somehow!
But seriously, thanks for your comments, it’s good to know that people are listening.
Yes, I did test the code. It’s tested on a nearly-default installation of Slackware 10.2.
I have never actually seen a setup where people specified the paths to the programs for sudo, except for a very locked down systems. For home users, it’s generally too much trouble (especially for doing “sudo make install”). However, that is probably good general advice.
I tried to expand a little on my points in my response on the Planète Béranger blog. Hopefully, reading my response there (assuming it gets approved) will clear the water more about what I was trying to say.
Hi Ron, thanks for the comment and I accept what you say. I was just a bit bothered because the headline and the gist of the first part of the article, which was emphasising spelling errors spoofing naive users and the dangers of insecure paths (which I accept), did not have a lot to do with the second half which is what would be a fundamental flaw in sudo if it were true. If sudo was in that state, never mind people hacking in, you would need to look to your ordinary users and what you are allowing them to do.
I just can’t see why home users would even bother to install sudo or use it – it would be much easier to use su to root (my experience is with Solaris not Linux so perhaps that doesn’t apply). If you were going to install it (with or without the secure path switch) I would have thought you would try to get the main control file sensible. Perhaps that is me being naive!! If sudo comes installed by default then it should have a decent control file pre-built.
I would be interested to know what your sudoers file actually had in it – it must have been /*/* or similar to allow a command from /tmp to be authorised.