frqb4td | 16 Feb 19:36 2012
Picon

Passive and active attacks via X11. Is Wayland any better?

In "The Linux Security Circus: On GUI isolation" (link: http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html ) - The Invisible Things Lab's blog, Joanna Rutkowska describes attacks from one X11 app on another and the general problem of the lack of GUI-level isolation, and how it essentially nullifies all the desktop security.

One application can sniff or inject keystrokes to another one, can take snapshots of the screen occupied by windows belonging to another one, etc.

The bit about how the X11 security model has changed over time and doesn't fit well with Linux was interesting. She pitches Qubes OS (Beta 1) as a secure alternative.

My questions:
Can passive (snooping) attacks be avoided? The passive attack she describes certainly works on my system, though I note that one of the comments says gksudo input can't be snooped.


Can active attacks (injecting keystrokes) be avoided? I seem to recall that active attacks was turned of by default a long time ago. But a quick google suggests that the XTest extension nullifies that (How to map a key-combination to a keyboard-button?).


Most Linux distros are moving to Wayland as a replacement for X11. Does it provide for good isolation between apps?

Is there hope for security on the desktop? :)
_______________________________________________
wayland-devel mailing list
wayland-devel@...
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Daniel Stone | 16 Feb 22:47 2012

Re: Passive and active attacks via X11. Is Wayland any better?

Hi,

On 16 February 2012 18:36, frqb4td <frqb4td@...> wrote:
> One application can sniff or inject keystrokes to another one, can take
> snapshots of the screen occupied by windows belonging to another one, etc.

That's more or less irrelevant really.  If you give session access to
hostile apps, they could easily do things like repeatedly steal all
the clipboard contents (at best) or just pretend to be your web
browser or terminal and steal every single one of your credentials (at
worst).

So, don't do that.

> Can passive (snooping) attacks be avoided? The passive attack she describes
> certainly works on my system, though I note that one of the comments says
> gksudo input can't be snooped.

Indeed, neither can screensavers.  They can be avoided, and Wayland
doesn't allow for them.

> Can active attacks (injecting keystrokes) be avoided? I seem to recall that
> active attacks was turned of by default a long time ago. But a quick google
> suggests that the XTest extension nullifies that (How to map a
> key-combination to a keyboard-button?).

I believe Wayland won't be vulnerable to these either.

But seriously - if you can't trust an app, don't give it arbitrary
access to your desktop session.  It's not going to end well.

Cheers,
Daniel
Tiago Vignatti | 17 Feb 09:43 2012
Picon

Re: Passive and active attacks via X11. Is Wayland any better?

Hi,

On 02/16/2012 08:36 PM, frqb4td wrote:
> In "The Linux Security Circus: On GUI isolation" (link:
> http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html
> ) - The Invisible Things Lab's blog, Joanna Rutkowska describes attacks
> from one X11 app on another and the general problem of the lack of
> GUI-level isolation, and how it essentially nullifies all the desktop
> security.

well, she's initially totally missed the motivations of XACE initially 
and designed her own "security" mechanism then. It doesn't sound quite 
right in terms of research, just to begin with... anyways: "New comments 
have been disabled for this post by a blog administrator." :(

> Can passive (snooping) attacks be avoided? The passive attack she
> describes certainly works on my system, though I note that one of the
> comments says gksudo input can't be snooped.

Input delivery for Wayland clients works in a different way from the X: 
while in X the events are broadcasted to all clients interested, on 
Wayland this happens by the compositor choosing the correct client 
surface (weston_compositor_pick_surface, on Weston). So I don't see any 
way to a client sniff another with Wayland's current model. One could 
eavesdrop UNIX sockets though, but that's a different story.

> Can active attacks (injecting keystrokes) be avoided? I seem to recall
> that active attacks was turned of by default a long time ago. But a
> quick google suggests that the XTest extension nullifies that (How to
> map a key-combination to a keyboard-button?).

Wayland doesn't provide any way to inject artificial events at the 
moment. But definitely it will be designed with security on mind. So 
yeah, we're safe on this side now  as well :)

   Tiago
Joanna Rutkowska | 17 Feb 19:39 2012

Re: Passive and active attacks via X11. Is Wayland any better?

