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.