Proxying Wayland for security

Carsten Haitzler raster at rasterman.com
Wed Jul 28 17:16:55 UTC 2021


On Wed, 28 Jul 2021 11:05:11 +0000 Simon Ser <contact at emersion.fr> said:

> On Wednesday, July 28th, 2021 at 12:30, Carsten Haitzler
> <raster at rasterman.com> wrote:
> 
> > On Wed, 28 Jul 2021 09:51:53 +0000 Simon Ser contact at emersion.fr said:
> >
> > > Please read the (lengthy) discussion at 1.
> > > In particular, the "get_credentials → PID → executable path" lookup is
> > > racy. PID re-use allows a malicious process to be recognized as another
> > > executable.
> >
> > That is true - but only at cusp points - e.g. PID has exited, but socket has
> > not been detected as dead yet and PID was recycled. I you do the lookup
> > then, it'd be a problem.
> >
> > If you do the lookup first on initial connect, then ensure you do at least
> > one round-trip to client (send something, it sends back a reply), then that
> > lookup would be valid
> 
> Nope. The PID returned by libwayland is the one that bound the socket.
> So if you create the socket, fork, bind it in the child, exit the
> child, then on the compositor side you'll see a socket which belongs to
> a PID which no longer exists. Wait until a privileged client re-uses
> that PID, and boom.

oooh i see. the rogue process waits for a lucky pid replace. it can set this
up. i was going to say "forking and keeping your fd alive is madness and unless
you have a very funky thing you generally close the fd before passing it off to
any child eg between fork and the exec". but yes - this can be abused to wait
for ANOTHER unrelated privileged client to slide into that pid slot.



-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com



More information about the wayland-devel mailing list