Allow user to suppress individual fields when sending a report

[Brian J. Murrell]

Binary package hint: apport

When apport detects a crash in an application that handles passwords there is a huge opportunity for an unwitting user to upload an attachment (i.e. a core file) with their password in it!

I'm not sure what the answer is to this problem. Initially I thought that applications that even come remotely close to handling passwords should be flagged and their bug reports be marked private when uploaded. That only limits possible password disclosure though.

Probably what is needed is some kind of password scrubbing tool that iterates over all of the attachments looking for a list of strings (i.e. passwords) and replace them with something like "***" (enough to fill the string). That would require that apport know a users password(s) in plain-text though. As bad as that is, sending passwords to an open and public bug reporting system is even worse.

Thots?

[Marco Rodrigues (gothicx)]

Have you an example of this ? I think it doesn't includes that type of information...

[Brian J. Murrell (brian-interlinx)]

On Mon, 2007-16-04 at 22:29 +0000, Marco Rodrigues wrote:
> Have you an example of this ? I think it doesn't includes that type of
> information...

A coredump of a login process dying or screen-saver unlocking process
will most certainly contain a password. Trust me. I have a core dump
here in hand that such information in it.

b.

--
My other computer is your Microsoft Windows server.

Brian J. Murrell

[Martin Pitt (pitti)]

I confirm that both stack traces and core dumps can potentially have stack traces. However, there is no reliable way of detecting passwords automatically, thus I better close this one.

The better solution is to not expose these things to the public bug tracker in the first place, see https://launchpad.net/ubuntu/+spec/crash-reporting.

[Brian J. Murrell (brian-interlinx)]

If apport (the interacting with the user part) knows the password(s) that could be in any attachment it can scrub them.

The question is whether to expose passwords to apport or not.

[Brian J. Murrell (brian-interlinx)]

Martin,

Seriously? "Yes, it's a problem but we don't know how to fix it, so we will just close it"?

As for "https://launchpad.net/ubuntu/+spec/crash-reporting" that does not solve the problem. My passwords are still in LP's database and only as safe as LP is secure (which I have no reason to believe is so), and/or the people with access being trustworthy (again which I have no basis to believe in).

The real solution here is to allow users to prevent an attachment from being included with an apport report.

Can we please reopen this bug and address it in a more appropriate manner? Thanx.

[Martin Pitt (pitti)]

> If apport (the interacting with the user part) knows the password(s) that could be in any attachment it can scrub them.

How should it? There isn't a single place which holds/knows all your passwords, secret projects, personal data, and other sensitive stuff, except maybe your brain.

> The real solution here is to allow users to prevent an attachment from being included with an apport report.

Then such bug reports would loose everything that a developer needs to actually look into the problem. We could basically just say "program foo has crashed".

[Brian J. Murrell (brian-interlinx)]

On Thu, 2008-10-23 at 17:59 +0000, Martin Pitt wrote:
>
> How should it? There isn't a single place which holds/knows all your
> passwords, secret projects, personal data, and other sensitive stuff,
> except maybe your brain.

Sure. The keyring potentially has a wealth of them, yes. Perhaps
apport can keep a list (that you supply to it). And scrubbing some is
better than scrubbing none.

> Then such bug reports would loose everything

_Everything_?

> that a developer needs to
> actually look into the problem. We could basically just say "program foo
> has crashed".

So knowing the package versions, distro release version and having stack
traces, etc. is of absolutely no more value than me just saying "program
foo has crashed"? I don't think I believe that.

As it is currently, I (and I'm sure anyone else who realizes as much as
I do about what they are sending in CrashDump attachments) just don't
send apport reports because of the leak rather than sending 90% of the
information doesn't contain sensitive information.

TBH, I think Canonical are falling short of full disclosure in not being
more clear to users that they are likely sending account information in
their apport reports. Things that crash a lot like firefox and
evolution are rife with accounts and passwords.

b.

[Martin Pitt (pitti)]

Brian J. Murrell [2008-10-23 18:17 -0000]:
> So knowing the package versions, distro release version

That's of course important supplementary data, but on its own it is
worthless to describe the problem, yes.

> and having stack traces

Stack traces can already contain pretty much anything, passwords, PIN
numbers, secret project names, etc. passed around as function
arguments or local variables. And in most cases, we even need more
than that, the full core dump, to get a fully symbolic stack trace.

It is computationally infeasible to weed out stuff which is
potentially sensitive.

> TBH, I think Canonical are falling short of full disclosure in not
> being more clear to users that they are likely sending account
> information in their apport reports. Things that crash a lot like
> firefox and evolution are rife with accounts and passwords.

Right, that's why the user can inspect the report initially, it
says "If you were not doing anything private", we don't mark bugs
as public, and we disable apport in stable releases.

[Brian J. Murrell (brian-interlinx)]

