What is the worst a browser exploit could do in Ubuntu?

[aligator12]

Out of curiosity, let's say I visited a site that was designed to exploit Chrome. What is the worst it could do? Install a keylogger for example?

Or would it basically be browser only?

[HermanAB]

Theoretically, it can do anything that the logged in user can do.

In practise, I haven't ever seen a successful browser exploit on Linux.

However, I have had to clean a number of mismanaged Linux servers that were infested with spam sending engines. In all cases it was due to some asshats who thought that a four character root password was really super cool...

[OpSecShellshock]

The worst thing an exploit can do is cause the execution of commands you didn't intend to execute. But I wouldn't think it would lead to installation of a keylogger, because at that point the exploit developer could do basically anything, so there'd be no need for one.

But as people are fond of saying, that usually doesn't happen. The economics of exploit development for criminal activity are such that it makes the most sense to go from exploit to malware installation, which is going to target Windows systems for the most part. It's not that it can't be done on Linux desktops, just that there's not much economic advantage or incentive in it.

Most of the time the worst result will be that the application crashes.

[Hungry Man]

Chrome's a poor example, you can do very little with a compromised Chrome due to its sandbox. An attacker who exploits Chrome is very limited.

If we talk about Firefox then it can do anything that the logged in user can do. It can keylog, write files to anywhere that your Firefox process can write them, read any files it can read, etc. Your attacker essentially "controls" Firefox's processes and it inherits those abilities.

[KaosuX]

This scenario is hard to answer since it relies on so many different variables to give an answer in-depth. However, let us assume this is a default installation of Ubuntu being exploited.

Scenario: You're surfing the Internet with your favorite browser and you stumble upon a malicious website that is compromising browsers with a shiny new zero-day.

Cause: Assume the exploit has set the payload to download, compile and execute a bindshell. Now the bindshell is running with whatever account privileges the browser had when exploited. The attacker can now connect to you and further compromise your machine by escalating his/her privileges using whatever exploits he/she has access to.

Prevention: Using secure App Armor profiles (not the default ones) to mitigate the damage compromised software can do would have likely prevented this from happening.

If you get creative, there is so much someone could do given your criteria. However, my given scenario would be the most common and most dangerous of them.

Even if IPTables were set up to disallow all incoming connections except for related/established ones, you would still be vulnerable, because it would be trivial to modify the aforementioned program to connect to the attacker instead of waiting for a remote connection (a reverse shell). Therefore, you are literally establishing the connection to the attacker, and once he/she has completely compromised the machine by escalating his/her privileges, there is no limit to what they could do.

[mike acker]

{snip}
Prevention: Using secure App Armor profiles (not the default ones) to mitigate the damage compromised software can do would have likely prevented this from happening.
{snip /}


Have you had a chance to review the Firefox profile provided by Jamie Strandboge of Canonical ?

it came with my system in a disabled condition; I enabled it and tested it in complain mode; I have it running in fail mode now.

[KaosuX]

Have you had a chance to review the Firefox profile provided by Jamie Strandboge of Canonical ?

it came with my system in a disabled condition; I enabled it and tested it in complain mode; I have it running in fail mode now.

I have not reviewed this profile. I have actually taken the time to carefully create my own profiles for all of the software that I use. However, I will do a quick Google search and take a look at the suggested profile. If I find anything that can be improved, I will happily send the changes to its maintainer.

[rookcifer]

Basically an attacker would have the same access to the machine that the user does. He wouldn't have root unless he has a separate exploit that allows him to escalate (i.e. a flaw in the OS). This means, in order to get root, he would need a browser exploit and an OS exploit.

But even without root, he can initiate connections to servers and make your machine a spam bot, etc.

As was mentioned, the probability of this happening is low, especially with Google Chrome. It uses 2 separate sandboxes. While it's probably not "impossible" to break out of them (a la pinky pie), it would be exceedingly difficult. You can give Firefox close to the same level of security with a strict AA profile.

[samiux]

Basically an attacker would have the same access to the machine that the user does. He wouldn't have root unless he has a separate exploit that allows him to escalate (i.e. a flaw in the OS). This means, in order to get root, he would need a browser exploit and an OS exploit.

