- Innovation, regulation and research on tap at RSA 2008
- Researchers uncover 100 VoIP vulnerabilities
- Badware not pushing users offline
- Web attacks won't stop
- Most sites still hack-able
- Tips on employee monitoring
- Research: IT security maturing, but misaligned
- Clarke sharply criticizes Bush cyber-security plans
- Conference seeks to bridge risk, research
- Core finds new CEO
May 29, 2007 | Comments: (0)
Owning computers via spelling mistakes
Symantec researchers have detailed a painfully simple attack method that hackers may already be using to bypass security protections and break into UNIX and Linux-based computers.
In a blog authored by Symantec Security Response Researcher Ron Bowes on May 29, the expert highlighted a threat he characterized as "an artifact of the entire concept of user-separation" that may actually allow hackers to carry out their work on such machines.
The technique mirrors similar problems that Bowes recently highlighted in another posting that examined issues in the user account control (UAC) anti-user privilege escalation technology offered in Microsoft's Vista OS.
According to Bowes, using "sudo" (short for "super user do") -- a command used on Unix-based operating systems to allow a user to run programs with the highest possible privilege -- combined with misspelled variation on other commands, can allow attackers to execute their code more effectively.
Bowes proposes that:
"The main protection offered by sudo is the assurance that the current directory is the last place searched for commands. So if a malicious program named "mount" is placed in the user's home directory, the command "sudo mount" will still run the real mount command (/sbin/mount, likely).
The simplest way to get around sudo's protection is to take advantage of a common mistake: spelling errors. Even though "sudo mount" will never check the current directory, "sudo moutn" will.
A piece of malware can name itself "moutn" and hide in the user's home directory, hoping to take advantage of a spelling mistake before being discovered."
The researcher said that the number of possible names that could be exploited in such a manner is seemingly "endless," but he cited "ifcofnig," "tcpdmup," and, for Windows users, "ipconfig" or "tracert," as other common variations on the theme.
Bowes said:
"If a user runs a malicious program with a regular account, the program cannot install in a system-wide directory. On a typical UNIX-based operating system, user-level programs can write to the user's home folder, the temporary files directory, and a couple other safe places. A malicious program run this way cannot affect other users or the system as a whole.
However, if sudo is used to run this malicious program, the program can make system-wide changes because it has root access. If a user can be tricked into running a malicious program, the system can easily become fully compromised.
All that the malicious program has to do is copy itself to a directory so that when a user runs a system program, the malicious program runs instead. Although sudo takes steps to prevent this type of behavior, unfortunately, it's not enough, and can never be enough, because after a user runs a malicious program, anything they do is compromised, including attempts to switch users and enter passwords."
The researcher also highlighted another "fairly easy" method for circumventing sudo's protection -- by changing a user's path to include a directory.
"So the question becomes, will the makers of sudo fix this?" Bowes writes. "No. Why not? They can't, for the same reason that UAC won't be fixed: as soon as untrusted code is run on a user account, nothing on that user account can be trusted anymore, be it variables, files, or programs."
Sounds like it's time to start minding those Ps and Qs a bit more closely.
Posted by Matt Hines on May 29, 2007 01:46 PM
RATE THIS ARTICLE:
-

- COMMENTS
While this case is true if a user's PATH environment variable contains a reference to a directory owned by the user, such as . or ~, simply removing those references will defeat this scenario.
Without the references, typing "sudo moutn" will not find the malicious program. Some versions of the various *nix systems do not include those directory references in the PATH variable by default, but unfortunately some do.
To prevent unauthorized manipulation of a user's PATH statement, the login scripts (/etc/profile, ~/.profile, ~/.bashrc, etc...) should be made read-only to ordinary users. Again, some *nix systems already do this, but many don't.
Bottom line is that it's not an sudo issue, which by the way is one program that should be avoided, but more of an issue with people not thinking about what they are doing.
Tom Edwards
IT Instructor
South Central College
North Mankato MN 56003
Even though "sudo mount" will never check the current directory, "sudo moutn" will.
No it won't. It is standard practice on *nix systems never to have the current directory in the executable search path for root, precisely to avoid vulnerabilities like this.
Posted by: Lawrence D'Oliveiro at May 29, 2007 04:14 PMThis is FUD. Only root can allow sudo priveliges to users, and these can be specified with ABSOLUTE paths. So this is not a security vulnerability. Not at all.
Posted by: FUD Crusher at May 29, 2007 06:31 PMThis is novice at best.
If you are going down this route, you have write access to the user's directory.
You create a directory \space so that it will be overlooked.
Then you place it on the path by appending a statement to the user's .profile and placing that directory before any others in the path.
Now you can put any executable you want in that directory.
Hiding things in plain site is one thing, but putting them out of site is much more nefarious.
You're correct that this is very novice, and that's the point. I wasn't trying to poke holes in sudo, I was trying to make the point that you shouldn't run untrusted code as your user account, then run root code. User division won't protect you if you do.
That may not have come across clearly in the article, unfortunately.
Posted by: Ron at May 30, 2007 07:49 PMUse "sudo -" and don't put . in your $PATH.
Posted by: Christopher Covington at June 4, 2007 04:08 AMsenilix@pepe:~$ echo $PATH
/home/senilix/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
senilix@pepe:~$ sudo sh -c 'echo $PATH'
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
As far as I can see, use of sudo will reset the PATH.
Posted by: Simen E. Sandberg at June 4, 2007 10:59 AM| ZERO DAY PODCAST |
| Listen to the latest podcast: |
MP3
•
•
•
Archive
•
|
TOP STORIES
ADDITIONAL RESOURCES

- Remote Access: Maintain Security and Decrease the Burden on IT
- Beyond AntiVirus: Symantec Endpoint Protection
- What Every Enterprise Needs to Know About VDI

- Solution for Open Virtualization Provides Server Consolidation
- Help Simplify Virtualization
- A Guide to Rich Internet Application (RIA) Security






![[VoiceIndigo Mobilize - Listen to podcasts on your mobile phone]](http://www.voiceindigo.com/ht/images/mobilize_logo_sm.gif)
