Bug 525858 - [RFE] Check and remove passwords etc from backtrace
[RFE] Check and remove passwords etc from backtrace
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: abrt (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Jiri Moskovcak
Fedora Extras Quality Assurance
:
: 525852 525853 525854 525855 (view as bug list)
Depends On:
Blocks: F12Target
  Show dependency treegraph
 
Reported: 2009-09-26 07:16 EDT by Nicolas Mailhot
Modified: 2015-02-01 17:49 EST (History)
9 users (show)

See Also:
Fixed In Version: abrt-2.0.10-1.fc17
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-04-18 19:00:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Nicolas Mailhot 2009-09-26 07:16:38 EDT
Description of problem:

Abrt produces backtraces that can contain sensitive data such as passwords

Abrt-gui should check them for sanity automatically (check for keywords such as variants on "password") and warn the user if it finds something that looks like sensitive data (highlight the result, focus on it, display if there are other suspicious matches, whatever)

And *not* by adding yet another user-unfriendly popup

Version-Release number of selected component (if applicable):
abrt-gui-0.0.9-2.fc12.x86_64
Comment 1 Denys Vlasenko 2009-10-06 10:23:38 EDT
dup 525855 says:

Abrt produces backtraces that can contain sensitive data such as passwords
People are supposed to check they're safe before pushing them bugzilla side

However those traces are not decorated and presented in plain text, making them
hard to read (it's easier to post-check them in gnome bugzilla, where they
*are* decorated with useful colors, but by that's time it's to late for
sensitive data)

Please use the usual decorator libs to make the stacks pretty in abrt-gui
Comment 2 Denys Vlasenko 2009-10-06 10:23:51 EDT
*** Bug 525855 has been marked as a duplicate of this bug. ***
Comment 3 Nicolas Mailhot 2009-10-06 10:36:18 EDT
The two bugs are not about the same thing:
- bug #525855 is about using one of the standard code prettyfiers to pretty-print stack traces in the abrt gui (prettyfy the trace structure and make it easy to read)
- this bug is about highlighting specific "dangerous" keywords such as password fields, that do not make sense in a standard code prettyfier but that abrt-gui can not ignore (make it easy to detect sensitive info)
Comment 4 Denys Vlasenko 2009-10-07 07:36:31 EDT
*** Bug 525854 has been marked as a duplicate of this bug. ***
Comment 5 Denys Vlasenko 2009-10-07 07:37:51 EDT
*** Bug 525853 has been marked as a duplicate of this bug. ***
Comment 6 Denys Vlasenko 2009-10-07 07:37:54 EDT
*** Bug 525852 has been marked as a duplicate of this bug. ***
Comment 7 Denys Vlasenko 2009-10-07 07:38:49 EDT
Dupes:

525854 "No usable way to display traces" - asks for bigger (maximizable) report window,

525853 "No obvious way to search traces" - asks for text search facility in backtrace, to search for "password" etc.

525852 "No obvious way to edit traces" - wants to edit backtrace in order to remove sensitive data.
Comment 8 Dan Stahlke 2009-11-27 02:34:12 EST
Reading this bug and it dupes, I infer that users are supposed to search the backtrace to see whether it contains any passwords (this is far from obvious from within the abrt gui).  However, the popup asks permission to send a core dump, and the core dump contains all program memory, not just the stack.  I am experiencing a crash in gkrellm's mail check routines and am reluctant to have a core dump which is guaranteed to contain my email password posted to the public server.  Do these files become publicly downloadable?  If so, I bet there will be dozens of passwords sitting around just waiting to be downloaded by whoever does that sort of thing.

It would be nice to offer a search-and-replace feature that would allow me to type my password and then have all instances of it replaced with XXXXX or something.  Better yet, it would be nice if the core file could be encrypted with the developer's GPG key.

Also, I had said yes to sending the backtrace and no to sending the core dump.  It seems that abrt then submitted neither to bugzilla and the bug report was deemed useless.
Comment 9 Jiri Moskovcak 2009-11-27 06:19:18 EST
(In reply to comment #8)
> Reading this bug and it dupes, I infer that users are supposed to search the
> backtrace to see whether it contains any passwords (this is far from obvious
> from within the abrt gui).  However, the popup asks permission to send a core
> dump, and the core dump contains all program memory, not just the stack.  I am
> experiencing a crash in gkrellm's mail check routines and am reluctant to have
> a core dump which is guaranteed to contain my email password posted to the
> public server.  Do these files become publicly downloadable?  If so, I bet
> there will be dozens of passwords sitting around just waiting to be downloaded
> by whoever does that sort of thing.
> 

Coredump is not send in BZ even if user press 'yes' this work only with the filetransfer plugin.

> It would be nice to offer a search-and-replace feature that would allow me to
> type my password and then have all instances of it replaced with XXXXX or
> something.  

Good idea, will look into it.

> Better yet, it would be nice if the core file could be encrypted
> with the developer's GPG key.
> 

Also good idea, but there is no information in the package about maintainer's gpg key and even if you had the key, you would had to trust the maintainer.

> Also, I had said yes to sending the backtrace and no to sending the core dump. 
> It seems that abrt then submitted neither to bugzilla and the bug report was
> deemed useless.  

This sounds like a bug, will try to reproduce this.

Thank you,
Jirka
Comment 10 Dan Stahlke 2009-11-27 15:36:47 EST
(In reply to comment #9)
> Coredump is not send in BZ even if user press 'yes' this work only with the
> filetransfer plugin.

Ok, that is a relief then.  If it is just the trace, I don't mind having to manually look it over for personal information, although it would be nice to spell this out before the permission-to-send box is shown ("look over the information below to make sure it doesn't contain any sensitive information") and maybe allow it to be edited.  And if the core dumps are not sent the dialog box should not ask for permission to send them...

> > Better yet, it would be nice if the core file could be encrypted
> > with the developer's GPG key.
> 
> Also good idea, but there is no information in the package about maintainer's
> gpg key and even if you had the key, you would had to trust the maintainer.

I was suggesting this under the belief that the core dumps were publicly downloadable.  If the cores are not sent at all, that's even better.

> Thank you,
> Jirka  

Thanks,
Dan
Comment 11 Denys Vlasenko 2010-02-08 22:42:37 EST
Look like "reasonably improved" in new GUI? Ok to close this bug?
Comment 12 Eric Blake 2010-06-11 12:13:38 EDT
I find it VERY time-consuming to manually scroll and read through pages of traceback looking for one or two instances of my username and/or password.  A search-and-replace feature would make this MUCH faster, since I know the few phrases that I am interested in protecting.  I think this should remain open until you have a search-and-replace feature to ease the scrubbing of a traceback.
Comment 13 Aleksandra Bookwar 2010-09-18 12:23:35 EDT
(In reply to comment #11)
> Look like "reasonably improved" in new GUI? Ok to close this bug?

what about cmdline field? it also can contain sensitive data

for example, 
I typed $ gftp some_site.org
got a crash

and now cmdline contains name of site, which I don't want to post in bugzilla
Comment 14 Fedora Admin XMLRPC Client 2011-12-19 12:42:21 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 15 Fedora Admin XMLRPC Client 2011-12-19 12:45:15 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 16 Jiri Moskovcak 2012-01-13 07:33:45 EST
I believe this bug is fixed in git. It's possible to edit any field and ABRT also automatically highlights sensitive words stored either in /etc/libreport/forbidden_words.conf and ~HOME/.abrt/settings/forbidden_words.conf


- the predefined list can be found here:http://git.fedorahosted.org/git/?p=libreport.git;a=blob;f=src/gui-wizard-gtk/forbidden_words.conf;h=effa4458e5cd96feede6831b7d5182ecc258c1a6;hb=HEAD

- if you think some words should be added to that list please don't hesitate and send an email to crash-catcher@fedorahosted.org

commit 9db54c707ebca2b98d465b2358b1bd9228c73550
Author: Jiri Moskovcak <jmoskovc@redhat.com>
Date:   Fri Jan 13 13:23:49 2012 +0100

    wizard: automatically highlight known sensitive words rhbz#525858 trac#441
Comment 17 Fedora Update System 2012-03-27 06:18:55 EDT
abrt-2.0.9-1.fc17, libreport-2.0.10-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/abrt-2.0.9-1.fc17,libreport-2.0.10-1.fc17
Comment 18 Fedora Update System 2012-03-28 01:59:43 EDT
Package abrt-2.0.9-1.fc17, libreport-2.0.10-1.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing abrt-2.0.9-1.fc17 libreport-2.0.10-1.fc17'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-4804/abrt-2.0.9-1.fc17,libreport-2.0.10-1.fc17
then log in and leave karma (feedback).
Comment 19 Fedora Update System 2012-04-02 09:34:54 EDT
abrt-2.0.10-1.fc17,libreport-2.0.10-2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/abrt-2.0.10-1.fc17,libreport-2.0.10-2.fc17
Comment 20 Fedora Update System 2012-04-18 19:00:51 EDT
abrt-2.0.10-1.fc17, libreport-2.0.10-2.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.