||Home : Advisories : StarOffice 5.2 Temporary Dir Vulnerability|
||StarOffice 5.2 Temporary Dir Vulnerability
||8th November 2000
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
- 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
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
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.