SecurityTracker.com
Keep Track of the Latest Vulnerabilities
with SecurityTracker!
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


 
Sign Up
Sign Up for Your FREE Weekly SecurityTracker E-mail Alert Summary
Instant Alerts
Buy our Premium Vulnerability Notification Service to receive customized, instant alerts
Affiliates
Put SecurityTracker Vulnerability Alerts on Your Web Site -- It's Free!
Partners
Become a Partner and License Our Database or Notification Service
Report a Bug
Report a vulnerability that you have found to SecurityTracker
bugs
@
securitytracker.com






Category:   Application (Generic)  >   OpenOffice.org Vendors:   OpenOffice.org
OpenOffice World-Readable Temporary Files Disclose Files to Local Users
SecurityTracker Alert ID:  1011205
SecurityTracker URL:  http://securitytracker.com/id/1011205
CVE Reference:   CAN-2004-0752   (Links to External Site)
Updated:  Sep 13 2004
Original Entry Date:  Sep 10 2004
Impact:   Disclosure of user information
Fix Available:  Yes  Vendor Confirmed:  Yes  Exploit Included:  Yes  
Version(s): 1.1.2
Description:   A vulnerability was reported in OpenOffice. A local user may be able to obtain documents belonging to another local user.

pmladek reported that the software uses insecure temporary files. When started, OpenOffice creates a world-readable temporary directory ('/tmp/sv<RAND>.tmp'). When an OpenOffice file is saved, a compressed version (zip file) is saved in the temporary directory.

A local user can access the temporary directory and obtain the file.

The vendor was notified on August 17, 2004.

Carsten Eiram of Secunia is credited with discovering this flaw.

Impact:   A local user can obtain information belonging to another local user.
Solution:   The vendor has issued a fix, available via CVS.
Vendor URL:  www.openoffice.org/issues/show_bug.cgi?id=33357 (Links to External Site)
Cause:   Access control error, State error
Underlying OS:   Linux (Any), UNIX (Any)

Message History:   This archive entry has one or more follow-up message(s) listed below.
Sep 10 2004 (Sun Issues Fix for StarOffice) OpenOffice World-Readable Temporary Files Disclose Files to Local Users
Sun has issued a fix for StarOffice.
Sep 16 2004 (Red Hat Issues Fix for RHEL) OpenOffice World-Readable Temporary Files Disclose Files to Local Users   (bugzilla@redhat.com)
Red Hat has released a fix for Red Hat Enterprise Linux 3.
Sep 28 2004 (Mandrake Issues Fix) OpenOffice World-Readable Temporary Files Disclose Files to Local Users   (Mandrake Linux Security Team <security@linux-mandrake.com>)
Mandrake has released a fix.
Oct 21 2004 (Gentoo Issues Fix) OpenOffice World-Readable Temporary Files Disclose Files to Local Users   (Thierry Carrez <koon@gentoo.org>)
Gentoo has released a fix.



 Source Message Contents

Date:  Thu, 9 Sep 2004 23:52:18 -0400
Subject:  http://www.openoffice.org/issues/show_bug.cgi?id=33357


Reporter: pmladek
OS:  Linux
Version:  OOo 1.1.2
Summary:  Insecure permissions on temporary files at runtime

When OOo is started, a directory /tmp/sv<RAND>.tmp is created, where
RAND is a 3 character random string. 

The permissions of this directory allow other users (depending on the user's
umask) to 'cd' to this directory and list the contents.

Once a file is saved, a zipped file is created in /tmp/sv<RAND>.tmp and the
name of the file follows the same convention. The permissions of the file
allow others (depending on the user's umask) to read the content.

Due to this any user can grab sensitive information of someother user.

Steps to reproduce the problem:
1. Launch OpenOffice.
2. List /tmp contents. Locate the directory 'sv*.tmp'
3. Type in some contents in the document and save it.
4. List the contents of the directory /tmp/sv*.tmp/
5. Do not close OpenOffice. 'su' to a different user.
6. Copy the file under /tmp/sv*.tmp/ to home directory.
7. Use 'unzip' to unzip the files.
8. The file content.xml holds the data the user had just saved.

The workaround is to set more secure umask. The problem is that the users does
not know about it. Why should they need to set more strict umask if they save
its data in a directory which has the correct permissions. They do not expect
that there are any world-readable temporary data available somewhere on the system.
 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

Copyright 2013, SecurityGlobal.net LLC