Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Tue, 27 Jul 2021 09:45:50 +0200
From: Matthias Gerstner <>
Subject: replay-sorcery: CVE-2021-36983: kms service in version 0.6.0 allows
 local root exploit and other local attack vectors

Hello list,

ReplaySorcery [1] upstream version 0.6.0 has introduced new security
issues. I already reviewed version 0.5.0 a while ago and found issues in
its implementation of a setuid-root program [2].

By now this setuid-root program has been deprecated by upstream and has
been replaced by a systemd service running as root called
"replay-sorcery-kms" that is supposed to provide the same functionality
(opening a DRI device with the ffmpeg library for hardware acceleration
support when recording screen contents).

# Findings in Version 0.6.0

The upstream author asked me to check up on the security of the new
systemd service. The basic idea is that the kms system service opens any
DRI devices via the ffmpeg library and passes back the open file
descriptors to clients of a UNIX domain socket that the service provides
in the system. I have found the following issues:

a) The UNIX domain socket is placed into the fixed path
  /tmp/replay-sorcery is a predictable path in a world writable
  directory, i.e. any other user in the system can precreate it
  and thus take control of the directory and its contents. For example
  by removing the intended device.sock and creating a different socket
  there, clients in the system will then communicate with other parties
  than intended.

b) The service calls the `kmsChmod()` function for both /tmp/replay-sorcery
  and /tmp/replay-sorcery/device.sock. This function performs a
  `chmod(path, 0777)`. Thus a local attacker can stage symlink attacks
  in both locations. The attack via /tmp/replay-sorcery is thwarted by
  the Linux kernel's symlink protection. The attack via the socket
  filename is not, because /tmp/replay-sorcery will not have a sticky
  bit set. So the attacker only has to win a race condition between the
  kms service binding the socket and performing the chown() during
  startup. This allows for a local root exploit achievable every time
  when the kms service is starting up.

c) During receiption of the RSServiceDeviceInfo data structure from a
  client, the (size_t) deviceLength parameter has no upper limit i.e.
  clients can cause denial-of-service by causing large memory
  allocations in the service.

d) When accepting client connections the service does not make
  sure that the client is somehow authorized to access the local
  display. E.g. by it being a member of a special restricted
  group, or by it owning a local active graphical session. This could
  allow unprivileged local processes to access display contents of
  logged in interactive users.

# CVE Assignment

I received CVE-2021-36983 from Mitre for the local root exploit in
issue b).

# Bugfixes

To my knowledge there are currently no bugfixes available for this. I
recommend neither to use the setuid-root option nor the systemd service
until these issues are handled.

# Timeline

2021-07-12: Received review request from the upstream author by e-mail.
2021-07-20: I reported these findings to the upstream author.
2021-07-21: I received the CVE from Mitre and offered the upstream
            author an embargo until 2021-07-26.
2021-07-27: No reply from the upstream author so far, publication of the




Matthias Gerstner <>
Dipl.-Wirtsch.-Inf. (FH), Security Engineer
Phone: +49 911 740 53 290
GPG Key ID: 0x14C405C971923553
SUSE Software Solutions Germany GmbH
HRB 36809, AG Nürnberg
Geschäftsführer: Felix Imendörffer

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.