| |||||||||||||
|
| |||||||||||||
How to write a Linux virus in 5 easy stepsHow to write a Linux virus in 5 easy stepsPosted Feb 11, 2009 22:09 UTC (Wed) by jmorris42 (subscriber, #2203)In reply to: How to write a Linux virus in 5 easy steps by mikov Parent article: How to write a Linux virus in 5 easy steps
> Does anybody know whether anything is being done to address
> this specific vulnerability?
I doubt a solution will ever get deployed until it gets exploited in the wild. The solution however is fairly obvious. Pass an environment variable declaring the path of the .desktop file and have important things like gksu check that it didn't get invoked from an unexpected/insecure location.
(Log in to post comments)
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 3:33 UTC (Thu) by k8to (subscriber, #15413) [Link]
I'm unclear how this fixes anything.
What is the attack vector?
If menus are able to be modified, this sounds like writes can be made to the filesystem, in which case the environment variable can be erased.
my.desktop:
my_script.sh:
Maybe I don't understand what your proposal is guarding against.
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 8:27 UTC (Thu) by jmorris42 (subscriber, #2203) [Link]
> If menus are able to be modified, this sounds like writes can be made
> to the filesystem, in which case the environment variable can be erased.
I was thinking about the problem in the article where you can replace the menu entry for an elevated privledge tool like packagekit with an entry in the users home directory and as long as the name and group are identical it will silently replace the systemwide entry in the menus.
But yea, an environment variable isn't going to be secure. Doh. Should have pondered that one a few more minutes. So what would be? If gksu can learn (reliably) how it got invoked the exploit goes away.
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 10:18 UTC (Thu) by efexis (guest, #26355) [Link]
No, you were on the right track; *su apps shouldn't be paying attention (as least where security decisions are concerned) to their launch environment, but should load their own (esp PATH, LD_PRELOAD etc) from a secured location outside of the users HOME (/etc etc) before launching anything. Still, if you can run stuff in system locations (/usr/{,s}bin etc) and pass command line parameters, you could still run eg, bash, and pass it your malicious script to run on the command line (now as root). You could have it so that .desktop files that launch *su have to have the suid root bits set for *su to obey their command... and I guess the *su program actually reporting the command that's going to be run right there with where it's asking the user to confirm the action would help out (if this is not the case already? I only ever use the system account (I am my own protection, I need not the computer to do that for me, but I guess that's not the norm) so I can't really comment on what is/isn't done so far)
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 18:49 UTC (Thu) by mikov (subscriber, #33179) [Link]
I think what you guys are forgetting is that the virus doesn't even need to run gksu/kdesu. It can display a window of its own that looks like the one from gksu and ask you for your password. Simple and effective! :-)
How to write a Linux virus in 5 easy steps Posted Feb 12, 2009 19:26 UTC (Thu) by efexis (guest, #26355) [Link]
Which is why I have a process running, inspired by phish filters and early viruses, that detects whenever I enter the key sequence that is my root password, and kills the process that's recieving those keys before I have chance to hit enter...
...I can't disable it...
I really didn't think that one through.
What I should've done was make the su app give *me* a system identifying password, which I then respond with the second half. Imitation *su apps wouldn't be able to read the challenge string, so I would never be fooled by something that merely asked me for a password.
|
|
||||||||||||