Home page logo

bugtraq logo Bugtraq mailing list archives

Re: StarOffice 5.2 Temporary Dir Vulnerability
From: Kurt Seifried <listuser () seifried org>
Date: Wed, 8 Nov 2000 13:09:57 -0700

When StarOffice creates the /tmp/soffice.tmp directory (with explicitly
set permissions 0777), it also seems to sometimes chmod() this directory
to 0777 afterwards.  Therefore if user A were to create a symbolic link
to any file owned by user B, and if user B were to run StarOffice the
target of the link will become 0777.  As a result, if the directory
containing this target is accessible by user A, they can do whatever
they want with the target file.  Some trivially exploitable scenarios
here include:

My suggested workaround is to create a symbolic link from
/tmp/soffice.tmp to a directory inside the your home directory which
is inaccessible to anyone but yourself. Doing this before running
StarOffice would seem to protect against the vulnerability and this
could be written into a simple shell script wrapper.


On my machines /tmp is mounted noexec, so when I tried to install StarOffice 5.2
it failed (it copies files into /tmp and then execs them). Rather then remount
my /tmp I did the following:
mkdir ~/tmp
export TMP="$HOME/tmp"
Then tried to install. I almost fell off my chair when StarOffice installed
properly, it honors $TMP (I can count on my hand how many commercial programs
honor $TMP). Instead of mucking about with /tmp permissions it might be a whole
lot simpler to chuck a tmp dir into etcskel (and all existing user's dirs) and a
$TMP definition into the various shell config files (i.e. /etc/profile). I
believe Mandrake does this now (they told me they'd do it, I haven't actually
checked the latest release).

Kurt Seifried - seifried () securityportal com
SecurityPortal, your focal point for security on the net

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]