On Thu, 2008-10-23 at 19:50 +0000, Martin Pitt wrote:

> That's of course important supplementary data, but on its own it is
> worthless to describe the problem, yes.

Of course, however along with...

> Stack traces can already contain pretty much anything, passwords, PIN
> numbers, secret project names, etc. passed around as function
> arguments or local variables.

Indeed. But I can visually inspect stack traces. I cannot do that with
the CoreDump. And just as I should have the option to not send the
CoreDump, I should be able to deselect sending any of the stack trace
attachments too. Of course I wouldn't once I have inspected them and
see they are clean. I would suggest that apport refuse to send a report
with too many things disabled.

Another option is to make (some of) the attachments editable. I'd send
a stack trace once I was able to "xxxxxx" out sensitive data. I'd even
suggest that of the CoreDump if it were not impractical 99% of the time.

> And in most cases, we even need more
> than that, the full core dump, to get a fully symbolic stack trace.

Yes, that's a fair point. It would be nice if the apport gui did
everything one needed to make sure fully symbolic stack traces were
sent.

> It is computationally infeasible to weed out stuff which is
> potentially sensitive.

Maybe. Maybe not.

> Right, that's why the user can inspect the report initially,

But they cannot inspect the most revealing aspect which is the CoreDump.

> it
> says "If you were not doing anything private", we don't mark bugs
> as public, and we disable apport in stable releases.

Yeah. I have seen that. The problem is, I think, that the average user
still does not understand the implication. My mom for example could be
looking for a recipe with firefox and it crashes. She wasn't doing
anything "private" although sending the CoreDump potentially will leak
the passwords she has told ff to remember and, as I have seen
personally, will leak cookies which I have seen financial institutions
dropping account information into.

I wonder how many ff bugs have CoreDumps in them which an LP
administrator/bug triage engineer has allowed to be public.

[Martin Pitt (pitti)]

Hi Brian,

Brian J. Murrell [2008-10-23 20:50 -0000]:
> Indeed. But I can visually inspect stack traces. I cannot do that with
> the CoreDump.

Right. Just to be clear, I am not *really* happy about sending core
dumps either, but it's currently the only practical method to get any
helpful information out of most crashes.

> And just as I should have the option to not send the CoreDump,

If the stack trace has some information already, apport does offer to
send a "reduced" report, which does not have the core dump.

> I should be able to deselect sending any of the stack trace
> attachments too.

That's a possible enhancement indeed.

> Yes, that's a fair point. It would be nice if the apport gui did
> everything one needed to make sure fully symbolic stack traces were
> sent.

This would be a possible option for developers, yes. That's bug 75901.
However, it isn't the standard mode of operation because it needs lots
and lots of debug symbols to download.

> Yeah. I have seen that. The problem is, I think, that the average user
> still does not understand the implication. My mom for example could be
> looking for a recipe with firefox and it crashes.

Right, she can't, and I don't expect her to. That's why we disable
apport in stable releases. :-)

Thank you,

Martin

[Brian J. Murrell (brian-interlinx)]

On Tue, 2008-10-28 at 09:58 +0000, Martin Pitt wrote:
> Hi Brian,

Hi Martin,

> Right. Just to be clear, I am not *really* happy about sending core
> dumps either, but it's currently the only practical method to get any
> helpful information out of most crashes.

Understood.

> If the stack trace has some information already, apport does offer to
> send a "reduced" report, which does not have the core dump.

Yeah, I had wondered what all was in a reduced report. Maybe it's
worthwhile noting in the dialog where you get that choice what won't be
included in a reduced report. Or maybe when one views the expanded list
of what's going in the report the reduced/full options are still
selectable and the expanded view changes to reflect what will be
included.

Of course all of this is moot if you were to...

>
> > I should be able to deselect sending any of the stack trace
> > attachments too.
>
> That's a possible enhancement indeed.

Do this instead/also.

> This would be a possible option for developers, yes. That's bug 75901.
> However, it isn't the standard mode of operation because it needs lots
> and lots of debug symbols to download.

Sure. I think you should still give users the option to do that:

        Rather than sending the CoreDump which has a likelihood of
        containing sensitive information, I need to install some
        packages to gather more debugging information. I will need to
        install 10MB of additional packages. Shall I go ahead and do
        this? Yes No.

        Shall I Remove additional packages when done? Yes No.

> Right, she can't, and I don't expect her to. That's why we disable
> apport in stable releases. :-)

Yeah. But if this reason is the only reason why GA releases get apport
disabled, if we could solve this, we could get apport reports from GA
users.

b.

[Martin Pitt (pitti)]

 summary Allow user to suppress individual fields when sending a report
 status triaged
 importance low
 done

Brian J. Murrell [2008-10-28 11:16 -0000]:
> > > I should be able to deselect sending any of the stack trace
> > > attachments too.
> >
> > That's a possible enhancement indeed.
>
> Do this instead/also.