But even without root, he can initiate connections to servers and make your machine a spam bot, etc.

As was mentioned, the probability of this happening is low, especially with Google Chrome. It uses 2 separate sandboxes. While it's probably not "impossible" to break out of them (a la pinky pie), it would be exceedingly difficult. You can give Firefox close to the same level of security with a strict AA profile.

It is not necessary to do privilege escalation via the vulnerability of Kernel of Linux. There are many ways to do privilege escalation. The easiler way is via the sudoer.

It is not necessary that there is any vulnerability on the browser itself. The vulnerability may be coming from the website, such as XSS.

Samiux

[movieman]

The worst thing an exploit can do is cause the execution of commands you didn't intend to execute.

The worst thing a browser exploit can do is install an addon which captures all your banking passwords and sends it to some guy in Russia who steals all your money and uses it to retire to Hawaii. That solely needs access to your account as your user ID.

I'm far more concerned about that scenario than someone using a second exploit to install a rootkit so they can use my Ubuntu box as a spam server. That's why I only log into my bank from a separate Linux box which isn't used for anything other than work and banking.

[Stonecold1995]

If we talk about Firefox then it can do anything that the logged in user can do. It can keylog, write files to anywhere that your Firefox process can write them, read any files it can read, etc. Your attacker essentially "controls" Firefox's processes and it inherits those abilities.
Actually, that's not completely true. AFAIK, a keylogger must be run as root to work globally. A compromised Firefox could log keys you input to Firefox, but no where else.


The worst thing a browser exploit can do is install an addon which captures all your banking passwords and sends it to some guy in Russia who steals all your money and uses it to retire to Hawaii. That solely needs access to your account as your user ID.
This is what I'd be worried about because it's independent of operating system. Malicious addons and extensions can do a lot of harm, even if they don't use any fancy 0-days or backdoors.

To answer OP's question, the worst would be to compromise the browser, use a 0-day to get out of any sandboxes (if the browser uses one), use a 0-day to gain root privileges, install a rootkit, and then do whatever it wants. More realistically though, you have to look at what a potential hacker would actually want to do. And most in this case want to make money. Most hackers infect computers by using "exploit packs", which are programs that a very advanced hacker makes and updates, and sells to other hackers, who can use it to put various exploits on either their own website(s) or hacked website(s). They can cost thousands of dollars, but they update themselves to include new 0-days as old ones are patched, and often include several different types of exploits to raise the chance success (such as a Java exploit, a Flash exploit, an ActiveX exploit, etc). Anyone who visits a website with an exploit pack has a chance of getting compromised. To understand the risk, very cheap exploit packs have infection success rate in the single digits, whereas the most expensive (that cost tens of thousands of dollars or more) ones have success rates only around 20-30%, and that's with Windows/Macintosh. So if you do visit a compromised site, not only is it unlikely it'll have an up-to-date exploit for your browser version, but you're also using Linux so even if Chrome/Firefox could be compromised its unlikely do be able to do anything because the exploit was designed for Windows/Mac.

Even if your computer was compromised and made part of, say, a botnet, even then there's no guarantee the effect will be horrible. Most botnets in fact are not designed to steal things like credit card or account info, but rather other activities such as Bitcoin mining (uses more electricity and may stress the computer but otherwise harmless), DDoSing (other than taking up internet bandwidth it's harmless to the bot), becoming a SOCKS proxy (may cause you to get caught for things you didn't do), hiding illegal data such as child pornography on your computer (this is probably the worst because "A virus did it" won't fly with the feds, but it is also the least likely scenario), etc.

A well funded government or private organization could probably pull this off if they target specifically you, but a hacker who's only in it for the money is going to stick with Windows/Mac (and more and more recently smart-phone OSes like iOS and Android). It is far, far, far more likely someone is going to steal your computer or your wallet than use a browser exploit targeted to Linux to steal credit card information, etc from your computer.

If you want to stay safe from browser exploits, I suggest you use either Firefox with NoScript (Firefox is the least secure but only it has NoScript which is a huge plus), or Chromium with all scripting disabled (Chromium has the best built-in security, but its extensions API makes it hard to port NoScript to it, and ScriptNo and NotScript all suck), and a secure AppArmor profile for either. Also exercise common sense. If you download everything you see and go to obscure Russian warez and porn sites, don't expect to stay safe with only technical barriers in place. If you are wise in your browsing habits, and also use secure applications, etc you'll be very secure.

