Bug 104992 - Possible information disclosure via Safe Mode
Summary: Possible information disclosure via Safe Mode
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: framework (show other bugs)
Version:
(earliest affected)
5.4.0.0.alpha0+
Hardware: All All
: medium critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: security
Depends on:
Blocks: Safe-Mode
  Show dependency treegraph
 
Reported: 2016-12-29 22:49 UTC by Gabor Kelemen (allotropia)
Modified: 2019-06-08 10:00 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gabor Kelemen (allotropia) 2016-12-29 22:49:13 UTC
I got a bit worried about the possibility of unintended information disclosure via Safe Mode.

Safe Mode gives an option to create a backup of the whole user profile, which can be uploaded to this Bugzilla.

Although the user is warned on the UI like this:
"You can also include relevant parts of your user profile in the bugreport (be aware it might contain personal data)."

I don't think this warning alone is enough. Scrubbing the sensitive data would be a minimum.

In a test profile I set up a master password, a CMIS service, and a mail account for mail merge, and all their data is included in the zip, for "further analysis". In particular I see:

<item oor:path="/org.openoffice.Office.Common/Misc"><prop oor:name="FilePickerPlacesNames" oor:op="fuse"><value><it>WebDAV - CENSORED</it></value></prop></item>
<item oor:path="/org.openoffice.Office.Common/Misc"><prop oor:name="FilePickerPlacesUrls" oor:op="fuse"><value><it>https://CENSORED.gov.hu:443/</it></value></prop></item>

<item oor:path="/org.openoffice.Office.Common/Passwords"><prop oor:name="HasMaster" oor:op="fuse"><value>true</value></prop></item>
<item oor:path="/org.openoffice.Office.Common/Passwords"><prop oor:name="Master" oor:op="fuse"><value>nehbfmdepkkdhbfjjflielklejpgjdbdgkpnnkcjglhimnnlmjfkbbdneplcipkclg</value></prop></item>
<item oor:path="/org.openoffice.Office.Common/Passwords/Store"><node oor:name="https_3a_2f_2fCENSORED2egov_2ehu_2f__kelemeng" oor:op="replace"><prop oor:name="Password" oor:op="fuse"><value>CENSORED</value></prop></node></item>

So an attacker can know I have access to CENSORED.gov.hu with user kelemeng. Also my master passwords hash, and the passwords hash for kelemeng@CENSORED.gov.hu.

Also bug #96672 is still not fixed, so you can have all my mail details including the password, in plain text:

<item oor:path="/org.openoffice.Office.Writer/MailMergeWizard"><prop oor:name="MailAddress" oor:op="fuse"><value>kelemeng@ubuntu.com</value></prop></item>
<item oor:path="/org.openoffice.Office.Writer/MailMergeWizard"><prop oor:name="MailDisplayName" oor:op="fuse"><value>Gabor Kelemen</value></prop></item>
<item oor:path="/org.openoffice.Office.Writer/MailMergeWizard"><prop oor:name="MailPassword" oor:op="fuse"><value>lofasznehogymatevagyabladerunner</value></prop></item>
<item oor:path="/org.openoffice.Office.Writer/MailMergeWizard"><prop oor:name="MailServer" oor:op="fuse"><value>smtp.gmail.com</value></prop></item>
<item oor:path="/org.openoffice.Office.Writer/MailMergeWizard"><prop oor:name="MailUserName" oor:op="fuse"><value>CENSORED@gmail.com</value></prop></item>

Finally my personal details from the Options - User Data panel, which I might want to share to people I share documents with, but probably not with the whole world:

