Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 07 Oct 2014 12:33:14 -0600
From: Kurt Seifried <>
To: "" <>,
        Assign a CVE Identifier <>
Subject: Discussion: information leakage from server and client software -

So I was looking at Firefox and noticed on Fedora it has the Health
check and crash reporter enabled by default, meaning that if Fedora
crashes a bunch of information gets sent back to Mozilla (I assume), I
don't know if the UI/etc pops up and lets you see what is being sent and
so on, on RHEL the crash reporter appears to be disabled by default.

Also having looked at spamassassin (which has a component to retrieve
and update rules) and clamav (which has freshclam to update the AV DB)
both of these explicitly disable the updates, you must manually enable them.

Then I see this:
which is rather timely.

So we have a continuum, at one end we have programs that explicitly make
you configure them before they'll connect out, and on the other end we
have apps that connect out whether or not you want them to (and being
closed source on locked down hardware you probably have little to no
choice in the matter).

Additionally we have the type of information and expectations, e.g. if I
enable ntp or chrony I expect it to make outgoing connections to the NTP
servers, which may be semi random if using the pool servers. If
I fire up a web browser and point it at I expect traffic to
go there and any ad networks/etc, I may not be expecting it to send
random health reports somewhere.

So my question is basically this: where on this grey scale does it go
from mildly annoying to security vulnerability (and CVE worthy), the
main things being:

-what kind of information is leaked (e.g. PII? system config? just the
fact that you're asking what time it is?)
-assuming it makes these outgoing connections by default, how informed
are users, e.g. in firefox you get a brief one time warning you can look
at or does it maybe warnt he user, show them the info and then require
them to confirm sending it (e.g. sosreport).

Thanks in advance.

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)

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.