[Hungry Man]

It doesn't need root. Any process with X access can log keys.

[Stonecold1995]

It doesn't need root. Any process with X access can log keys.
I thought a non-root applications could only log keys when the application is in focus. Why do packages such as "logkeys" require root then?

[Hungry Man]

http://www.youtube.com/watch?v=Y1fZAZTwyPQ

Ubuntu doesn't isolate any applications from each other in terms of X access - they can all send and receive keystrokes between each other without root.

[Stonecold1995]

http://www.youtube.com/watch?v=Y1fZAZTwyPQ

Ubuntu doesn't isolate any applications from each other in terms of X access - they can all send and receive keystrokes between each other without root.
That's creepy. Doesn't that completely defeat the purpose of having sudo/su because any non-root app could could record root/sudo password? And is there any way to prevent this?

[Hungry Man]

It defeats the purpose of quite a lot, yes. I wrote about it here:
https://insanitybit.wordpress.com/2012/09/24/x-keylogging-and-linux-security-model/

SELinux lets you use a -X sandbox that is kinda cumbersome but will prevent keylogging apparently. I haven't tried this and I'm not sure about the details.

Otherwise, no, there's no way to prevent this. Any program with X access can send and receive input to all other applications running under that X session.

[Stonecold1995]

Is there any way to tell what processes are using X?

[samiux]

Interesting video and blog indeed.

I would like to discuss that when the attacker gained access to your box (even in a lower privilege account), he can very easy to escalate to higher privilege, such as root by many methods. The most easy way is by sudoers.

Moreover, if the attacker already gained access your box, he may or may not use keylogger to record your keystokes as it is very hard to dig out the valuable data from the huge log of the keylogger.

If he want to steal your password of any website (such as bank or PayPal), he can also very easy to do it with cookie/session stealing.

In addition, attack your box via browser can be doing with a lot of methods. Attacker do not require to figure out the vulnerability of your browser. He may using XSS or cookie/session stealing and etc.

Finally, social engineering is another way to attack your box. There may be some other areas/situations that I have not mentioned here.

By the way, I will not mention the method of attacks here in details.

Samiux

[Hungry Man]

@Stonecold,

There's probably a way but I don't know of it. Naturally any application that uses graphics/ has some graphic interface will be given access. I would assume (hope) that services running under separate user IDs have had access removed, but I'm not sure.

[Stonecold1995]

@Stonecold,

There's probably a way but I don't know of it. Naturally any application that uses graphics/ has some graphic interface will be given access. I would assume (hope) that services running under separate user IDs have had access removed, but I'm not sure.
So if I were to use a different tty to enter sensitive passwords (such as one for a TrueCrypt volume), would that prevent X access? Because if pressing Control+Alt+F[1-6] and switching to a session without X blocks a keylogger in tty7 then wouldn't that be the best way to go about entering passwords?

Is there a way to allow only a single process X access at a time? Or maybe two processes at a time (one for the key binds and the other for the application in focus).

[Hungry Man]

Not really sure, honestly. You can test that easily though.

Just type in a terminal:

xinput list

Now find the ID for your keyboard (11 for me).

xinput test 11

And then type wherever you think is "safe" and see if it appears in the terminal.

[OpSecShellshock]

Yeah it might be beneficial to set up a test machine, intentionally install a software keylogger, try a few things and see what you get from it. Like see what happens if you run a discrete X session for each graphical application vs. doing it all in one.

[Stonecold1995]

