Bug 7530 - [sorcery/installwatch] insecure tmp file handling vulnerability
: [sorcery/installwatch] insecure tmp file handling vulnerability
Status: CLOSED FIXED
Product: Security
Classification: Unclassified
Component: General / Other Security Issue
: unspecified
: Other other
: P1 critical
Assigned To: SM Security List
Depends on: 7536
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-16 18:44 UTC by Clément MATHIEU
Modified: 2007-03-31 01:58 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Clément MATHIEU 2004-10-16 18:44:19 UTC
Overview : 
---------

An insecure tmp file handling vulnerability can allow an attacker to write in
any file.

Details :
--------

$ sorcery --version
20041015

vim =cast
    708   IW_LOG="/tmp/$SPELL.iw"

vim /var/lib/sorcery/modules/libtrack
     50 function invoke_installwatch()  {
     51 
     52   if  [  -e  /usr/lib/installwatch.so  ];  then
     53     export  INSTALLWATCHFILE=$IW_LOG
     54     export  LD_PRELOAD=/usr/lib/installwatch.so
     55   fi
     56 
     57 }

vim installwatch.c
    147         if((logname = getenv("INSTALLWATCHFILE"))) {
    148                 logfd = true_open(logname, O_WRONLY | O_CREAT | O_APPEND
       , 0666);

As you can see, the name of the installwatch's file is fully deterministic.
Nor sorcery nor install check if the tmp file already exist, this allow an
attacker to create a symlink to write in any file.
Comment 1 Seth Woolley 2004-10-18 11:50:12 UTC
Thanks for reporting this, we must have missed it in the last "fix kyle's bad
/tmp code" run.

I presume this is a good candidate for placing in /tmp/sorcery/ like most of the
other tmp variables, Andrew (added to CC)?

Sorry for the long wait for reply, I didn't have access to the computer all weekend.
Comment 2 Andrew Stitt 2004-10-19 00:28:28 UTC
This should be fixed with change 45229, the file now lives in a
unique /tmp/sorcery sub-directory directory which is owned by root.
/tmp/sorcery is guarenteed to be owned by root with perms 755, if it
isnt sorcery makes sure it is. The actual $TMP_DIR is guarenteed to be
created by cast with perms 755 and owned by root, if it already exists its
removed and re-created. In other words there shouldnt be any way for an
attacker to place clever symlinks in $TMP_DIR without being root.

Thanks for pointing out this class of exploits. Had I known earlier I would
have spent more time moving files to safer locations rather than taking
the "if its not broken dont fix it" approach.

Let me know if there are any weaknesses in libmisc::mk_tmp_dirs, and
if possible ways to fix it.
Comment 3 Jeremy Blosser 2007-03-31 00:58:51 UTC
closing fixed bugs