Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | OpenOffice can compromise people's privacy by putting UUIDs that reveal their ethernet addresses into documents | ||||||
---|---|---|---|---|---|---|---|
Product: | General | Reporter: | nealmcb <neal> | ||||
Component: | code | Assignee: | kay.ramme | ||||
Status: | CLOSED FIXED | QA Contact: | issues@framework <issues> | ||||
Severity: | Trivial | ||||||
Priority: | P3 | CC: | frank, gerry, issues, www.openoffice.org | ||||
Version: | 680m87 | Keywords: | security | ||||
Target Milestone: | OOo 2.2 | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||
Developer Difficulty: | --- | ||||||
Attachments: |
|
Description
nealmcb
2005-07-03 06:40:36 UTC
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 |