Bugzilla Bug 160130

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 an attachment (id=105965) [edit]
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