<item oor:path="/org.openoffice.UserProfile/Data"><prop oor:name="c" oor:op="fuse"><value>Hungary</value></prop></item>
<item oor:path="/org.openoffice.UserProfile/Data"><prop oor:name="facsimiletelephonenumber" oor:op="fuse"><value>foo</value></prop></item>
<item oor:path="/org.openoffice.UserProfile/Data"><prop oor:name="fathersname" oor:op="fuse"><value></value></prop></item>
<item oor:path="/org.openoffice.UserProfile/Data"><prop oor:name="givenname" oor:op="fuse"><value></value></prop></item>
<item oor:path="/org.openoffice.UserProfile/Data"><prop oor:name="homephone" oor:op="fuse"><value>foo</value></prop></item>
<item oor:path="/org.openoffice.UserProfile/Data"><prop oor:name="initials" oor:op="fuse"><value>GK</value></prop></item>
<item oor:path="/org.openoffice.UserProfile/Data"><prop oor:name="l" oor:op="fuse"><value>foo</value></prop></item>
<item oor:path="/org.openoffice.UserProfile/Data"><prop oor:name="mail" oor:op="fuse"><value></value></prop></item>
<item oor:path="/org.openoffice.UserProfile/Data"><prop oor:name="o" oor:op="fuse"><value>ACME INC</value></prop></item>
<item oor:path="/org.openoffice.UserProfile/Data"><prop oor:name="position" oor:op="fuse"><value>foo</value></prop></item>
<item oor:path="/org.openoffice.UserProfile/Data"><prop oor:name="postalcode" oor:op="fuse"><value>foo</value></prop></item>
<item oor:path="/org.openoffice.UserProfile/Data"><prop oor:name="sn" oor:op="fuse"><value>Gabor Kelemen</value></prop></item>
<item oor:path="/org.openoffice.UserProfile/Data"><prop oor:name="st" oor:op="fuse"><value>foo</value></prop></item>
<item oor:path="/org.openoffice.UserProfile/Data"><prop oor:name="street" oor:op="fuse"><value>foo</value></prop></item>
<item oor:path="/org.openoffice.UserProfile/Data"><prop oor:name="telephonenumber" oor:op="fuse"><value>foo</value></prop></item>
<item oor:path="/org.openoffice.UserProfile/Data"><prop oor:name="title" oor:op="fuse"><value>foo</value></prop></item>
Comment 1 Stephan Bergmann 2017-01-11 07:58:03 UTC
(In reply to Gabor Kelemen from comment #0)
> I don't think this warning alone is enough. Scrubbing the sensitive data
> would be a minimum.

Note that there is no fixed known set of scrub-worthy data in registrymodifications.xcu; esp. extensions can bring along additional configuration schemas.
Comment 2 Samuel Mehrbrodt (allotropia) 2017-01-11 09:16:00 UTC
I removed the "unintended" from the title.
This is by design.

Maybe you have a suggestion how to improve the message? I don't see much we can/should do here.
Comment 3 Michael Meeks 2017-01-11 10:48:33 UTC
Does tweaking the legend do it for you ? if so how ? Would a tooltip when you mouse-over the button/label with some more text:

"This may include personal details from the settings, and also connection details for remote servers"

Or somesuch work ?
Comment 4 Cor Nouws 2017-01-11 11:11:26 UTC
(In reply to Michael Meeks from comment #3)

> "This may include personal details from the settings, and also connection
> details for remote servers"

And the idea is that users (..) then click "OK do send this" :) ?
Comment 5 Andras Timar 2017-01-19 08:54:08 UTC
The problem is that users will press OK, then they will regret later. Their data "will be publicly available and cannot be deleted" (quote from our bugzilla's front page).

At least, please document how to disable this feature.
Comment 6 Samuel Mehrbrodt (allotropia) 2017-01-19 09:53:41 UTC
(In reply to Andras Timar from comment #5)
> The problem is that users will press OK, then they will regret later. Their
> data "will be publicly available and cannot be deleted" (quote from our
> bugzilla's front page).
> 
> At least, please document how to disable this feature.

Which feature?
There is no automatic upload happening. Safe mode just offers to create the zip file. Users still need to manually send/upload it somewhere.
Comment 7 QA Administrators 2018-01-20 03:33:23 UTC Comment hidden (obsolete)
Comment 8 Cor Nouws 2018-01-20 15:38:35 UTC
(In reply to Andras Timar from comment #5)
> The problem is that users will press OK, then they will regret later. Their
> data "will be publicly available and cannot be deleted" (quote from our
> bugzilla's front page).
> 
> At least, please document how to disable this feature.

See comment #0 for what will be disclosed when users click OK without searching through all the lines for sensible data.
Comment 9 Thorsten Behrens (allotropia) 2018-02-23 13:52:49 UTC
As it stands, this bug report does not seem actionable - setting to NEEDINFO

(ideas how to scrub that is fool-proof, how to better phrase the UI warning etc etc needed)
Comment 10 Xisco Faulí 2018-02-26 11:37:23 UTC
FYI: I'm deleting user profiles I'm finding in Bugzilla as attachments that might contain sensitive data. If you find any that needs to be deleted, please, let me know. I'll also add it to the QA script, so I'll be notified when registrymodifications.xcu is added as attachment in the future...
Comment 11 Xisco Faulí 2018-02-28 10:47:26 UTC
(In reply to Thorsten Behrens (CIB) from comment #9)
> As it stands, this bug report does not seem actionable - setting to NEEDINFO
> 
> (ideas how to scrub that is fool-proof, how to better phrase the UI warning
> etc etc needed)

Dear Gabor Kelemen,
Could you please provide a better phrase for the UI and set this bug back to NEW ?
Comment 12 QA Administrators 2018-10-09 11:27:32 UTC Comment hidden (obsolete)
Comment 13 Cor Nouws 2018-11-02 11:37:47 UTC
(In reply to Xisco Faulí from comment #11)
> Dear Gabor Kelemen,
> Could you please provide a better phrase for the UI and set this bug back to
> NEW ?

He suggests more than just a better wording:

(In reply to Gabor Kelemen from comment #0)
> ...
> I don't think this warning alone is enough. Scrubbing the sensitive data
> would be a minimum.
Comment 14 Thorsten Behrens (allotropia) 2018-11-02 12:35:56 UTC
(In reply to Cor Nouws from comment #13)
> (In reply to Gabor Kelemen from comment #0)
> > ...
> > I don't think this warning alone is enough. Scrubbing the sensitive data
> > would be a minimum.

But that is not actionable I'm afraid (and also defeats the purpose of this feature, which originally came from QA).

I see two ways forward:
* improve what we have (extra warnings, hide the feature some more) within the scope of this bug
* file a separate enhancement issue, that will then need UX (and other stakeholder) input, if/how/whether this can be implemented entirely differently

Back to NEEDINFO.
Comment 15 Xisco Faulí 2018-11-05 12:57:15 UTC
(In reply to Thorsten Behrens (CIB) from comment #14)
> (In reply to Cor Nouws from comment #13)
> > (In reply to Gabor Kelemen from comment #0)
> > > ...
> > > I don't think this warning alone is enough. Scrubbing the sensitive data
> > > would be a minimum.
> 
> But that is not actionable I'm afraid (and also defeats the purpose of this
> feature, which originally came from QA).
> 
> I see two ways forward:
> * improve what we have (extra warnings, hide the feature some more) within
> the scope of this bug
> * file a separate enhancement issue, that will then need UX (and other
> stakeholder) input, if/how/whether this can be implemented entirely
> differently
> 
> Back to NEEDINFO.

@Gabor, could you please answer Thorsten's comment above ?
Comment 16 QA Administrators 2019-05-08 17:30:13 UTC Comment hidden (obsolete)
Comment 17 QA Administrators 2019-06-08 02:55:27 UTC Comment hidden (obsolete)
Comment 18 Cor Nouws 2019-06-08 10:00:11 UTC
In bug 120269 I've proposed to work on a better warning.