Apache OpenOffice (AOO) Bugzilla – Issue 51501
OpenOffice can compromise people's privacy by putting UUIDs that reveal their ethernet addresses into documents
Last modified: 2007-02-05 13:33:00 UTC
Openoffice generates and discloses UUIDs in a way that can reveal the ethernet address of the computer used to generate the document. UUIDs (Universally Unique IDentifiers) are commonly used to provide unique names for things. See more at http://en.wikipedia.org/wiki/Universally_Unique_Identifier. Microsoft got bad publicity in 1999 for publishing ethernet addresses in Word documents via UUIDs (GUIDs for them) as described at http://www.cnn.com/TECH/computing/9903/08/microsoft.privacy.02/index.html and http://en.wikipedia.org/wiki/Globally_Unique_Identifier They responded by changing to random UUIDs. Now OpenOffice is doing the same thing. One example is the "Id" attribute of the Signature element in the META-INF/documentsignatures.xml file that contains document signatures inside Writer ".odt" documents generated by recent OpenOffice 2.0 snapshots. I've verified that on my Ubuntu 5.04 Linux machine running 1.9.87, my ethernet address showed up in a document I signed, and since the code looks like it would do the same thing again, I haven't waited to confirm it on a more recent build. (I assume I don't have to explain that even signed documents shouldn't generally reveal their host addresses). Since there are hundreds of places in the code where the rtl_createUuid function is told to include an ethernet address, I assume they show up in other places also. I don't know if this is a problem for OpenOffice version 1. I suspect the best way to fix this is by just using random UUIDs (version 4) like Microsoft seems to do now in their GUIDs. Search for lines of code that put ethernet addresses in freshly generated UUIDs: http://go-ooo.org/lxr/search?filestring=&advanced=1&string=rtl_createUuid.*+sal_True
Reassigned to ES.
reassigned to mt please take a look on this issue
Hi, tried to reproduce but was not able to find my MAC address in the mentioned XML file. I've used internal m114 to test. Frank BTW changed component to framework as all application are involved if this problem exists.
Created attachment 27769 [details] META-INF/documentsignatures.xml file extracted from signed .odt file
Sorry I didn't document it step by step - it is indeed obscure. Now I've added an attachment. It includes six "ID" values, all of which are nonstandard encodings of the UUIDs in question (4 unique ones). The bytes of the UUID are printed out as 4 hex digits each, with the top 2 digits always zero. For example, from the documentsignatures.xml file comes this element: <Reference URI="#ID_003f003400270062009c002c001100d9009c00170000005000ba005e008d008c"> which comes from the original UUID 3f342762-9c2c-11d9-9c17-0050ba5e8d8c which can be decoded by http://kruithof.xs4all.nl/uuid/uuidgen?typeReq=-1 to indicate that it was generated at Thursday, March 24, 2005 6:16:23 AM GMT, which corresponds to the time of the signature. The last 48 bits, 0050ba5e8d8c , corresponds to my MAC address (ifconfig on linux says HWaddr 00:50:BA:5E:8D:8C). Hope this helps.
I think the first priority is to figure out what the scores of other places in the code that use this dangerous sort of UUID do with them, and if any are being disclosed by OO 1.1. Here are a few thoughts on how to fix this. Besides the disclosure of the hardware address, the presence of multiple timestamps also can disclose undesirable information. In this example, two UUIDs are generated one after the other each of which has an independent time stamp with 100 ns resolution. Observers can derive guesses as to the speed of the processor by comparing the times, which could also compromise anonymity in some cases. The rtl_createUuid function is currently called with the "bUseEthernetAddress" argument set to sal_True. Setting it to false appears to substitute a 6-byte random value for the ethernet address. But given the timestamp issues, I'd recommend going with what others have done and suggested, which is using a Version 4 UUID which has nothing but type info and random bits. It would only take a bit more code and shouldn't add much time, since a pseudo-random-number generator is used, and secure random numbers don't seem to be important for this case.
addedc myself to the cc list
duplicate to issue 51500 ?
May i suggest the first priority is to switch to Version 4. Regardless of the internal usage, Openoffice is exposing a Version 1 UUID, and this must be stopped. If there is internal code using the timestamp, then "hopefully" it will realize the version variants, and will handle version 4 gracefully. Even if you break internal code, you'd be forced to ask yourself "why is it using UUID?" If you're after the timestamp, why not simply develop a timestamp mechanism? Version 1 has privacy issues, and it is always suspicious when software uses version 1. It would be nice to say OO doesn't.
MT->JL: Can you please have a look on that?
Compatibility?
added myself to cc
.
Shifted to OOo 2.2 due to time constraints.
rtl_createUuid now generates version 4 instead of version 1 UUIDs. Regression tests at sal/qa/rtl/uuid/.
@kr: Please verify (sal/inc/rtl/uuid.h:1.7.188.1, sal/rtl/source/uuid.cxx:1.8.42.1).
Looks good -> verified.
closing ancient issues