environment in reports can contain sensitive information

This is a bit tricky to solve. The bug reporting window explains that you should only attach the report if the program does not deal with sensitive data, but of course this does not make it clear that this covers the environment as well (and it is too hard to explain, too).

Maybe I should leave out the environment completely or just filter out some interesting stuff like $SHELL, $PATH, $LANGUAGE, and $LANG. These are the only interesting and insensitive variables that come to my mind right now.

I'd like to do a bit more auditing to see if I can help come up with solutions. Can you give me a quick lesson on decoding the base64 encoded core dump?

I tried to strip out just the (very long single line) base64 string and process it with:

$ openssl enc -d -base64 < /tmp/foo.base64 >/tmp/foo.bin

but that just produces a 0 length file.

Cheers,
b.

Hi Brian,

Brian J. Murrell [2006-08-19 23:40 -0000]:
> I'd like to do a bit more auditing to see if I can help come up with
> solutions. Can you give me a quick lesson on decoding the base64
> encoded core dump?

It's pretty easy with the problem_report python module in the
python-problem-report package. However, since this is generally
useful, I wrote a small script to extract the fields of a problem
report into separate fields (attached).

#!/usr/bin/python

# Extract the fields of a problem report into separate files into a new or
# empty directory.
#
# Copyright (c) 2006 Canonical Ltd.
# Author: Martin Pitt <email address hidden>
#
# This program is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by the
# Free Software Foundation; either version 2 of the License, or (at your
# option) any later version. See http://www.gnu.org/copyleft/gpl.html for
# the full text of the license.

import sys, os, os.path

import problem_report

if len(sys.argv) != 3:
    print 'Usage: %s <report> <target directory>' % sys.argv[0]
    sys.exit(1)

report = sys.argv[1]
dir = sys.argv[2]

# ensure that the directory does not yet exist or is empty
try:
    os.mkdir(dir)
except OSError:
    if os.listdir(dir):
 print >> sys.stderr, 'Destination directory %s exists and is not empty.'
 sys.exit(1)

pr = problem_report.ProblemReport()
pr.load(open(report))
for k in pr:
    open(os.path.join(dir, k), 'w').write(pr[k])

 apport (0.15) edgy; urgency=low
 .
   * Add apport-unpack: Script to extract the fields of a problem report into
     separate files into a new or empty directory. Mainly useful for extracting
     compressed binary data like the core dump.
   * test-apport: Check that dumped environment only contains security
     insensitive variables.
   * apport: Filter out all environment variables but $SHELL, $PATH, and
     locale/language related ones. Closes: LP#56846
   * test-apport: Delete test report in the cleanup handler so that the
     kernel-mode test can be run multiple times without manual cleanup.
   * test-apport: Check for running apport and test executable processes in
     check_crash().
   * preloadlib/libapport.c: Improve error checking, some robustification.
   * test-apport: If using the preload library, wait a second between the test
     process invocations in the flooding test to mitigate a strange race
     condition that sometimes causes the signal handler not to be executed.

On Sun, 2006-08-20 at 13:13 +0000, Martin Pitt wrote:
> Hi Brian,

Hi Martin,

> It's pretty easy with the problem_report python module in the
> python-problem-report package. However, since this is generally
> useful, I wrote a small script to extract the fields of a problem
> report into separate fields (attached).

I got this from it:

/tmp/foo$ apport-unpack /var/crash/_bin_bash.1001.crash .
Traceback (most recent call last):
  File "/usr/bin/apport-unpack", line 35, in ?
    pr.load(open(report))
  File "/usr/lib/python2.4/site-packages/problem_report.py", line 56, in load
    (key, value) = line.split(':', 1)
ValueError: need more than 1 value to unpack
brian@pc:/tmp/foo$ ls -l
total 0
brian@pc:/tmp/foo$ less /usr/bin/apport-unpack
brian@pc:/tmp/foo$ apport-unpack /var/crash/_bin_bash.1001.crash .
Traceback (most recent call last):
  File "/usr/bin/apport-unpack", line 35, in ?
    pr.load(open(report))
  File "/usr/lib/python2.4/site-packages/problem_report.py", line 56, in load
    (key, value) = line.split(':', 1)
ValueError: need more than 1 value to unpack

b.

--
My other computer is your Microsoft Windows server.

Brian J. Murrell

Hi Brian,

Brian J. Murrell [2006-08-21 19:01 -0000]:
> I got this from it:
>
> /tmp/foo$ apport-unpack /var/crash/_bin_bash.1001.crash .
> Traceback (most recent call last):
> File "/usr/bin/apport-unpack", line 35, in ?
> pr.load(open(report))
> File "/usr/lib/python2.4/site-packages/problem_report.py", line 56, in load
> (key, value) = line.split(':', 1)
> ValueError: need more than 1 value to unpack

Can you please mail me the report, or attach it to this bug?

On Tue, 2006-08-22 at 17:06 +0000, Martin Pitt wrote:
> Hi Brian,
>
> Brian J. Murrell [2006-08-21 19:01 -0000]:
> > I got this from it:
> >
> > /tmp/foo$ apport-unpack /var/crash/_bin_bash.1001.crash .
> > Traceback (most recent call last):
> > File "/usr/bin/apport-unpack", line 35, in ?
> > pr.load(open(report))
> > File "/usr/lib/python2.4/site-packages/problem_report.py", line 56, in load
> > (key, value) = line.split(':', 1)
> > ValueError: need more than 1 value to unpack
>
> Can you please mail me the report, or attach it to this bug?

I'd love to, but this report contains my password in the environment at
least. It may be in the core dump. That's why i wanted to un-base64
it. For an audit.

Maybe I can find some time to debug the unpacking here.

b.

--
My other computer is your Microsoft Windows server.

Brian J. Murrell