Bug#686648: ioquake3: consider disallowing auto-downloading in wheezy
Am 24.09.2012 09:52, schrieb Simon McVittie: Not intentional, patches welcome. I could not even reproduce this. When I start the game with an empty ~/.openarena and switch Automatic Downloading from off to on, the warning appears. Then I exit the game and restart it. Automatic Downloading is still set on, and when I set it back off and then on again, the warning appears again -- just as expected. - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686648: ioquake3: consider disallowing auto-downloading in wheezy
On Tue, 25. Sep 09:56 Fabian Greffrath fab...@greffrath.com wrote: Am 24.09.2012 09:52, schrieb Simon McVittie: Not intentional, patches welcome. I could not even reproduce this. When I start the game with an empty ~/.openarena and switch Automatic Downloading from off to on, the warning appears. Then I exit the game and restart it. Automatic Downloading is still set on, and when I set it back off and then on again, the warning appears again -- just as expected. Indeed it isn't reproducible with a clean installation of OpenArena. You have to connect to a heavily modded server like Gem's InstaGib server. After that you can see the difference. Regards Markus signature.asc Description: Digital signature
Bug#686648: ioquake3: consider disallowing auto-downloading in wheezy
On 25/09/12 13:44, Markus Koschany wrote: Indeed it isn't reproducible with a clean installation of OpenArena. You have to connect to a heavily modded server like Gem's InstaGib server. Playing on a modded server with auto-download turned on can replace the UI with arbitrary bytecode - for instance, a UI based on the upstream OpenArena release, which will consequently no longer have the are you sure you want to shoot yourself in the foot? prompt. If that's what's happening here, then there's no way to fix it. S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686648: ioquake3: consider disallowing auto-downloading in wheezy
On Tue, 25. Sep 15:53 Simon McVittie s...@debian.org wrote: On 25/09/12 13:44, Markus Koschany wrote: Indeed it isn't reproducible with a clean installation of OpenArena. You have to connect to a heavily modded server like Gem's InstaGib server. Playing on a modded server with auto-download turned on can replace the UI with arbitrary bytecode - for instance, a UI based on the upstream OpenArena release, which will consequently no longer have the are you sure you want to shoot yourself in the foot? prompt. If that's what's happening here, then there's no way to fix it. I think that's exactly what's happening here. The whole pak6-patch088.pk3 file gets also downloaded again. Sounds like wontfix. signature.asc Description: Digital signature
Bug#686648: ioquake3: consider disallowing auto-downloading in wheezy
Am 14.09.2012 21:38, schrieb Markus Koschany: I took the liberty to download the experimental version and i think the solution is good. The only thing i noticed was, that if cl_allowDownload was already set to 1 the warning wouldn't be visible, no matter how many times you switch between enabled and disabled. You have to restart OpenArena with auto-downloading set to 0 first and then the warning appears every time you switch between 0 to 1. Anyway i guess it's not a big deal because the warning is meant for new players. Is this intended or an oversight? I think it makes sense to always show the warning, regardless of the initial state of cl_allowDownload. - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686648: ioquake3: consider disallowing auto-downloading in wheezy
On 24/09/12 08:31, Fabian Greffrath wrote: Am 14.09.2012 21:38, schrieb Markus Koschany: if cl_allowDownload was already set to 1 the warning wouldn't be visible, no matter how many times you switch between enabled and disabled. You have to restart OpenArena with auto-downloading set to 0 first and then the warning appears every time you switch between 0 to 1. Is this intended or an oversight? Not intentional, patches welcome. Sorry, I'm not necessarily going to be able to keep chasing this; if someone else from the Games Team could take responsibility for polishing this change and getting it past the release team, I'd appreciate it. S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686648: ioquake3: consider disallowing auto-downloading in wheezy
-devel-games: this summarizes feedback from the bug, which was pretty similar to what you said: everyone wants a this is not safe, do it anyway? [Y/N] prompt, rather than knocking out cl_allowDownload altogether. Please reply to both the list and the bug. On Tue, 04 Sep 2012 at 15:42:21 +0200, Markus Koschany wrote: In practice this would force players to download custom maps and even new versions of base maps manually from more or less trustworthy servers. Yes, I do see the problem. If people are willing to download potentially-executable code from arbitrary sources, then there's nothing we can do to make them secure. It's a pity there isn't a distinction between executable and non-executable game content - if you could auto-download PK3s, but those PK3s were flagged as not to be searched for QVMs somehow, then everything would be secure - but there isn't, and realistically, this isn't going to change before wheezy. Unfortunately, some use cases for auto-downloading do rely on executing downloaded code: For example Ubuntu players are playing with version 0.8.5 at the moment and my Debian server is running 0.8.8. If cl_allowDownload was permanently disabled all players which run an older version wouldn't be able to join my server although they only had to download the pak6-patch088.pk3. As far as I can see, my proposal would not break this. Auto-downloading is possible if the server has sv_allowDownload true and the client has cl_allowDownload true: my proposal was to knock out cl_allowDownload, but leave sv_allowDownload working. Older clients could still download your pak6-patch088.pk3, but Debian clients on a future 0.9.0 server would not auto-download. If client auto-downloading was allowed but bytecode in auto-downloaded PK3s was prevented from being being executed, this use-case would still fail for updated clients, though: upstream's pak6-patch088.pk3 contains updated cgame and ui code. (Debian's doesn't, because we don't have a Free compiler for it; we run equivalent native-code game logic from the openarena package instead.) * Automatic downloading is disabled on the first start thus OpenArena is secure by default. This is already the case; the default has always been cl_allowDownload = 0. * You could also move the menu option for auto downloading to the bottom and improve the description. Warning: Enabling of auto downloading *could* lead to security implications. Worst case: Execution of arbitrary code. Please visit link to the Debian Wiki and carefully read about the alternatives *before* you enable this option. Unfortunately, the Quake 3 engine's UI toolkit is not very good at displaying significant amounts of text (it's done in a very low-res style), and the text I put in the confirmation box comes out in all-caps anyway, so the best I've been able to do so far looks like this: / Auto-download? \ \ YES/NO / WARNING: this is a security risk. More information: http://deb.li/Q3DL I've uploaded 0.8.8-7 to experimental with this change. If you (for plural values of you) can improve on this UI or the wording on the referenced wiki page, please do! The relevant code change is: http://anonscm.debian.org/gitweb/?p=pkg-games/openarena.git;a=commit;h=eed3e6469 On Tue, 04 Sep 2012 at 21:03:48 +0200, Stefan Potyra wrote: Maybe there's another measure to mitigate against some effects of malicious downloads: Can access of ioquake3 (and games using it) be restricted somehow? (apparmor or selinux comes to my mind, but I must admit that I don't have much clue with that). Not for Debian 7, and not by me, but if someone else wants to do this for Debian 8, great. (This won't protect anyone who isn't using the relevant LSM, though.) S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686648: ioquake3: consider disallowing auto-downloading in wheezy
On Fri, 14. Sep 10:47 Simon McVittie s...@debian.org wrote: [snip] It's a pity there isn't a distinction between executable and non-executable game content - if you could auto-download PK3s, but those PK3s were flagged as not to be searched for QVMs somehow, then everything would be secure - but there isn't, and realistically, this isn't going to change before wheezy. I agree. I think this should be a feature request for upstream but is nothing someone can change in Debian. [snip] For example Ubuntu players are playing with version 0.8.5 at the moment and my Debian server is running 0.8.8. If cl_allowDownload was permanently disabled all players which run an older version wouldn't be able to join my server although they only had to download the pak6-patch088.pk3. As far as I can see, my proposal would not break this. Auto-downloading is possible if the server has sv_allowDownload true and the client has cl_allowDownload true: my proposal was to knock out cl_allowDownload, but leave sv_allowDownload working. Older clients could still download your pak6-patch088.pk3, but Debian clients on a future 0.9.0 server would not auto-download. True. I already had future clients in mind. I wanted to express that, if we had had a similar situation like today, then the players would have been unable to download the pk3 file. [snip] / Auto-download? \ \ YES/NO / WARNING: this is a security risk. More information: http://deb.li/Q3DL I've uploaded 0.8.8-7 to experimental with this change. If you (for plural values of you) can improve on this UI or the wording on the referenced wiki page, please do! I took the liberty to download the experimental version and i think the solution is good. The only thing i noticed was, that if cl_allowDownload was already set to 1 the warning wouldn't be visible, no matter how many times you switch between enabled and disabled. You have to restart OpenArena with auto-downloading set to 0 first and then the warning appears every time you switch between 0 to 1. Anyway i guess it's not a big deal because the warning is meant for new players. The wiki page entry was to the point. I added a german translation, too. Regards Markus signature.asc Description: Digital signature
Bug#686648: ioquake3: consider disallowing auto-downloading in wheezy
Am 04.09.2012 15:42, schrieb Markus Koschany: * Automatic downloading is disabled on the first start thus OpenArena is secure by default. * You could also move the menu option for auto downloading to the bottom and improve the description. Warning: Enabling of auto downloading *could* lead to security implications. Worst case: Execution of arbitrary code. Please visit link to the Debian Wiki and carefully read about the alternatives *before* you enable this option. This sounds very reasonable. I am all for warning users but still leaving them in the position to shoot themselves in the foot - instead of second-guessing and disabling a feature that they might explicitely want to use, even if they are made aware of the security implications it may bring. - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686648: ioquake3: consider disallowing auto-downloading in wheezy
Package: ioquake3 Version: 1.36+svn2287-1 Severity: important Tags: patch X-Debbugs-Cc: debian-rele...@lists.debian.org X-Debbugs-Cc: debian-devel-ga...@lists.debian.org I am considering removing the cl_allowDownload option from the ioquake3 client, effectively forcing its value to disabled (further details below). The effect of this option is: * if disabled (or patched out), joining modded game servers will require users to download and install any mods active on that server manually * if enabled, mods are automatically downloaded; if certain security flaws exist in ioquake3, a malicious server operator or a man-in-the-middle could exercise those flaws (worst-case: arbitrary code execution) by encouraging users to join a game server This is basically a trade-off between convenience and mitigating security vulnerabilities. I say mitigating because a user could always install a malicious mod to ~/.q3a or ~/.openarena manually, with the same result as if they had auto-downloaded it. I am not aware of any current vulnerabilities that could be exploited in this way, but see below for a list of past vulnerabilities that would have been mitigated by this change. Games team: what are your thoughts about this? Should we give users the freedom to shoot themselves in the foot, or patch this feature out? Should we reinstate the feature in unstable after wheezy releases, or leave it out permanently? Release team: would you consider a freeze exception for this? I attach draft patches (I'd replace nn with this bug number and UNRELEASED with unstable, obviously). Only the ioquake3 one is strictly necessary, but it would leave a useless and misleading menu option in openarena, so I would prefer to patch openarena too. The next obvious revision numbers (ioquake3 1.36+svn2287-2, openarena 0.8.8-6) are already in use in experimental, so if I upload these, I'm going to version them like a stable update. Let me know if you would prefer me to use -X+wheezyY for the revision numbers rather than -X+deb70+Y, or something else entirely. S Further explanation: The ioquake3 engine is used in openarena (main/games) and quake3 (contrib/games). When used as a network client, it has the option to auto-download required data from the game server, or (as one of the ioquake3 enhancements to the Quake III Arena engine) from a HTTP or FTP server nominated by the server administrator. By design, auto-downloaded packages are not signed or authenticated (server administrators can add arbitrary mods). As well as safe data (maps, 3D models etc.), auto-downloaded packages can include executable bytecode (cgame.qvm, ui.qvm), which will be run by the client using a JIT or interpreter. The JIT/interpreter acts as a simple sandbox, and known vulnerabilities in it have been treated as security issues and fixed. To the best of my knowledge, there has not been a systematic audit. Unfortunately, it is not currently possible to auto-download safe files (maps, models, textures, music etc.) but reject executable bytecode. I hope to add that feature in time for Debian 8, and make it the default. During squeeze updates to tremulous (which uses a fork of ioquake3), I patched out auto-downloading support. I am now considering doing the same to ioquake3 itself before wheezy is released: this would mean that any vulnerabilities discovered in the bytecode JIT/interpreter would not affect wheezy. However, this would remove an apparently-intentional feature, making it harder for Debian users to join modded servers. In Quake III Arena (quake3, contrib/games) enabling client-side auto-downloading requires console commands; in OpenArena (openarena, main/games) the feature can be enabled through the GUI. In both cases it is off by default. Server administrators and gaming communities frequently encourage users to switch on this feature, apparently without considering its security implications. Here are some past Quake III Arena CVEs and whether this change would have mitigated them: affects impact mitigated by this? CVE-2001-1289 serverDoS no CVE-2005-0430 serverDoS no CVE-2005-0983 clientDoS no CVE-2006-2082 server info disclos no CVE-2006-2236 client code execno CVE-2007-2785 client code execyes CVE-2006-3324 client file write yes CVE-2006-3325 client code exec? partially? CVE-2006-3400 client code exec? no CVE-2006-3401 client code execyes? CVE-2011-1412 client code execno CVE-2011-2764 client code execyes CVE-2012-3345 both file write no -- System Information: Debian Release: wheezy/sid APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Bug#686648: ioquake3: consider disallowing auto-downloading in wheezy
Hi, i've been running an openarena server for 6 months now and although i'm just an ordinary user i wanted to share my thoughts on this bug. I agree with your conclusions and how you contrast the pros and cons. I personally could live without automatic downloading. But the question is if other players, the casual user, would see it as an improvement of security or as an unnecessary inconvenience forced on them by Debian because your change would not only affect mods but also the download of official maps. In practice this would force players to download custom maps and even new versions of base maps manually from more or less trustworthy servers. For example Ubuntu players are playing with version 0.8.5 at the moment and my Debian server is running 0.8.8. If cl_allowDownload was permanently disabled all players which run an older version wouldn't be able to join my server although they only had to download the pak6-patch088.pk3. In fact when i had disabled cl_allowDownload on the server a considerable smaller number of players joined the server. Thus disabling allowDownload on the client would very likely force these casual players to play on servers with an outdated version which would give them a false impression of the actual development of Openarena. Please consider a second alternative: * Automatic downloading is disabled on the first start thus OpenArena is secure by default. * You could also move the menu option for auto downloading to the bottom and improve the description. Warning: Enabling of auto downloading *could* lead to security implications. Worst case: Execution of arbitrary code. Please visit link to the Debian Wiki and carefully read about the alternatives *before* you enable this option. No matter which alternative you prefer please make sure that every user knows about the information on the Debian Wiki and that they are pointed to the official Debian ftp servers where they can obtain new pak files. Finally i wonder how other distributions deal with this potential security flaw and whether they would follow Debian. Then either this is a serious issue or not thus automatic downloading should be completly removed. If not then in my opinion it's better to improve the description than to walk a seperate path. Kind regards Markus Koschany signature.asc Description: Digital signature
Bug#686648: ioquake3: consider disallowing auto-downloading in wheezy
Hi, first off, big thanks to everybody involved in maintaining ioquake. You've done a great job! On Tue, Sep 04, 2012 at 03:42:21PM +0200, Markus Koschany wrote: In practice this would force players to download custom maps and even new versions of base maps manually from more or less trustworthy servers. *nod*. I doubt it'll add much to security, as people will manually dl maps from possibly untrusted servers by-hand then. Also I think it must be almost a year that I last played on the line, custom maps (and mods) were still quite widespread. Of course I may be biased, since I prefer servers with the instagib mod ;). Please consider a second alternative: * Automatic downloading is disabled on the first start thus OpenArena is secure by default. * You could also move the menu option for auto downloading to the bottom and improve the description. Warning: Enabling of auto downloading *could* lead to security implications. Worst case: Execution of arbitrary code. Please visit link to the Debian Wiki and carefully read about the alternatives *before* you enable this option. *nod*. Maybe there's another measure to mitigate against some effects of malicious downloads: Can access of ioquake3 (and games using it) be restricted somehow? (apparmor or selinux comes to my mind, but I must admit that I don't have much clue with that). Cheers, Stefan. signature.asc Description: Digital signature
