Reproducible: Always Steps to Reproduce: 1. cd /tmp 2. ln -sf ~/.bashrc analogtv.size 3. start /usr/lib/xscreensaver/xanalogtv 4. log out 5. log in Actual Results: bogus .bashrc Expected Results: corrupting files should not be made that easy
Created attachment 25561 [details, diff] removes the part where "/tmp/analogtv.size" is written grepping through the code i found only one place where this file is touched. that's when something is written into. the program doesn't seem to open this file another time and the data is never read. so this patch removes the file-writing part and it seems to work. i only tested this patch on the standalone-hacks, not with the xscreensaver-configuration window.
This surely seems to be your standard symlink . I'm a little nervous about adding this patch without any type of testing being done. I would prefer if somebody could touch base with the people that coded analogtv portion of xscreensaver and confirm that said section of code was only used for their own DEBUGGING or whatever. Till then how do the rest of us feel? package.mask xscreensaver all together or #ifdef WANT_BUGGY_LINK_CODE our way around the code in question or simply use the patch as provided by plasmagunman?
i already sent this patch to the xscreensaver-coder. actually i don't know if he did the xanalogtv-part. anyway, i didn't receive any answer yet, but will inform you when i get some.
i don't think this is serious enough to warrant a hard mask right now. we could disable the analogtv hack until we get a suitable patch from the maintainers. i'm just not qualified or have the time to audit the creation of files and symlink type attacks. if that is sufficient, then i'll prepare a -r1 that has the analogtv hack disabled.
<rant> Okay, since nobody really seems to know what /tmp symlink attack means, here's a clue: it means that any user with write access to /tmp can corrupt arbritary files owned by any other user. And no, hardmasking won't do anything because it will not change already installed base. I don't want to sound impolite, but this still an issue after one week seems very weak. Hello, gentoo enterprise! </rant>
thanks for the useless rant.
i find it ridiculous that the reporter has just ranted about nothing being done, yet did not help us with providing a patch or analysing the problem. a clear flamebait in my book. thanks to plasmagunman, who provided us with a patch and also contacted the author, i've committed xscreensaver-4.14-r2 that removes the creation of the symlink. and masked all the older xscreensaver versions. security team, what else do we need to do? plasmagunman, did jwz respond to the patch you submitted to him?
no response yet. it's strange, once i had a problem with opengl and my graphics-card and i got an answer after 10 minutes. perhaps he's on vacation..?
before i get shafted for my mistake, i meant i removed the creation of the temporary file that could possibly be used in a symlink attack.
Sorry sorry sorry! And a thank you to plasmagunman from me too. But I thought since patch was already provided and it is clear offending file is only used for debugging, no further analysis is required. Issue here is, no action after problem is public for one week can cause massive data loss and I'm feeling very uncomfortable for this report already. I'll be quiet now.
anybody wants to close this bug? i don't think i can do that, must be the reporter or a developer, no?
Old bug, apparently still needs to be closed