Hello, I recently packaged this cool game Rocks'n'Diamonds on openSUSE: https://build.opensuse.org/package/show ... sndiamonds
and noticed that the package comes with a patch to address an old security issue : https://cve.mitre.org/cgi-bin/cvename.c ... =2011-4606
May I ask if there's a chance to include the patch directly in the upstream source code ? I guess that would be beneficial for everyone.
Many thanks
Patch proposal to fix an old CVE
Moderators: Flumminator, Zomis
Re: Patch proposal to fix an old CVE
i always wondered who is that mysterious "attacker" on my home PC, and how he managed to get there. actually, if i have that "attacker" active, RnD wrong access rights on fresh config dir would be the tiniest of my problems…
Re: Patch proposal to fix an old CVE
Kedmar, I know you wrote in a semi-humorous way, but please can you explain a little bit to what you are referring to, for those of us with little aptitude or practical knowledge in PC security? Is this just a Linux thing? (I only use Windows).
Re: Patch proposal to fix an old CVE
the mentioned "CVE" is totally non-issue (as most CVEs, actually). to somehow use it, the attacker should already have at least partial control over your PC — and if the attacker is already there… all bets are off.
tl;dr: not a bug. not a vulnerability. just some "security people" scoring points. safe to ignore. also, it affects only *nix-like systems, windows is not affected.
let me use the car analogy to explain it better. the report is: "the attacker can replace the tire on your car without authorisation". which doesn't matter at all, because if the attacker already has access to your car, he can do anything he want: break steering system, poison the fuel, plant an explosive… protecting tires is the last thing you should care about in this case.
tl;dr: not a bug. not a vulnerability. just some "security people" scoring points. safe to ignore. also, it affects only *nix-like systems, windows is not affected.
let me use the car analogy to explain it better. the report is: "the attacker can replace the tire on your car without authorisation". which doesn't matter at all, because if the attacker already has access to your car, he can do anything he want: break steering system, poison the fuel, plant an explosive… protecting tires is the last thing you should care about in this case.
Last edited by ketmar on Tue Nov 04, 2025 7:36 am, edited 5 times in total.
Re: Patch proposal to fix an old CVE
First of all: Thanks for bumping this thread, ketmar!
Because, apparently I have totally missed it when it was posted in 2023!
With today's view on PCs running R'n'D, you are mostly right of course.
But R'n'D is a game that was first released in 1995, a time when multi-user systems were still common. That is, we're speaking of a time when the "/home" directory may have contained more than only your own user, but maybe several others which also had access to that same system. Those maybe being not some of your family members (also having access to your home PC), but some other students at your university sharing the same, shared computer in a computer room with several shared computers for many people to use.
And still today, there's nothing wrong with a Linux PC with several accounts on it (while today they most likely are used by some other family members, as mentioned).
And as there was no central high score server back then, the only way to compete against other players locally was to have a central scores directory on your computer accessible by all local users. And yes, this theoretically opens the vulnerability described in that CVE, as you can create a symlink to another user's file. But this only works if R'n'D has more access rights when running as you have by yourself (else R'n'D cannot access any files of other users).
Since R'n'D uses its central high score server, support for local (world-writable) scores directories has been removed (see corresponding commit), and all files and directories are now created with private access permissions only, so the issue described in the above CVE does not exist anymore. (And this also means that the proposed patch is not needed anymore -- which, BTW, did not work correctly anyway, because if you take a closer look at it, you can see that it further restricts read (r) and execute (x) permission bits, but not write (w) permissions, which were already set to "private" before.)
Because, apparently I have totally missed it when it was posted in 2023!
Yes and no.the mentioned "CVE" is totally non-issue (as most CVEs, actually). to somehow use it, the attacker should already have at least partial control over your PC — and if the attacker is already there… all bets are off.
With today's view on PCs running R'n'D, you are mostly right of course.
But R'n'D is a game that was first released in 1995, a time when multi-user systems were still common. That is, we're speaking of a time when the "/home" directory may have contained more than only your own user, but maybe several others which also had access to that same system. Those maybe being not some of your family members (also having access to your home PC), but some other students at your university sharing the same, shared computer in a computer room with several shared computers for many people to use.
And still today, there's nothing wrong with a Linux PC with several accounts on it (while today they most likely are used by some other family members, as mentioned).
And as there was no central high score server back then, the only way to compete against other players locally was to have a central scores directory on your computer accessible by all local users. And yes, this theoretically opens the vulnerability described in that CVE, as you can create a symlink to another user's file. But this only works if R'n'D has more access rights when running as you have by yourself (else R'n'D cannot access any files of other users).
Since R'n'D uses its central high score server, support for local (world-writable) scores directories has been removed (see corresponding commit), and all files and directories are now created with private access permissions only, so the issue described in the above CVE does not exist anymore. (And this also means that the proposed patch is not needed anymore -- which, BTW, did not work correctly anyway, because if you take a closer look at it, you can see that it further restricts read (r) and execute (x) permission bits, but not write (w) permissions, which were already set to "private" before.)
Re: Patch proposal to fix an old CVE
yes, i understand that it was a historical artefact; and you're right assuming that i was talking from the today's PoV. i haven't checked if it was already fixed in the current code or not, just read enough of the discussion to notice that it is one of those "vulnerabilities" which is not a vulnerability at all.
but even in Good Old Days of real multiuser stations, this "vulnerability" was not something to worry about. i doubt that anybody will install RnD as root SUID binary, and without that the "attacker" could only write to the places where he could write without jumping through symlink hoops.
this matches your analysis too, and that's why i was openly sarcastic about this "bug". but the problem is that many people don't have enough knowledge to distinguish real threat from fake "vulnerabilities", and some other people love to use that to create FUD. this is something i really hate, because at the end of the day people will simply stop caring about any vulnerabilities at all, 'cause there are too much of them, and many of them are fake. this is kind of red flag for me, so couldn't kept silence. ;-)
but even in Good Old Days of real multiuser stations, this "vulnerability" was not something to worry about. i doubt that anybody will install RnD as root SUID binary, and without that the "attacker" could only write to the places where he could write without jumping through symlink hoops.
this matches your analysis too, and that's why i was openly sarcastic about this "bug". but the problem is that many people don't have enough knowledge to distinguish real threat from fake "vulnerabilities", and some other people love to use that to create FUD. this is something i really hate, because at the end of the day people will simply stop caring about any vulnerabilities at all, 'cause there are too much of them, and many of them are fake. this is kind of red flag for me, so couldn't kept silence. ;-)
Re: Patch proposal to fix an old CVE
The original CVE includes links to other things including https://bugs.debian.org/cgi-bin/bugrepo ... bug=651620 -- which, if the facts it claims are correct, was talking about a real and actual security concern.
It says that RnD, back then (and as built and packaged in Debian) created the user's ~/.rocksndiamonds directory *world writable*. The attack would look something like:
1. user A runs RnD, thus creating world-writable ~A/.rocksndiamonds
2. user B notices this and runs: `cd ~A/.rocksndiamonds; rm -f stdout.txt; ln -s ~A/important/file/dissertation.txt stdout.txt`
3. next time user A runs RnD, they overwrite their dissertation
I happen to be running a really old system, and /usr/games/rocksndiamonds is version 3.3.1.2 [2014-06-23]. Moving aside ~/.rocksndiamonds, then running it -- it created 6 world-everything (777) directories:
~/.rocksndiamonds
~/.rocksndiamonds/cache
~/.rocksndiamonds/levels
~/.rocksndiamonds/levelsetup
~/.rocksndiamonds/levelsetup/rnd_tutorial_niko_boehm
~/.rocksndiamonds/levels/filbo
I then blew away ~/.rocksndiamonds and ran my (not very new) current build, 4.3.8.2 [2024-02-18] -- and everything it created was 755 (reasonable). Then I blew it away again, ran `umask 0; ./rocksndiamonds`, and -- all directories are 755 (stricter than I was asking for). The only regular files created were serversetup.conf (644) and rocksndiamonds.log (666) -- an odd mix of outcomes...
It says that RnD, back then (and as built and packaged in Debian) created the user's ~/.rocksndiamonds directory *world writable*. The attack would look something like:
1. user A runs RnD, thus creating world-writable ~A/.rocksndiamonds
2. user B notices this and runs: `cd ~A/.rocksndiamonds; rm -f stdout.txt; ln -s ~A/important/file/dissertation.txt stdout.txt`
3. next time user A runs RnD, they overwrite their dissertation
I happen to be running a really old system, and /usr/games/rocksndiamonds is version 3.3.1.2 [2014-06-23]. Moving aside ~/.rocksndiamonds, then running it -- it created 6 world-everything (777) directories:
~/.rocksndiamonds
~/.rocksndiamonds/cache
~/.rocksndiamonds/levels
~/.rocksndiamonds/levelsetup
~/.rocksndiamonds/levelsetup/rnd_tutorial_niko_boehm
~/.rocksndiamonds/levels/filbo
I then blew away ~/.rocksndiamonds and ran my (not very new) current build, 4.3.8.2 [2024-02-18] -- and everything it created was 755 (reasonable). Then I blew it away again, ran `umask 0; ./rocksndiamonds`, and -- all directories are 755 (stricter than I was asking for). The only regular files created were serversetup.conf (644) and rocksndiamonds.log (666) -- an odd mix of outcomes...
Re: Patch proposal to fix an old CVE
Argh, I didn't actually state the point of the security issue.
It is not a security issue against the *system* one is running on, but against the *person* running RnD. It doesn't let an attacker attack system files, only the files of the person playing the game. Still, we don't want to play a game and have it delete our dissertation.
It is not a security issue against the *system* one is running on, but against the *person* running RnD. It doesn't let an attacker attack system files, only the files of the person playing the game. Still, we don't want to play a game and have it delete our dissertation.
Re: Patch proposal to fix an old CVE
it is already fixed in the new RnD versions, but still… for old versions, the attacker had to somehow know what files are in the victim's home. the victim should have never made any backups of their important work. of course, both things are possible, but i'd say that the attack is "mostly harmless".
sysadmin should fail to setup the system to make weekly backups. the user should fail to make the backups of important files. the system should be misconfigured, allowing world access to users home dirs (for reading, to find the file to make a link to). it means that the system is already FUBARed, and no additional safeguards in RnD could help.
and RnD behaviour was not even a bug: everything worked as intended. using world-writeable files was quite a common way to share high-score tables back then. and on single-user PCs it is a non-issue at all.
so while the "attack" is definitely possible, i wouldn't call it a "vulnerability". and that's why i think that the current approach to security is totally wrong: instead of edutating the users, "security experts" demand "absolute protection", which is impossible. classifying everything as "vulnerability" lowers signal-to-noise ratio, and makes real vulnerabilities mostly indistinguishable from the fake ones.
the key to proper security is user education, it cannot be solved by mere techincal methods, at least not without making our computers barely usable. that's why we still have successfull trojans, keyloggers, cryptors and such despite the combined efforts of multi-billion dollar AV industry. user is sill the weakest point, and this cannot be programmatically fixed.
sysadmin should fail to setup the system to make weekly backups. the user should fail to make the backups of important files. the system should be misconfigured, allowing world access to users home dirs (for reading, to find the file to make a link to). it means that the system is already FUBARed, and no additional safeguards in RnD could help.
and RnD behaviour was not even a bug: everything worked as intended. using world-writeable files was quite a common way to share high-score tables back then. and on single-user PCs it is a non-issue at all.
so while the "attack" is definitely possible, i wouldn't call it a "vulnerability". and that's why i think that the current approach to security is totally wrong: instead of edutating the users, "security experts" demand "absolute protection", which is impossible. classifying everything as "vulnerability" lowers signal-to-noise ratio, and makes real vulnerabilities mostly indistinguishable from the fake ones.
the key to proper security is user education, it cannot be solved by mere techincal methods, at least not without making our computers barely usable. that's why we still have successfull trojans, keyloggers, cryptors and such despite the combined efforts of multi-billion dollar AV industry. user is sill the weakest point, and this cannot be programmatically fixed.
Re: Patch proposal to fix an old CVE
Hmmm, we will probably end up having to 'agree to disagree' on this.
I say, an app should *not* create and then use world-modifiable directories in one's home directory. You say 'the system was already screwed up', but -- if you look at any real-world computer security breach, it is made up of a chain of small steps facilitated by various programs that (often) nobody thought were important to security. The real world is *FULL* of systems which have all sorts of small problems. Programs which help an attacker make those small problems into big problems, are problematic.
I gave the example of overwriting the victim's dissertation. But it could be used to overwrite any file that user had write access to; including, for instance, their login files (.profile etc.) It would not be too difficult to make that into a way to *steal* such an account (i.e., install a backdoor such that the attacker is now able to login as that user, perhaps sniff their communications, steal their passwords, things like that). Those can then be quickly promoted into taking over the whole system, attacking other attached systems, and so on.
Yes, it's already fixed, and rightly so. You seem to be saying that it's no big deal, that Holger need not even have bothered to fix it. I'm pretty sure he would strongly disagree with that...
I say, an app should *not* create and then use world-modifiable directories in one's home directory. You say 'the system was already screwed up', but -- if you look at any real-world computer security breach, it is made up of a chain of small steps facilitated by various programs that (often) nobody thought were important to security. The real world is *FULL* of systems which have all sorts of small problems. Programs which help an attacker make those small problems into big problems, are problematic.
I gave the example of overwriting the victim's dissertation. But it could be used to overwrite any file that user had write access to; including, for instance, their login files (.profile etc.) It would not be too difficult to make that into a way to *steal* such an account (i.e., install a backdoor such that the attacker is now able to login as that user, perhaps sniff their communications, steal their passwords, things like that). Those can then be quickly promoted into taking over the whole system, attacking other attached systems, and so on.
Yes, it's already fixed, and rightly so. You seem to be saying that it's no big deal, that Holger need not even have bothered to fix it. I'm pretty sure he would strongly disagree with that...
Re: Patch proposal to fix an old CVE
Although this is really a discussion about an issue not existing anymore in R'n'D for a long time, I would like to add some comments to it. 
Regarding the security state of R'n'D 3.3.1.2 (as of 2013/2014): Thanks, filbo, for your tests and observations. However, I am surprised about your findings! It seems to me as if that Debian R'n'D binary (/usr/games/rocksndiamonds) was the result of modifications that were not part of the original source code of that version. Looking at commit 07e47c9c, there's only one single directory that is created with world-writable permissions, and that's the scores directory:
As sub-directories are created recursively, the "common data" directory is interesting here:
... and "options.rw_base_directory" (after a few redirections) is set to "RW_GAME_DIR", which is defined in the top-level Makefile:
So this should be outside the user's home directory.
Unfortunately, I wasn't able to build R'n'D from the 3.3.1.2 source code on my M3 Mac, so I cannot test how the "vanilla" code really behaves in that regard.
UPDATE 1: The (world-writable) "scores" directory will then be created inside the user's home directory (using "." for "RW_GAME_DIR" somewhere in the user's home directory tree), which indeed opens the vulnerability as described in the CVE! But I wonder why this have happened with the Debian build (also setting many other directories to "world-writable"), as a global scores directory has to be defined at a global, non-user related position in the file system in this case.
UPDATE 2: I just downloaded and tested pre-build R'n'D 3.3.1.2 for the Mac (from https://www.artsoft.org/RELEASES/mac/rocksndiamonds/). Although it refuses to run correctly on my current Mac, it did create the directories with 777 permissions as described by filbo!
So yes, this old version has the security problem as described in the CVE, and I am happy to know that the corresponding code has been fixed long ago to prevent this critical vulnerability.
But I would just like to strongly emphasize here that R'n'D-related security issues are really important to me, and that I will try hard to make R'n'D behave correctly from a security perspective.
So if you should find anything that should be fixed in R'n'D in that regard, I am always interested and willing to sort such things out as soon as possible.
Having regular backups of all your stuff available is always a good idea anyway, of course.
I strongly agree here, and that's why I do take CVEs like the above seriously, and try to make R'n'D as secure as possible.an app should *not* create and then use world-modifiable directories in one's home directory
Regarding the security state of R'n'D 3.3.1.2 (as of 2013/2014): Thanks, filbo, for your tests and observations. However, I am surprised about your findings! It seems to me as if that Debian R'n'D binary (/usr/games/rocksndiamonds) was the result of modifications that were not part of the original source code of that version. Looking at commit 07e47c9c, there's only one single directory that is created with world-writable permissions, and that's the scores directory:
Code: Select all
void InitScoreDirectory(char *level_subdir)
{
createDirectory(getCommonDataDir(), "common data", PERMS_PUBLIC);
createDirectory(getScoreDir(NULL), "main score", PERMS_PUBLIC);
createDirectory(getScoreDir(level_subdir), "level score", PERMS_PUBLIC);
}Code: Select all
char *getCommonDataDir(void)
{
static char *common_data_dir = NULL;
#if defined(PLATFORM_WIN32)
...
#else
if (common_data_dir == NULL)
common_data_dir = options.rw_base_directory;
#endif
return common_data_dir;
}Code: Select all
# directory for read-only game data (like graphics, sounds, levels)
# default is '.' to be able to run program without installation
# RO_GAME_DIR = /usr/games
# use the following setting for Debian / Ubuntu installations:
# RO_GAME_DIR = /usr/share/games/rocksndiamonds
# directory for writable game data (like highscore files)
# default is '.' to be able to run program without installation
# RW_GAME_DIR = /var/games
# use the following setting for Debian / Ubuntu installations:
# RW_GAME_DIR = /var/games/rocksndiamonds
Unfortunately, I wasn't able to build R'n'D from the 3.3.1.2 source code on my M3 Mac, so I cannot test how the "vanilla" code really behaves in that regard.
UPDATE 1: The (world-writable) "scores" directory will then be created inside the user's home directory (using "." for "RW_GAME_DIR" somewhere in the user's home directory tree), which indeed opens the vulnerability as described in the CVE! But I wonder why this have happened with the Debian build (also setting many other directories to "world-writable"), as a global scores directory has to be defined at a global, non-user related position in the file system in this case.
UPDATE 2: I just downloaded and tested pre-build R'n'D 3.3.1.2 for the Mac (from https://www.artsoft.org/RELEASES/mac/rocksndiamonds/). Although it refuses to run correctly on my current Mac, it did create the directories with 777 permissions as described by filbo!
So yes, this old version has the security problem as described in the CVE, and I am happy to know that the corresponding code has been fixed long ago to prevent this critical vulnerability.But I would just like to strongly emphasize here that R'n'D-related security issues are really important to me, and that I will try hard to make R'n'D behave correctly from a security perspective.
So if you should find anything that should be fixed in R'n'D in that regard, I am always interested and willing to sort such things out as soon as possible.
Having regular backups of all your stuff available is always a good idea anyway, of course.
Re: Patch proposal to fix an old CVE
UPDATE 3: This part of the code in 3.3.1.2 caused the described problem with insecure permissions:
Very nasty, and fixed in 2017 by this commit.
And this bug was not fixed by the patch related to the above CVE...
Code: Select all
void createDirectory(char *dir, char *text, int permission_class)
{
...
if (running_setgid)
posix_umask(last_umask & group_umask);
else
dir_mode |= MODE_W_ALL;
...
}
And this bug was not fixed by the patch related to the above CVE...
Re: Patch proposal to fix an old CVE
Given the commit you pointed to, your previous comment of:
was actually wildly off the mark! So I am amused and mildly surprised. Other than that, all is well :)Looking at commit 07e47c9c, there's only one single directory that is created with world-writable permissions, and that's the scores directory: