Bug#887348: steam:i386: execmod access is requested, security issue
Hi, On 16/01/18 03:41, Russell Coker wrote: > On Monday, 15 January 2018 2:15:40 PM AEDT James Cowgill wrote: >>> Sorry, we do not control the binaries that Valve >>> use in Steam. You're welcome to take this upstream to >>> https://github.com/ValveSoftware/steam-for-linux/issues/ if you believe >>> the use of generic i386 binaries is a security problem. >>> >>> path="/home/rjc/.steam/ubuntu12_32/libavutil.so.55" >> >> Arguably this is an ffmpeg bug. I expect you will find that this will >> also happen if you try to run any program which uses ffmpeg on a machine >> with Debian i386 and SELinux installed. > > It's a compilation choice for ffmpeg. Last time I checked that same choice > was made by the maintainers of the Debian package, so for some years I had a > repository of alternate ffmpeg packages to support a more strict > configuration > of SE Linux on the i386 desktop - which incidentally also made things more > secure for i386 users who didn't use SE Linux. I stopped supporting thost > packages because i386 desktops are almost never used nowadays, the i386 > architecture is uncommon and most use of it is for routers and embedded > systems. > > But in this case the compilation choice was made by Steam upstream. I filed > a > bug report here so that everyone is aware of it and anyone who looks up the > issue will know that it's a known issue. I had a harder look at this, and it seems that the x86 assembly from modern ffmpeg will require significant patching to be made PIC on x86_32. Changing a few flags to enable PIC results in hundreds of assembly errors. At the moment the only way to avoid the textrels is to disable all assembly which is too much of a performance hit (I expect for both Debian and Steam). A few bugs I found: https://trac.ffmpeg.org/ticket/4928 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493705 James signature.asc Description: OpenPGP digital signature
Bug#887348: steam:i386: execmod access is requested, security issue
On Monday, 15 January 2018 2:15:40 PM AEDT James Cowgill wrote: > > Sorry, we do not control the binaries that Valve > > use in Steam. You're welcome to take this upstream to > > https://github.com/ValveSoftware/steam-for-linux/issues/ if you believe > > the use of generic i386 binaries is a security problem. > > > > path="/home/rjc/.steam/ubuntu12_32/libavutil.so.55" > > Arguably this is an ffmpeg bug. I expect you will find that this will > also happen if you try to run any program which uses ffmpeg on a machine > with Debian i386 and SELinux installed. It's a compilation choice for ffmpeg. Last time I checked that same choice was made by the maintainers of the Debian package, so for some years I had a repository of alternate ffmpeg packages to support a more strict configuration of SE Linux on the i386 desktop - which incidentally also made things more secure for i386 users who didn't use SE Linux. I stopped supporting thost packages because i386 desktops are almost never used nowadays, the i386 architecture is uncommon and most use of it is for routers and embedded systems. But in this case the compilation choice was made by Steam upstream. I filed a bug report here so that everyone is aware of it and anyone who looks up the issue will know that it's a known issue. > This happens because ffmpeg contains some i386 assembly routines which > intentionally use TEXTRELs in the name of performance. Maybe the code > should be reworked to be totally position independent. It would be > interesting to see the exact performance cost of enabling PIC for these > specific routines. I've seen claims of as much as a 15% performance hit in the past. IMHO it's worth losing 15% of performance for security given that security is decreased for every application which links against that library or any other library that links against it. In this case the Steam downloader is using that library. The Steam downloader is a network facing application that includes a small web browser among other things. I think that the security issue is more important than the theoretical performance issue in this case. Particularly as 64bit code would give both better performance (solving the lack of registers problem that led to all of this) as well as better security. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/
Bug#887348: steam:i386: execmod access is requested, security issue
Hi, On 15/01/18 11:18, Simon McVittie wrote: > Control: tags -1 + wontfix > > On Mon, 15 Jan 2018 at 21:47:32 +1100, Russell Coker wrote: >> this should be fixed > ... >> recompiling > > Sorry, we do not control the binaries that Valve > use in Steam. You're welcome to take this upstream to > https://github.com/ValveSoftware/steam-for-linux/issues/ if you believe > the use of generic i386 binaries is a security problem. > path="/home/rjc/.steam/ubuntu12_32/libavutil.so.55" Arguably this is an ffmpeg bug. I expect you will find that this will also happen if you try to run any program which uses ffmpeg on a machine with Debian i386 and SELinux installed. The lintian warning which usually occurs when you do this sort of thing is overridden here: https://sources.debian.org/src/ffmpeg/7:3.4.1-1/debian/libavutil55.lintian-overrides/ This happens because ffmpeg contains some i386 assembly routines which intentionally use TEXTRELs in the name of performance. Maybe the code should be reworked to be totally position independent. It would be interesting to see the exact performance cost of enabling PIC for these specific routines. James signature.asc Description: OpenPGP digital signature
Bug#887348: steam:i386: execmod access is requested, security issue
On Tue, 16 Jan 2018 at 00:13:32 +1100, Russell Coker wrote: > Can't an amd64 package have dependencies on i386 packages? Dependencies with an :architecture qualifier aren't allowed, as of last time I asked (I think the only one allowed is the :any pseudo-architecture, usually seen as python3:any). The least bad workaround available would be for steam:amd64 to depend on steam-graphics-i386 which happens to be Multi-Arch: foreign and only available on i386, and then if it's a hard dependency (which it probably should be, because there's a very long tail of legacy i386 games) ask the release team (once) to force it into testing even though it appears to be uninstallable when you only consider amd64. That's how Wine (wine32) and the proprietary NVIDIA graphics drivers (nvidia-drivers-libs-i386) deal with the equivalent situation, and how libnss-mdns handled the upgrade path from pre-multiarch versions. smcv
Bug#887348: steam:i386: execmod access is requested, security issue
> Impact: am I right in thinking that this is not in itself a security > vulnerability, but that if there is a separate security vulnerability > somewhere in Valve's binaries, having execmod access makes it > significantly easier for an attacker to turn that vulnerability into > arbitrary code execution, similar to an absence of the hardening measures > (stack protecter, PIC, etc.) that we're encouraged to use in packages > that are built from source? Yes. > Am I right in saying that replacing some or all of the i386 binaries > with x86_64 binaries would be sufficient? Or is there some simple thing > Valve could do with a general-purpose compiler (I think they use gcc/g++) > to get i386 binaries with the right magic flags? Replacing with AMD64 doesn't inherently solve the problem. But as AMD64 has no shortage of registers the assembler tricks used for performance on i386 aren't used and this solves the problem. They could just not use the assembler. I really don't think that they are doing anything performance intensive in this regard. When I maintained my own fork of those packages to address this issue (when i386 on the desktop was useful) I didn't have any performance problems with programs like mplayer. > (I don't know whether Valve would be willing to require x86_64 for Steam > - a lot of older games are only available as i386 binaries, and having > steam be an i386 package makes it a lot easier to pull in i386 multiarch > graphics drivers and other necessary libraries from the host system - > but it's worth asking.) If they had "steam" as an amd64-only package it would mean that you couldn't install Steam games on an i386 system. I really doubt that anyone wants to do that nowadays given that quad core amd64 systems can be found as rubbish nowadays. So if they entirely dropped support for running games on i386 it wouldn't be a problem and the i386 compiled games once installed would run fine. Of course i386 games might have the same issue, but that would only affect people who run those particular games while the current issue affects everyone who uses steam. Can't an amd64 package have dependencies on i386 packages? Surely a better solution to depending on multiarch graphics drivers would be for a steam:amd64 package to recommend steam-graphics:i386 which depends on the graphics packages in question. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/
Bug#887348: steam:i386: execmod access is requested, security issue
On Mon, 15 Jan 2018 at 22:40:16 +1100, Russell Coker wrote: > On Monday, 15 January 2018 11:18:42 AM AEDT Simon McVittie wrote: > > Sorry, we do not control the binaries that Valve > > use in Steam. You're welcome to take this upstream to > > https://github.com/ValveSoftware/steam-for-linux/issues/ if you believe > > the use of generic i386 binaries is a security problem. > > https://github.com/ValveSoftware/steam-for-linux/issues/5340 Thanks. That might be more likely to be addressed if there was a tl;dr summary of the impact and solution that doesn't require reading blog posts. Impact: am I right in thinking that this is not in itself a security vulnerability, but that if there is a separate security vulnerability somewhere in Valve's binaries, having execmod access makes it significantly easier for an attacker to turn that vulnerability into arbitrary code execution, similar to an absence of the hardening measures (stack protecter, PIC, etc.) that we're encouraged to use in packages that are built from source? Am I right in saying that replacing some or all of the i386 binaries with x86_64 binaries would be sufficient? Or is there some simple thing Valve could do with a general-purpose compiler (I think they use gcc/g++) to get i386 binaries with the right magic flags? (I don't know whether Valve would be willing to require x86_64 for Steam - a lot of older games are only available as i386 binaries, and having steam be an i386 package makes it a lot easier to pull in i386 multiarch graphics drivers and other necessary libraries from the host system - but it's worth asking.) smcv
Bug#887348: steam:i386: execmod access is requested, security issue
On Monday, 15 January 2018 11:18:42 AM AEDT Simon McVittie wrote: > Sorry, we do not control the binaries that Valve > use in Steam. You're welcome to take this upstream to > https://github.com/ValveSoftware/steam-for-linux/issues/ if you believe > the use of generic i386 binaries is a security problem. https://github.com/ValveSoftware/steam-for-linux/issues/5340 Done. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/
Bug#887348: steam:i386: execmod access is requested, security issue
Control: tags -1 + wontfix On Mon, 15 Jan 2018 at 21:47:32 +1100, Russell Coker wrote: > this should be fixed ... > recompiling Sorry, we do not control the binaries that Valve use in Steam. You're welcome to take this upstream to https://github.com/ValveSoftware/steam-for-linux/issues/ if you believe the use of generic i386 binaries is a security problem. smcv
Bug#887348: steam:i386: execmod access is requested, security issue
Package: steam
Version: 1.0.0.54-3
Severity: normal
Tags: upstream
type=AVC msg=audit(1516012042.500:1381380): avc: denied { execmod } for
pid=4488 comm="steam" path="/home/rjc/.steam/ubuntu12_32/libavutil.so.55"
dev="sda2" ino=64950
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=0
Above is an audit message from running steam with a fairly default SE Linux
configuration in enforcing mode. The command "setsebool allow_execmod 1"
permits this to work, but this should be fixed. Allowing execmod access
weakens the security of the system in general, and when the shared object
requests it the security of the application is weakened.
https://etbe.coker.com.au/2008/09/11/execmod-and-se-linux-i386-must-die/
Above is a blog post I wrote about this in 2008. The root cause of this is
assembler optimisations for i386. If the steam package was released in an
AMD64 variant then the default compile of libavutil would solve this problem
(back in 2008 I spent a lot of time recompiling libabutil and related libraries
to fix this on i386 while AMD64 just worked as desired).
https://etbe.coker.com.au/2007/02/10/execmod/
Here's another blog post I wrote about this.
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.14.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8),
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Enforcing - Policy name: default
Versions of packages steam:i386 depends on:
ii debconf [debconf-2.0] 1.5.65
ii libc6 2.26-2
ii libgl1-mesa-dri 17.2.5-1
ii libgl1-mesa-glx 17.2.5-1
ii libgpg-error0 1.27-5
ii libstdc++67.2.0-19
ii libtxc-dxtn-s2tc0 [libtxc-dxtn0] 0~git20131104-1.1
ii libudev1 236-2
ii libx11-6 2:1.6.4-3
ii libxinerama1 2:1.1.3-1+b3
ii xz-utils 5.2.2-1.3
Versions of packages steam:i386 recommends:
ii fonts-liberation 1:1.07.4-5
ii konsole [x-terminal-emulator] 4:17.08.3-1
ii libxss11:1.2.2-1+b2
ii xterm [x-terminal-emulator]331-1
ii zenity 3.26.0-2
Versions of packages steam:i386 suggests:
pn steam-devices
-- no debconf information