Yeah it might be beneficial to set up a test machine, intentionally install a software keylogger, try a few things and see what you get from it. Like see what happens if you run a discrete X session for each graphical application vs. doing it all in one.
The only way I found to prevent this is to use a different tty, or to use something like Xephyr (Xephyr won't know what's going on with the "host", but the "host" knows what's being typed into Xephyr).

Is an update to the X server that prevents this going to come out any time soon or is it too low priority?

[Hungry Man]

It is less than a low priority. There is very little chance this issue will be solved soon if ever.

Ideally we'll see something new with Wayland.

[OpSecShellshock]

I wouldn't expect it to ever be addressed. There are just so many development/use cases where calling one graphical application from another is considered desirable behavior. I'm not sure you could address the (relatively minor) risk of cross-application input interception without compromising that functionality. It makes more sense at the moment to fix the arbitrary code execution bugs and library loading (or default path or whatever) bugs in the applications themselves.

Keep in mind we're talking about something that is really, really unlikely. You might come across it in a competitive blue/red team exercise, but it would be a waste of time for criminals.

[Hungry Man]

You can say that about literally any vulnerability in desktop Linux - criminals just don't care.

But no, it wouldn't break everything to fix this. Windows doesn't suffer from this - they have a form of UI separation.

If UIDs were given their own X sessions (or treated as if they were in separate X sessions) and/ or interactions were capability based it would solve most of the issues here.

Separating X sessions by UID would solve GKsudo being keylogged right off the bat. It would also stop non-root applications from keylogging root applications.

Windows also took it another step with their MAC Integrity where lower integrity levels are isolated from higher integrity levels - this is where I think capabilities would model after in terms of X isolation. You also can't set global hotkeys on Windows without root AFAIK.

It'll just never happen because this is a desktop problem, not a server problem.

[OpSecShellshock]

To be clear, the reason I said it's a waste of criminals' time isn't because they don't care, but because there are much easier ways for them to get what they want.

A better mandatory access control solution would still be fantastic though. I just can't see anyone putting the work into it unless real-world risks to home users become far more significant or until Linux desktops get any kind of widespread enterprise use (which isn't going to happen).

[Hungry Man]

To be clear, the reason I said it's a waste of criminals' time isn't because they don't care, but because there are much easier ways for them to get what they want.

Like what?

I know there are other ways to keylog within a UID but I don't know of any other way to keylog from one process to another process when they live in separate UID.

For example - I know of no way to keylog GKsudo without X keylogging.

[Hungry Man]

To be clear, the reason I said it's a waste of criminals' time isn't because they don't care, but because there are much easier ways for them to get what they want.

Like what?

I know there are other ways to keylog within a UID but I don't know of any other way to keylog from one process to another process when they live in separate UID.

For example - I know of no way to keylog GKsudo without X keylogging.

[OpSecShellshock]

You don't really need to intercept keystrokes at all. Best strategy is getting a dump of accounts on the server side. A substantial number of those users will re-use IDs and passwords across multiple services. Not a bad haul.

There's also phishing and tricking people into installing trojans or running bad scripts. For data other than passwords, the browser and its scripts and objects have access to the entire home directory, where people store that sort of thing. Maybe even enough information to impersonate the user over the phone to someone they do business with.

In the event someone did decide to intercept inputs, most people's sensitive keyboard activity takes place in the browser anyway, so if an attacker can't break out of it they still don't have much of a problem.

[Hungry Man]

Sure, you can dump accounts etc. I know more about that on Windows than Linux like /repair/SAM and /regback/SAM etc. But on Linux I'm assuming that using something like Apparmor would solve that easily whereas there is no solution (other than SELinux -x, which is way less than ideal) for X keylogging.

Same goes for the browser having more access than it needs - that's a permissions issue with tools already available to solve it.

And, again, following the Linux security model (users/groups) you can run your Firefox as a separate user and mitigate a lot of those attacks. But X-Keylogging remains, breaking the user/group model.

Lots of the information being entered into the browser is sensitive, but I don't see how that makes it *less* dangerous that an attacker can view the rest of your input such as into a terminal, gksudo, or sensitive files.

[OpSecShellshock]

It's less about danger than risk to the user's data and passwords. For home users having an attacker gain full control of their computer is certainly annoying and inconvenient, but the most it's going to cost them is the time they spend recovering. Which is good, because there always comes a point at which there's nothing you can do to stop it (even if a lot of other things have to go wrong before you get there).

Cleaning up after having accounts with other providers/sites/services/whatever compromised is more of a pain. But resetting passwords is easy and disputing fraudulent charges (in the US) is getting easier and easier because it happens so often now. About the most destructive thing an attacker could do from a life-ruining standpoint is use someone's system for storage of Very Bad Files.