Right, so I devote this bug report to this aspect, since it is both
feasible and helps to what you have in mind.

> > Right, she can't, and I don't expect her to. That's why we disable
> > apport in stable releases. :-)
>
> Yeah. But if this reason is the only reason why GA releases get apport
> disabled, if we could solve this, we could get apport reports from GA
> users.

It's actually not the only reason, but certainly the most important
one. Others are:

 - Crash report processing takes a lot of CPU and I/O resources and
   disk space, which is inconvenient.

 - By the time we release we should already have the really bad
   crashes reported, and we won't fix the uncritical/seldom ones in
   stables (SRU policy). Besides, during the development cycle
   we get way more crash reports than we could ever triage/fix anyway.

Thanks,

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

[tronicum (stefan-sels)]

I had a similar problem with a information reported by apport "HalComputerInfo.txt".

It contained my Laptops serial/service tag. Such information should not be publish as it allows you to get support from your manufacturer and identify you by that unqiue entity (or if you are more evil, report it as stolen, register it as your device, and so on).

That field within that file should not be reported at all (device serial).

[Martin Pitt (pitti)]

tronicum [2009-03-02 0:06 -0000]:
> It contained my Laptops serial/service tag. Such information should not
> be publish as it allows you to get support from your manufacturer and
> identify you by that unqiue entity (or if you are more evil, report it
> as stolen, register it as your device, and so on).
>
> That field within that file should not be reported at all (device
> serial).

Good point. I fixed that in the development release, will upload soon.

Thanks!

[komputes (komputes)]

I am for the review full content of files before they are uploaded, and have the ability to allow or deny the attachment of the file as this will respect user privacy. As far as I know crash dumps are put into private bugs and are reviewed for sensitive information before being made public. Any crashed that allow passwords to be sent to a bug report should be seen as a security risk.

[komputes (komputes)]

Also note that this bug looks very similar to Bug #137687 - "apport automatic bug-reporting system doesn't (apparently) let you see what it reports to launchpad"

[Brian J. Murrell (brian-interlinx)]

On Fri, 2010-01-08 at 18:31 +0000, komputes wrote:
> As far as I know crash dumps are put into
> private bugs and are reviewed for sensitive information before being
> made public.

Being comfortable with that means you are comfortable with:
      * the proficiency of the bug triager to identify what could be
        sensitive information
      * the tenacity of the triager to hunt down all possible leaks
      * the trustworthy-ness of everyone who has access to private bugs
      * the trustworthy-ness of the LP software to keep information in
        private bugs private
      * the security of the LP website and it's backing infrastructure

I could keep going. The bottom line is that if information is
sensitive, know where it's going and everyone who will deal with it, or
don't give it. Personally if it's sensitive and unnecessary to be
shared, I don't share it.

[komputes (komputes)]

The information is sensitive and there should be better ways of checking for this type of info before sending it in.

Q: the proficiency and tenacity
A: Basically this person has to prove themselves to BugControl. This can't be assured.

Q: the trustworthy-ness of everyone who has access to private bugs
A: this can't be assured.

Q: the trustworthy-ness of the LP software to keep information in private bugs private
A: Can't find teh bug now, but launchpadlibrarian (holds all attachments) is wide open, even if the bug is private, all you need is the URL and you can access the attachment. You are basically counting on security through obscurity.

So you are completely right. I concur the fact that since security on this site and its groups is low, the user should be able to review ALL data that will be sent into launchpad.

[luca (llucax)]

I'll copy the description of bug 583003 here because it was marked as a duplicate of this one, but I think what I say is more general, so here it is:

There is no way to exclude sensitive information from a bug report using ubuntu-bug, and is a real PITA to report a bug via web directly (you have to search the magic URL, find the source package for the problematic package and then edit the magic URL with the source package).

To report a bug to Ubuntu you either have to sacrifice your privacy or go through a painful set of steps, none of them seems tempting for me, so I tend to avoid reporting bugs to Ubuntu.

I understand that is hard to give a naive user a lot of options, but it would be enough to:

1) State very clearly that the users privacy *will* be compromised, *always*, any information you send, becomes public and in the general case it shouldn't. If I want to report a spelling error, all you need is what the reporter of the bug have to say (and the version of the package at most). Everything else, is violating users privacy, making public a lot of information that makes no sense. See this very same bug report (reported via ubuntu-bug). How many information provided by ubuntu-bug is needed to understand/fix this issue?

2) Add an "Advanced" button (or whatever you want to name it) where you can select what to include or exclude from the bug report.

I hope you address it soon since I think is a very serious issue. As time passes I have less and less desires to report bugs when using Ubuntu (being mostly a Debian user I would love if you adopted report-bug, but I guess that won't happen :S).

Thanks.