Date: Wed, 10 Feb 2021 10:28:42 +0100 From: Matthias Gerstner <mgerstner@...e.de> To: oss-security@...ts.openwall.com Subject: Replay-Sorcery: CVE-2021-26936: Multiple security issues in with setuid-root program in versions 0.4.0 through 0.5.0 Hello, we received a review request  for ReplaySorcery  for inclusion in the openSUSE Linux distribution. ReplaySorcery allows to record short videos of screen content, triggered via a key combination. Since version 0.4.0 released on 2020-12-19 through to the current version 0.5.0 the replay-sorcery program is by default installed with setuid-root and (unnecessarily) setgid-root bits and is thus running with root privileges. The motivation for this was to improve screen capture performance via vaapi, which requires `CAP_SYS_ADMIN` privileges . I reviewed the security of ReplaySorcery in the setuid-root context. The outcome of the review is that the replay-sorcery program is not fit to run as setuid-root in the currently released versions. The program does not take any of the many precautions that are necessary to avoid security issues in setuid-root programs. The issues start with things like failure to establish safe environment variables and end with careless file system accesses with elevated rights. There happens no user privilege management at all i.e. the program runs with full root privileges all of the time. Following are a couple of specific issues I could find right away (probably not a complete list): a) The $HOME environment variable is interpreted by the program. Thus an unprivileged user can cause the configuration files of other users to be used, or output videos to be created in arbitrary (home) directories. b) The $DISPLAY environment variable is interpreted, which could allow in theory to record videos from other users' X displays. Together with setting $XAUTHORITY to another user's Xauthority file this nearly allows to do that. Only that fact that libX11 is doing an `access()` check on the Xauthority file first comes to the rescue (`access()` takes the real user ID into account). For other graphic systems like Wayland or kms the outcome might be different, I did not extensively test that. c) When reading config files in ~/.config/replay-sorcery.conf symlinks are followed. This allows for arbitrary file existence tests, opening of arbitrary special files (with potential side effects in the kernel) and also parsing files not normally accessible to the calling unprivileged user. The parsing will typically fail but could leak information from the file in some circumstances (e.g. through logging, when the target format matches the configuration file syntax in some ways). d) When writing video output files into the user's home directory (by default ~/Videos/ReplaySorcery_%F_%H-%M-%S.mp4) then symlinks will be followed. Either the Videos folder or the target filename itself can be symlinks (apart from being able to setting $HOME to arbitrarily change the home directory). Even when the timestamp with second granularity is used it is pretty simple to pre-create a range of symlinks resulting in arbitrary file overwrite, resulting in local denial-of-service. e) By configuring a user specific `outputFile` in ~/.config/replay-sorcery.conf like outputFile = /etc/ld.so.conf.d/mylib.conf the video will be created in the path in `/etc/ld.so.conf.d.d`. When setting `umask 0` before running the replay-sorcery program then this file will receive mode 0666 and owner root:root. Thus it can be edited by anybody. This can allow for a full local root exploit via various vectors depending on the target directory. If the target path already exists then it will only be overwritten but the mode will remain the same. This still allows for a denial-of-service. I reported these issues to the upstream developer on 2021-01-29. We discussed various approaches to fix the issues. By now two upstream commits ,  greatly improve the situation by dropping effective capabilities to the unprivileged user and only obtain root privileges for calling into ffmpeg library functions when the vaapi acceleration is necessary. I could not find any obvious security issues with this new approach but it still feels uneasy calling into the ffmpeg library in a setuid-root context. Also the replay-sorcery code does not yet take precautions to clear the environment and set a safe umask value. I urged the upstream developer to do that as well. As a workaround for these security issues ReplaySorcery can be built with the CMake setting `-DRS_SETID=OFF` to prevent installation with setuid-root and setgid-root bits. The only drawback will be the missing vaapi acceleration in certain configurations. : https://bugzilla.suse.com/show_bug.cgi?id=1181321 : https://github.com/matanui159/ReplaySorcery : https://trac.ffmpeg.org/wiki/Hardware/VAAPI#ScreenCapture : https://github.com/matanui159/ReplaySorcery/commit/d6580072582a31c72fdf70fdc80431eddeb3ddc6 : https://github.com/matanui159/ReplaySorcery/commit/557e8e80ab7934bfe8521f96c237ea62b961e74e Cheers Matthias -- Matthias Gerstner <matthias.gerstner@...e.de> Dipl.-Wirtsch.-Inf. (FH), Security Engineer https://www.suse.com/security 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.