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

[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.