All of which is just a complicated way of saying users should prepare for recovery as their primary strategy. Even though the likelihood of an attacker gaining control of a system is low, assume it's going to happen and just always be ready to recover from it. This has the extra benefit of also preparing users for catastrophic hardware failure.

Back around to the topic, there are things people can do to stop exploits from triggering in the first place, such as blocking scripts, advertisements, and embedded objects. If that fails, then there's going to be an attempt at file access or code execution, which can be constrained with AppArmor or whatever MAC solution you prefer. If that fails then you're into an area where there's nothing you can do to stop an attack, so there's no sense in worrying too much. You can protect sensitive data to an extent by having it inside an encrypted volume separate from the day to day stuff, but that's only a solution if it isn't mounted or in use at the time of attack. But once things have gone wrong to the point you can't stop say a shell or a keystroke logger, you're going to rebuild your system anyway, so just concentrate on recovery.

[Ms. Daisy]

+1

Backups are not sexy but they're extremely effective for a quick recovery.

[Hungry Man]

Backups necessitate the ability to determine when we're compromised. Really useful and effective, but oftentimes the damage is already done if we're talking about attacks involving keyloggers. Unlike ransomware/ trojans a keylogger isn't necessarily going to announce itself.

To be honest, I'm not gonna rely on a bank to say "Oh, I understand" when it comes to these things and I've worked for banks.

I agree that prevention is key but we can't rely on it. It would be nice to see UI isolation considering how trivial this makes something as serious as keylogging.

I'm not trying to sound like I'm spreading fear or anything, an attack on a Linux desktop is incredibly unlikely; even though keylogging is trivial you could hit 100% of the userbase and still not get as many users as a windows attack that hit a small percentage. But I think this vulnerability should be taken seriously.

[Ms. Daisy]

I understand wanting to prevent vs. recover. If you want real defense you have to have a plan for both, though. Hence backups are fantastic advice for recovery. Full stop.

There are people (not just Hungry Man) who seem to be overly-concerned with keyloggers. So I decided to dig for some stats on what percentage of malware includes keyloggers. (if you find some better stats please share!)

http://blogs.mcafee.com/mcafee-labs/a-look-at-one-day-of-malware-samples

So a year ago roughly 10% of the day's malware were keyloggers. (The study didn't include the popularity of each malware, so that could skew the results I suppose.) Therefore keyloggers are nothing to ignore, but they're certainly not the vast majority of threats out there either. I think that's why OpSecShellshock was saying he couldn't see anyone putting the work into creating a better mandatory access control solution for keyloggers.

[Hungry Man]

I thought it was closer to 4%. Based on a study I trust to be accurate, though outdated. It could be 10% now. For Linux home users it's quite likely <1% (of the scope of malware out there).

If we were concerned with what malware actually resides in the real world this forum would be nothing but posts about locking down servers. I'm assuming that if we're talking about a browser we're talking about a user and if we're talking about a user the conversation can go in two ways:

1) We inform that that Linux users don't have to worry about malware because malware for Linux is virtually nonexistent.

2) We indulge the concept that security has to do with possibilities and every vulnerability isn't exploited until the day that it is.

I think going into both makes the most sense. I also think people like to tout Linux as secure but you bring up security holes and they go "Well no one attacks Linux anyways". This is probably the biggest issue with Linux security because it's so ingrained into upstream, I think Linus was at one point 'awarded' one of those yearly "biggest security screwups" for his constant missing-the-point statements about security ("a bug is a bug").

For the most part that's what X-Keylogging is met with - immediate downplaying of the issue when it's pretty damn gaping. And this is true of a lot of things, there are a number of mislabeled bugs as DOS or vague 'overrun' when they're clearly exploitable.

In terms of what the browser can do when compromised I would say keylogging is likely the most dangerous outside of local exploitation; in fact I would say it's more dangerous than local exploitation because there exist methods to prevent that and there exists no method to prevent keylogging on Linux.

OT: I don't consider recovery security. I remember in my Security class we learned about recovery, it was interesting because whereas everything else we'd learned about was about prevention and detection recovery was given its own section and it revolved entirely around things like cost analysis etc. and had very little to do with security.

I've probably gone very OT at this point haha but I do like to indulge.