On 02/17/12 09:43, Tiago Vignatti wrote:
> Hi,
> 
> On 02/16/2012 08:36 PM, frqb4td wrote:
>> In "The Linux Security Circus: On GUI isolation" (link:
>> http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html
>>
>> ) - The Invisible Things Lab's blog, Joanna Rutkowska describes attacks
>> from one X11 app on another and the general problem of the lack of
>> GUI-level isolation, and how it essentially nullifies all the desktop
>> security.
> 
> well, she's initially totally missed the motivations of XACE initially
> and designed her own "security" mechanism then. It doesn't sound quite
> right in terms of research, just to begin with... anyways: "New comments
> have been disabled for this post by a blog administrator." :(
> 

Boo!

> 
>> Can passive (snooping) attacks be avoided? The passive attack she
>> describes certainly works on my system, though I note that one of the
>> comments says gksudo input can't be snooped.
> 
> Input delivery for Wayland clients works in a different way from the X:
> while in X the events are broadcasted to all clients interested, on
> Wayland this happens by the compositor choosing the correct client
> surface (weston_compositor_pick_surface, on Weston). So I don't see any
> way to a client sniff another with Wayland's current model. One could
> eavesdrop UNIX sockets though, but that's a different story.
> 
> 
>> Can active attacks (injecting keystrokes) be avoided? I seem to recall
>> that active attacks was turned of by default a long time ago. But a
>> quick google suggests that the XTest extension nullifies that (How to
>> map a key-combination to a keyboard-button?).
> 
> Wayland doesn't provide any way to inject artificial events at the
> moment. But definitely it will be designed with security on mind. So
> yeah, we're safe on this side now  as well :)
> 

That's a very comforting statement! However, being a nasty person as I
am, let me ask a few more questions:

1) Are you planning to support on-screen keyboard apps? If so, how this
is going to be implemented, so that a malicious/compromised app couldn't
act as such "on-screen keyboard" and inject keystrokes to other apps?

2) Are you planning to support screenshot-taking apps, or
jigsaw-puzzle-like screensavers? If so, how are you planning to prevent
malicous/compromised apps from sniffing the content of other apps? E.g.
I might not be happy seeing Tetris being able to take screenshots of my
Thunderbird's windows and send them back to China...

3) How is Wayland going to protect the clipboard from being
sniffed/modified by 3rd party apps? E.g. I want to copy my bank password
from KeepassX to Firefox, and don't want Tetris to be able to eavesdrop
on that...

Cheers,
joanna.

_______________________________________________
wayland-devel mailing list
wayland-devel@...
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Kristian Høgsberg | 17 Feb 20:20 2012
Picon

Re: Passive and active attacks via X11. Is Wayland any better?

On Fri, Feb 17, 2012 at 1:39 PM, Joanna Rutkowska
<joanna <at> invisiblethingslab.com> wrote:
> On 02/17/12 09:43, Tiago Vignatti wrote:
>> Hi,
>>
>> On 02/16/2012 08:36 PM, frqb4td wrote:
>>> In "The Linux Security Circus: On GUI isolation" (link:
>>> http://theinvisiblethings.blogspot.com/2011/04/linux-security-circus-on-gui-isolation.html
>>>
>>> ) - The Invisible Things Lab's blog, Joanna Rutkowska describes attacks
>>> from one X11 app on another and the general problem of the lack of
>>> GUI-level isolation, and how it essentially nullifies all the desktop
>>> security.
>>
>> well, she's initially totally missed the motivations of XACE initially
>> and designed her own "security" mechanism then. It doesn't sound quite
>> right in terms of research, just to begin with... anyways: "New comments
>> have been disabled for this post by a blog administrator." :(
>>
>
> Boo!
>
>>
>>> Can passive (snooping) attacks be avoided? The passive attack she
>>> describes certainly works on my system, though I note that one of the
>>> comments says gksudo input can't be snooped.
>>
>> Input delivery for Wayland clients works in a different way from the X:
>> while in X the events are broadcasted to all clients interested, on
>> Wayland this happens by the compositor choosing the correct client
>> surface (weston_compositor_pick_surface, on Weston). So I don't see any
>> way to a client sniff another with Wayland's current model. One could
>> eavesdrop UNIX sockets though, but that's a different story.
>>
>>
>>> Can active attacks (injecting keystrokes) be avoided? I seem to recall
>>> that active attacks was turned of by default a long time ago. But a
>>> quick google suggests that the XTest extension nullifies that (How to
>>> map a key-combination to a keyboard-button?).
>>
>> Wayland doesn't provide any way to inject artificial events at the
>> moment. But definitely it will be designed with security on mind. So
>> yeah, we're safe on this side now  as well :)
>>
>
> That's a very comforting statement! However, being a nasty person as I
> am, let me ask a few more questions:
>
> 1) Are you planning to support on-screen keyboard apps? If so, how this
> is going to be implemented, so that a malicious/compromised app couldn't
> act as such "on-screen keyboard" and inject keystrokes to other apps?

