The ebuilds games-rpg/eternal-lands and games-rpg/eternal-lands-data write game resources to /usr/share/games/eternal-lands/. This directories and files belong to root:games and are group-writeable, allowing members of the group 'games' to manipulate the game data files. This allows users of the group 'games' to inject malicious code in the game data files, exploiting possible vulnerabilities in the game's binary and thus executing code in the context of another user. Of course users can also simply delete the game data, killing the package. To prevent this attack vector, this files should not be group-writeable. Reproducible: Always
This was a deliberate change introduced on Jul 2 2006 by previous maintainers. I believe it was made to allow the game to auto-update. The downside would be what you mention. I'm open to comments from the games herd / QA, but I suspect that this sort of situation is fairly common with games like this. Unless somebody raises a strong objection I probably will close this WONTFIX.
i'm inclined to agree with the status quo. there are other known ways for people in the games group to be malicious. i don't think we should worry about this: it's highly unlikely you're installing these on a system that is multi-user where the users don't know each other and don't have access to the actual hardware. if someone has a realistic use case where this is an issue, we can talk about it. but this theoretical "i gave games access to someone and they punched me in the nuts" is just noise to me.
I thought the purpose of the 'games' group was to restrict the execution of games. Allowing the members of games to mess with the system looks like a bug to me. On the point of this beeing common for games: find -L /usr/share/games/ -group games -perm +0020 just turns up eternal-lands on my system. And i have quite a few games installed. Auto-update, eh? Congratulations, your local exploit just got remote. Realistic use case follows: 1. Mallory poisons Alice's DNS cache, pointing www.eternal-lands.com to Mallory's server 2. Alice starts eternal-lands, which pulls auto-updates from www.eternal-lands.com 3. Mallory's fake updates exploit a yet unknown vulnerability of the eternal-lands binary 4. Mallory has thus pwned Alice The question is if you want to bet user's systems against the probability this vulnerability has not been found yet. I fail to see the benefit in allowing the client to auto-update. There are reasons we have a package manager. One of them being checksumming. So i propose reverting the change of Jul 2 2006, losing auto-update ability and gaining checksumming on the data files, effectively increasing security for all systems which have this ebuild installed.
(In reply to comment #3) > 1. Mallory poisons Alice's DNS cache, pointing www.eternal-lands.com to > Mallory's server If you can do that a simpler solution is to just poison your cache for the gentoo rsync servers. Then when you run emerge --sync they can modify any eclass on your system. Then the next time emerge sources just about any ebuild it will execute arbitrary shell code, and if you're actually running emerge to install something that code could run as root without a sandbox. Also, if you're assuming that the game client contains vulnerabilities in parsing its data files it seems reasonable to assume that it contains vulnerabilities in parsing network traffic - making it exploitable even if its files cannot be modified. From having to debug more than one issue getting this game to build I can already tell you that it can crash due to buffer overruns when parsing log data (seems like they've not heard of strncopy). Generally speaking uncommon games are not a good place to look for strong security practices. All that said, your basic point is still a valid one. I'll take a look into this and see how important the updates are. If it turns out the feature doesn't get much use it would only make sense to disable it. I've yet to see map updates/etc posted on their website except when they've done major client releases.
