Bug 41253

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