Bugzilla – Bug 59034
VUL-0: CVE-2004-0752: OpenOffice Insecure Temporary File Creation
Last modified: 2021-10-02 09:52:36 UTC
Looks like we are vulnerable too. Is a workaround possible, e.g. by setting TMPDIR to ~ or something like that? Date: Wed, 18 Aug 2004 11:32:57 -0400 From: Josh Bressers <bressers@redhat.com> To: vendor-sec@lst.de Subject: [vendor-sec] Forwarded message regarding openoffice.org X-Spam-Level: The Red Hat Security Team got this mail yesterday, after further communication with secunia, they're unsure if this will affect other vendors. I'm forwarding this so everyone can verify if it affects you or not. If it does affect you, please let Carsten know. This issue has been assigned CAN-2004-0752. ------- Forwarded Message Date: Tue, 17 Aug 2004 11:42:14 +0200 From: "Carsten H. Eiram" <che@secunia.com> To: secalert@redhat.com cc: vuln@secunia.com Subject: SA12302: Fedora OpenOffice Insecure Temporary File Creation Hi, Secunia Research has discovered a vulnerability in the OpenOffice implementation on Fedora Core 1 and Fedora Core 2, which potentially can be exploited by malicious, local users to gain knowledge of sensitive information. Default installs create temporary OpenOffice documents with insecure permissions ("664" or "644" depending on the user's umask) in the "/tmp" folder. Example: /tmp/svelj.tmp/svemm.tmp (The temporary folders and files are always named "sv???.tmp"). Successful exploitation allows an unprivileged user to read arbitrary users' currently open documents. NOTE: We also tested the issue on Red Hat Enterprise Linux WS 3 and confirmed that the temporary files are created properly in users' own folders. This has been reserved as Secunia Advisory SA12302. The advisory will of course be held back until you have a fix ready, if you so desire. You are welcome to contact me, if you require further information. - -- Med venlig hilsen / Kind regards Carsten H. Eiram, RHCE IT Security Specialist Secunia Toldbodgade 37B DK-1253 Copenhagen K Denmark Phone +45 7020 5144 Fax +45 7020 5145 ------- End of Forwarded Message
I can confirm the behaviour and will look at it.
The workaround would be to set the variable TEMP to any existing directory. For example, if it is set to TEMP=$HOME the temporary files looks like $HOME/sv7i0.tmp/sv7i2.tmp
Very good :-) I'd vote for not pushing out an update for this monster package then but rather explain the workaround in an advisory. Judging from the mail cited above, setting the umask is another workaround. Someone who wants his files private should have 077 anyways.
Hmm, I have made some more detailed investigation in the OOo sources. Unforunatelly, the temporary files/directories are not created only at one place. The temporary directory can by changed by the environment variables TEMP and TMP on almost all places. TEMP is usually preferred over TMP but in installation/setup2/mow/source/loader/loader.c TMP is preferred over TEMP. One exception is in gsl/psprint/source/printergfx/printerjob.cxx where only the variable TMPDIR can be used to change the temporary spool directory. Another exception is in porting/sal/osl/unx/signal.c where /tmp is hardcoded and cannot be changed at runtime. This path is used to complete informations for ReportCrash. So, in this case the informations about stack, ... are visible. There might be some other specific cases but they are related to the OOo build tools which are used only at the build time and are not packaged. I didn't investigate this parts. Another problem is that that the temporary directories and files are not created in a save way. First, an unique file name is created. Then the directory is created by mkdir. So, mktemp is not used. Result: 1. Environment variables TEMP, TMP, TMPDIR solves almost all situations except the one when data for ReportCrash are created. They solves also the problem with the insecure way of creating temporary files and directories. 2. umask solves the situation with ReportCrash. It does not help to solve the insecure way of creating files. It impacts also permissions of normal files created by OOo. So, some users would complain.
Thanks for the Analysis. Can you fix the cases where sensitive information is stored word readable for STABLE? Wrt mkdir, mkdir fails if the directory already exists. So it's ok as long as the directory is not used when mkdir failed.
It seems that mkdir is really used the safe way. BTW: The most problematic temporary directory where the actually edited documents are stored can be also changed in the OOo menu Tools/Options/OpenOffice.org/Paths/Temporary Files. Unfortunatelly, this temporary path does not affect the path used for printing spool and for crash report where /tmp is still used. Even this path is set to $HOME/OpenOffice.org/user/temp in OOo, version 1.0.x by default. So, the situation is better at SL 8.2 and former releases. OK, I'll fix it for STABLE.
It's fixed in STABLE now (The Ximian's guys did the patch). I'll reassign the bug to the security team becase they will create an advisory for older releases.
apparently the disclosure date for this was set to October 15 and it got leaked through our bugreport towards OpenOffice. We need to take care that such things don't happen ;)
we mentioned this in an advisory, so close. (http://www.suse.de/de/security/2004_31_cups.html)
CVE-2004-0752: CVSS v2 Base Score: 2.1 (AV:L/AC:L/Au:N/C:P/I:N/A:N)