It was reported [1] that the rocksndiamonds game would create it's configuration/cache directory (~/.rocksndiamonds/) as world-writable. If a user's home directory was mode 0755 (the default is 0700), a local attacker could delete one of the cache files and replace it with a symbolic link to some other file they did not have access to. When the victim loaded the game again, that file would be overwritten. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651620
Created rocksndiamonds tracking bugs for this issue Affects: fedora-all [bug 766810]
this issue has been assigned CVE-2011-4606 http://seclists.org/oss-sec/2011/q4/498
Created attachment 545893 [details] Patch to resolve directory security issue I believe this patch will resolve the security concern, although, I'd like for someone on the Red Hat Security team to double-check my work before I send it upstream and kick off Fedora builds.
(In reply to comment #3) > Created attachment 545893 [details] > Patch to resolve directory security issue At a quick glance, I'm not sure it will. Shouldn't there be another else in there? If we're not running setgid, then we're testing for permissions_class (no idea what it's set to), but what if that fails? There's no "else" there if that test fails. I don't have time at the moment to look at the patch in context; I suppose sending it upstream for peer review might be best and if they have something better/different, we can use what they have (this is a pretty low-impact issue, so I don't think we need to rush it -- I'd rather upstream review the whole thing first (I don't even know if they've been made aware of it)).
So, the context for that code is this (in english): If the code is running setgid, then, be sure to set the umask appropriately. Else (it is not setgid) then, force world writeable permissions (+w) in addition to DIR_PERMS_PRIVATE (0700) I changed it to this: If the code is running setgid, then, be sure to set the umask appropriately. Else (it is not setgid) If the directory is explicitly supposed to be created as a public directory then and only then, force world writeable permissions (+w) in addition to DIR_PERMS_PUBLIC(0755) (because that is set whenever a directory is created as a public directory) When the directory is explicitly supposed to be created as a private directory (which the user ~/.rocksndiamonds directory is already set as), it passes through createDirectory() with DIR_PERMS_PRIVATE. It is possible that there is still a security concern in the setgid case, but since we don't run that way for obvious reasons, I don't lose sleep here. I'll send it upstream for more feedback.
Oh, so the default then is for the directories to be created 0700? In that case, I think the patch looks fine. Thanks for taking the time to explain the context.
Yes, unless you tell createDirectory() that you're making a "Public Directory" (permission_class == PERMS_PUBLIC). Which it never does for the ~/.rocksndiamonds dir.
Makes sense. Thanks!
rocksndiamonds-3.3.0.1-5.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
rocksndiamonds-3.3.0.1-5.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.