5700056 2000-11-08 15:33 +0800 /101 rader/ Christian <christian@IT.MURDOCH.EDU.AU>
Sänt av: joel@lysator.liu.se
Importerad: 2000-11-08 21:12 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: christian@IT.MURDOCH.EDU.AU
Mottagare: Bugtraq (import) <13654>
Ärende: StarOffice 5.2 Temporary Dir Vulnerability
------------------------------------------------------------
From: Christian <christian@IT.MURDOCH.EDU.AU>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20001108153353.B11281@diffie.it.murdoch.edu.au>
Hi,
A while back I noticed that StarOffice 5.2 (running under Linux and
Solaris) creates a temporary directory under /tmp with the name
"soffice.tmp" with permissions 0777. I figured there had to be some
security issue here so I had a further look and noticed that there
were files created under here called svXXXX.tmp (where XXXX is a four
or sometimes five digit number) which seemed to contain configuration
information of some sort. Now while there might be a whole bunch of
possible issues with this in terms of race conditions and symbolic
links, there actually seems to be a much easier way of attacking it.
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:
- gaining access to sensitive files (e.g., encrypted files or those
containing private keys)
- making user B's mail spool file world read/write-able
- linking to a shell start-up file (e.g., ~/.profile, ~/.bashrc,
~/.cshrc etc.) which will become world read/write-able and hence can
be modified to execute whatever user A wants next time user B logs
in.
I'm sure the black hats in the audience can think of many more.
Note that there is no race condition here, the sym link just needs to
be made before StarOffice is run by the victim. There is also no
issue in guessing the temporary directory name -- it is always
"soffice.tmp". Also, from user B's point of view, there is no
indication that anything has gone wrong. From my testing (admittedly
not extensive), StarOffice performs as usual while being attacked
giving no error message or such (i.e., for those of us on SECPROG,
it's quite reliable. ;-)
The only two restrictions I can find are that the target file must be
in a directory accessible by the attacker (otherwise it's 0777 perms
are not that useful) and the target must NOT have executable
permission set. If it does then there seems to be no effect. I
haven't tested this extensively, nor looked at the source code which
is now available apparently, so I'm not sure exactly why this is. To
be honest it's pretty baffling that someone would create a directory
with 0777 permissions, let alone the chmod() it to 0777 (thus
avoiding the effect of the umask). The only reason I can think of is
where more than one user is running StarOffice on the same machine
and since the "soffice.tmp" directory name is constant, all users had
to have access to it (obviously generating a new directory name with
a good pseudorandom number attached to the end would be a better
approach).
The impact of this vulnerability is obviously fairly minimal on a
single-user workstation system but in an environment where there is a
central server with multiple users then anyone who uses StarOffice is
at significant risk.
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.
I discovered this vulnerable several months ago and attempted to
report it to Sun. First I spent about an hour searching Sun's web
site for the appropriate place to report it or a contact email
address. I couldn't find any obvious links to information about
security (other than Sun's security products) nor any obvious place
or email address for reporting such bugs. I did a search of the site
with no appropriate results. Eventually I tried submitting the bug
via a StarOffice bug report form which, after several attempts,
finally accepted my report. Some time passed (I was very busy with
other things at the time) and there was no response. Maybe Sun's
security contact details are blindingly obvious on their web site and
I somehow missed them but their complete lack of response from anyone
from my bug feedback form posting is pretty poor. I was about to
report the problem to BUGTRAQ when I saw a post about Vendor Contacts
from SecurityFocus's Vulnhelp Team -- it's somewhat ironic that
SecurityFocus seems to be doing more to aid responsible reporting of
security problems to vendors than the vendors themselves. The
Vulnhelp team put me in contact with Brent Paulson from Sun who, to
his credit, has been helpful, interested and responsive, liaising
between myself and the StarOffice team.
Concerning a official fix, the last update I've received from Brent is:
> The fix has been checked-in to StarOffice 5.2 SP1. Patches are in the
> works for the current version (5.2) and other supported lower versions
> (5.1a) against the current supported platforms for each release (I
> believe for 5.1a they are: Linux, Solaris/SPARC, Solaris/x86, OS/2 and
> Win32. For 5.2, OS/2 was dropped.) Once the patches are available
> I'll let you know.
Regards,
Christian.
(5700056) --------------------------------(Ombruten)
Kommentar i text 5701346 av Kurt Seifried <listuser@SEIFRIED.ORG>
Kommentar i text 5701793 av Peter W <peterw@USA.NET>
5701346 2000-11-08 13:09 -0700 /42 rader/ Kurt Seifried <listuser@SEIFRIED.ORG>
Sänt av: joel@lysator.liu.se
Importerad: 2000-11-09 08:38 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: listuser@seifried.org
Mottagare: Bugtraq (import) <13665>
Kommentar till text 5700056 av Christian <christian@IT.MURDOCH.EDU.AU>
Ärende: Re: StarOffice 5.2 Temporary Dir Vulnerability
------------------------------------------------------------
From: Kurt Seifried <listuser@SEIFRIED.ORG>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <003f01c049bf$def12260$6900030a@seifried.org>
[snipsnip]
> 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:
[snipsnip]
> 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.
> Regards,
>
> Christian.
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
http://www.securityportal.com/
(5701346) --------------------------------(Ombruten)
5701793 2000-11-08 19:07 -0500 /73 rader/ Peter W <peterw@USA.NET>
Sänt av: joel@lysator.liu.se
Importerad: 2000-11-09 10:16 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: peterw@USA.NET
Mottagare: Bugtraq (import) <13673>
Kommentar till text 5700056 av Christian <christian@IT.MURDOCH.EDU.AU>
Ärende: Re: StarOffice 5.2 Temporary Dir Vulnerability
------------------------------------------------------------
From: Peter W <peterw@USA.NET>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <3A09EACD.D19122A@JunkMailForbidden.usa.net>
Christian wrote:
> A while back I noticed that StarOffice 5.2 (running under Linux and
> Solaris) creates a temporary directory under /tmp with the name
> "soffice.tmp" with permissions 0777.
Ah, our old friend /tmp. WordPerfect and VMWare had similar
problems...
> 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.
>
...and similar solutions. A better workaround is to set the
environment variable TMP to a safe alternative before running
StarOffice. If you do this, StarOffice will create the mode 0777 dir
inside $TMP. I don't know if this is documented, but it works (tested
with StarOffice 5.2 for Linux), and that's what matters. ;-)
Below is a shell script Red Hat Linux users can put in /etc/profile.d
(be sure to make it at least 0555, and use a .sh extension) to take
care of this, and similar, temp dir issues for users of sh/Bash
shells, starting the next time each user logs in. Others, source this
from your .profile or whatever, so your temp dir vars are properly
set when you log in.
Or put it in a wrapper script, but I think history has shown that
it's a good idea to set these variables so that other applications
might behave more safely, too. Search the Bugtraq archive for TMPDIR
for more cases.
IIRC, some (many? most?) other Linux distros support /etc/profile.d
scripts for sh/Bash, but YMMV.
Note that while WordPerfect 8 and VMWare respect $TMPDIR, StarOffice
uses $TMP. So my script now sets both variables, Just In Case.
Christian, thanks for the catch.
-Peter
other stuff at http://www.tux.org/~peterw/
#
# bastille-tmpdir.sh
#
# This script sets TMP/TMPDIR environment variables for some added
# safety on multi-user systems. Many applications write temporary
# files in unsafe ways to /tmp unless TMP and/or TMPDIR are set.
#
if [ -z "${TMPDIR}" ]; then
# TMPDIR is not set
TMPDIR="${HOME}/tmp"
if [ "${TMPDIR}" = /tmp ]; then
# This user's home dir is "/"? SysV-root?
TMPDIR=/tmp-root
fi
if [ ! -d "${TMPDIR}" ]; then
# We need to create the directory, with sane permisssions
mkdir -m 0700 "${TMPDIR}" 2>/dev/null && export TMPDIR \
TMP="${TMPDIR}" export TMP \
|| echo "Warning: unable to create safe TMPDIR"
else
TMP="${TMPDIR}"
export TMP
export TMPDIR
fi
fi
(5701793) --------------------------------(Ombruten)
5704809 2000-11-09 07:42 -0800 /19 rader/ Chmouel Boudjnah <chmouel@MANDRAKESOFT.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2000-11-09 21:34 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: chmouel@MANDRAKESOFT.COM
Mottagare: Bugtraq (import) <13674>
Kommentar till text 5701346 av Kurt Seifried <listuser@SEIFRIED.ORG>
Ärende: Re: StarOffice 5.2 Temporary Dir Vulnerability
------------------------------------------------------------
From: Chmouel Boudjnah <chmouel@MANDRAKESOFT.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <m3snp1179g.fsf@matrix.mandrakesoft.com>
Kurt Seifried <listuser@seifried.org> writes:
> 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).
if SECURE_TMP is defined in the /etc/sysconfig/system file.
--
MandrakeSoft Inc http://www.chmouel.org
--Chmouel
(5704809) ------------------------------------------
5704970 2000-11-08 11:35 +0100 /33 rader/ Igor Falcomata' <igor@INFOSEC.IT>
Sänt av: joel@lysator.liu.se
Importerad: 2000-11-09 21:58 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: igor@INFOSEC.IT
Mottagare: Bugtraq (import) <13676>
Kommentar till text 5700056 av Christian <christian@IT.MURDOCH.EDU.AU>
Ärende: Re: StarOffice 5.2 Temporary Dir Vulnerability
------------------------------------------------------------
From: Igor Falcomata' <igor@INFOSEC.IT>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20001108113545.H269@kppc.sikurezza.org>
On Wed, Nov 08, 2000 at 03:33:53PM +0800, Christian wrote:
> Hi,
>
> A while back I noticed that StarOffice 5.2 (running under Linux and
> Solaris) creates a temporary directory under /tmp with the name
> "soffice.tmp" with permissions 0777. I figured there had to be some
a real quick workaround is to make (as root) a "fixed"
/tmp/soffice.tmp 777
+t dir.
drwxrwxrwt 2 root root 1024 Nov 9 11:39 soffice.tmp
Note that files created by SO in this dir are still readable (but not
writable) by other users, so change the $TMP var is probabily better.
bye
Koba
--
Igor Falcomata'
IT Security Manager & Consultant
Infosec srl - www.infosec.it
Network Security and Data Defense
--
free advertising: www.openbsd.org - Multiplatform Ultra-secure OS
(5704970) --------------------------------(Ombruten)