Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Fri, 18 Jul 2014 18:33:38 -0600
From: Kurt Seifried <>
Subject: CVE's for intersection vulnerabilities

Hash: SHA1

So long story short: we have a program called sosreport that is used
to send system information back to Red Hat so we can help customers
troubleshoot their problems. It would appear we have three main
classes of (potential) security vulnerabilities:

1) sosreport collects sensitive information that is unexpected/should
not be included, e.g. potentially it could grab configuration files
with credentials for third party systems/etc. My take on this is this
type of data should only be included if explicitly added/requested by
the end user (it should default to safe for well known sensitive files
in other words).

2) sosreport collects sensitive information that would be "normal",
e.g. HTTP logs with GET requests, or usernames used to log into
services. My take on this is that we should document this behaviour
and provide options for the users to review/sanitize data prior to it
being sent to Red Hat, but that this is security hardening and not a
vulnerability, so no CVE.

3) sosreport unintentionally collects sensitive information, e.g. a
service mistakenly logs username/password to a world readable log
file, which sosreport then includes. My take on this would be that a
CVE is deserved for the program logging the sensitive information
(which normally it would get in any event), but that no CVE should be
assigned for sosreport (since #1 the flaw isn't in sosreport, and
ideally with #2 the user sees it and sanitizes it any ways).

But then we have #4:

4) sosreport unintentionally collects sensitive information, e.g. a
service mistakenly logs username/password to a secured log file. Now
normally this would not get a CVE since the logfile has secure
permissions, however we have a situation where sosreport is
potentially exposing the information. So do we assign a CVE for this
intersection vulnerability?

- -- 
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird -


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.