We can restrict access to functionality on a per-application basis.
An on-screen keyboard would be part of the core ui and launched by the
compositor in a way that gives it access to the "input event
injecting" interface.

> 2) Are you planning to support screenshot-taking apps, or
> jigsaw-puzzle-like screensavers? If so, how are you planning to prevent
> malicous/compromised apps from sniffing the content of other apps? E.g.
> I might not be happy seeing Tetris being able to take screenshots of my
> Thunderbird's windows and send them back to China...

No.  In general, clients don't have access to or even knowledge of any
other clients on the server.  They can't see other clients buffers or
any of the compositors front buffers.

We do have a screenshot example app that uses an example interface to
get a screenshot out of the server but that's only a demo and
something that we've explicitly enabled.  We might want to change that
to be triggered by a compositor hot-key to avoid setting a bad
example.

> 3) How is Wayland going to protect the clipboard from being
> sniffed/modified by 3rd party apps? E.g. I want to copy my bank password
> from KeepassX to Firefox, and don't want Tetris to be able to eavesdrop
> on that...

You only get access to the current selection when the application is
activated (receive keyboard focus).  If you don't want tetris to get
access to the clipboard at all, you have to be able to classify
clients as trusted or not, which is a bigger problem.  Actually
restricting access to the clipboard for an untrusted clients is a
small detail.  Ultimately, the clipboard is by definition for
inter-client communication and once you put something there, it's up
for grabs.  If you want a secure way to pass passwords between apps, I
suggest you don't use it.

Kristian
_______________________________________________
wayland-devel mailing list
wayland-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Bill Spitzak | 17 Feb 21:05 2012
Picon

Re: Passive and active attacks via X11. Is Wayland any better?

Kristian Høgsberg wrote:

>> 1) Are you planning to support on-screen keyboard apps? If so, how this
>> is going to be implemented, so that a malicious/compromised app couldn't
>> act as such "on-screen keyboard" and inject keystrokes to other apps?
> 
> We can restrict access to functionality on a per-application basis.
> An on-screen keyboard would be part of the core ui and launched by the
> compositor in a way that gives it access to the "input event
> injecting" interface.

I think a much easier way is that clients directly talk to the on-screen 
keyboard application.

* Clients that decide not to talk to it cannot possibly receive events.

* If the client knows it is talking to an on-screen keyboard it can also 
restrict the keys to text input and not have them trigger shortcuts.

* The api can allow information relevant to on-screen keyboards (such as 
it's position) to be communicated.
_______________________________________________
wayland-devel mailing list
wayland-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Michael Hasselmann | 17 Feb 21:57 2012

Re: Passive and active attacks via X11. Is Wayland any better?

On Fri, 2012-02-17 at 12:05 -0800, Bill Spitzak wrote:
> Kristian Høgsberg wrote:
> 
> >> 1) Are you planning to support on-screen keyboard apps? If so, how this
> >> is going to be implemented, so that a malicious/compromised app couldn't
> >> act as such "on-screen keyboard" and inject keystrokes to other apps?
> > 
> > We can restrict access to functionality on a per-application basis.
> > An on-screen keyboard would be part of the core ui and launched by the
> > compositor in a way that gives it access to the "input event
> > injecting" interface.
> 
> I think a much easier way is that clients directly talk to the on-screen 
> keyboard application.

Exposing the virtual keyboard to the applications means you have to
patch all toolkits that run on your platform, in order to support.
Desktops usually allow all kind of toolkits. So having the virtual
keyboard in the compositor allows it to support applications that use
different toolkits. It also allows the compositor to restrict access to
the active application, as Kristian mentioned.

On top of that, the virtual keyboard (and possibly other input methods)
only need to be launched once, if running inside the compositor. This
can affect application start up time significantly (think of
dictionaries and word engines that need to be initialized).

Giving applications too much control over the virtual keyboard also
makes it too easy for applications to simply provide their own, and then
any form of platform consistency is gone. I think it's better to have a
policy where toolkits need to implement the virtual keyboard support for
Wayland and the applications don't have to do anything at all.

That being said, there are a few use-cases where on-screen keyboard
inside the application makes sense, but for the majority of use-cases,
it's more beneficial to have it in the compositor (or even as a
dedicated process, but still protected from direct application access).

regards,
Michael

_______________________________________________
wayland-devel mailing list
wayland-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Gmane