The file files/predict-update that is distributed with the sci-astronomy/predict ebuild insecurely writes to files in /tmp. If the files were to exist, or be created by a local attacker in a race condition with wget, as symlinks, arbitrary files could possibly be overwritten upon the installation of sci-astronomy/predict. wget should not be used to write to files in /tmp, and even otherwise, the existence of files in wget should be checked for existence before data is written to them.
sci please advise.
Hi Vic, Thanks for pointing this out! Unfortunately, I am not familiar with this package, but it seems that the predict-update script is provided by gentoo rather than being part of the upstream package. It was committed by phosphan, so maybe he can advise on what to do. There are two options I can think of right now to resolve this issue: (1) We add "-nc" to wget to prevent it from overwriting already existing files. (2) We remove the script altogether and provide the user with a brief set of instructions on how to update his database "by hand". If (1) would be fine and sufficient with the security folks I could do that right away. Thanks, Markus
Hi Markus, an easy way to use /tmp securely from a shellscript is like so: mkdir /tmp/predict-$$ || exit 1 cd /tmp/predict-$$ now you can use wget safely, then just rm -rf the directory when finished...the imnportant part is you _must_ abort if mkdir returns error. If you dont mind making this minor change, that would be fine from a security perspective!
Created attachment 105965 [details, diff] proposed patch to remove insecure file handling Hi Tavis, Thanks for the tip and this should work perfectly! I've attached a proposed patch for predict-update. If this looks fine to the security team I'll apply it asap and revision bump the ebuild. Thanks, Markus
@security folks: I've just bumped predict to version 2.2.3 which will pull in the updated predict-update script (see the posted patch). This should fix the insecure /tmp file handling, unless there are additional concerns with the updated version. The bumped ebuild is currently in ~amd64 and ~x86 and needs to be stabled on both arches to get the insecure version of predict-update off of user's systems. Please let me know if there's anything else you would like me to do. Thanks, Markus
thanks Markus amd64/x86, pls test predict-2.2.3 and mark stable if possible
x86 stable
amd64 stable
security please vote on glsa publication
I vote yes; there were a bunch of these packages we found, we should probably do GLSAs for all of them.
Well if we can bundle a lot of similar issues it would be fine. Otherwise I tend to vote NO.
(In reply to comment #11) > Well if we can bundle a lot of similar issues it would be fine. Otherwise I > tend to vote NO. > IMHO it should depend on the package, the severity and if the exploitation if easy. Here it's only during emerge, so i vote NO, and i close the bug. Feel free to reopen if you disagree