[OpSecShellshock]

Yeah and detection is really just not there on Linux desktops, to the point where I suggest folks don't bother trying. Management of risk is a big driver of security improvements, and the risk isn't enough to justify development of solid heuristic detection. Even if someone did develop such a thing, it may not be worth the expenditure of system resources for such a low risk. But I guess that brings it back around to costs. Now, if someone decided to port Android malware over to other distributions things might get interesting.

I do think management of risk is a discussion worth having in these threads, because otherwise I'd have to choose between telling people not to worry or telling them to be constantly anxious about what could happen even if it probably won't. I can't really do either.

And I don't mean to downplay the issue of code execution and input interception across graphical applications, because it is an issue and there's a lot of real risk there if anyone wants to take advantage of it. I also don't think it's likely the developers are going to fix it, so I tend to base my advice around things people can do themselves, immediately.

[Hungry Man]

Heuristic detection for Linux would have to be really different since you don't have malware to create signatures. You'd either have to guess or come up with a new way to detect.

If the DalvikVM gets ported to Ubuntu we may see Android malware on it - that would be interesting, yeah.

Anyways, I agree with you - it's just a matter of discussion but being realistic is important and we both agree the developers aren't going to fix it. This issue isn't new by any means.

[jrog]

I haven't seen anybody mention Qubes in this thread. Are any of you aware of it? I believe it is supposed to (among other things) prevent the sort of keylogging between X applications being discussed here. Here's a link to the Qubes website: http://qubes-os.org/Home.html. Here's a link to a blog post where one of the Qubes developers discusses keylogging between X applications specifically: http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html.

[Stonecold1995]

I haven't seen anybody mention Qubes in this thread. Are any of you aware of it? I believe it is supposed to (among other things) prevent the sort of keylogging between X applications being discussed here. Here's a link to the Qubes website: http://qubes-os.org/Home.html. Here's a link to a blog post where one of the Qubes developers discusses keylogging between X applications specifically: http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html.
I think if you wanted a really secure operating system Hardened Gentoo would be a better idea. Or maybe FreeBSD but that's not Linux.

[Hungry Man]

Yeah, most of the information out there is actually related to Qubes because a lot of people refuse to discuss it.

It solves this by implementing X in a way that should be default - multiple X sessions and isolating user accounts.

[Stonecold1995]

It solves this by implementing X in a way that should be default - multiple X sessions and isolating user accounts.
Isn't Wayland suppose to do that as well?

[Hungry Man]

I think Wayland requires root for global hotkeys. I've only ever heard about GUI isolation in it, never seen official documentation.

[BigCityCat]

From a lay mens point of view. Is a minimized application using x session? Also is keepassx perform auto type function or copied to clip board information encrypted?

If it is then as long as keepassx is the only app open when you put in the master password you would be safe. I mean wouldn't you have to have a malicious app or infected browser open to implement.

[Hungry Man]

A minimized application is using X/ has X access. It's not so much that an application has to be using X so much as it needs to have access to X.

But yes, you would either need a malicious application with X access or some process with X access would have to have been exploited.

[BigCityCat]

Thanks

I think just to be safe I will run a dedicated browser with no addons, a clean history and keepassx only... when dealing with sensitive information. Obviously it's probably not an issue but why not.

[BigCityCat]

A minimized application is using X/ has X access. It's not so much that an application has to be using X so much as it needs to have access to X.

But yes, you would either need a malicious application with X access or some process with X access would have to have been exploited.

Does the clipboard use x?

[Hungry Man]

I believe so.

[BigCityCat]

Well under those circumstances an infected app or process could read your master password and any info used with the clipboard provided both were using x at the same time.

I think the Wayland team is aware of this issue and has plans to try and deal with it. I found this link on the Wayland devel mailing list where the primary developer of Qubes OS has an interesting exchange with a Wayland developer.

http://comments.gmane.org/gmane.comp.freedesktop.wayland.devel/1867

I would be interested in some of you guys take on the Wayland developers response.

[Hungry Man]

They state "don't give a program session access" but we're talking about exploited programs, so it's different. But they do state that keys aren't broadcasted globally, they're handled by the compositor, which is what I expected them to do.

I'll finish reading and give a better response later.