[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 9 Aug 2020 11:05:38 +0200
From: Richard Hartmann <richih.mailinglist@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Voiding CVE-2020-16248
Hi Bastian,
I have been wondering if I should reply or not as mutual feelings of
XKCD 386 are usually not conductive to a mailing lists' S/N ratio. As
we have known each other for ~15-20 years and as you asked directly, I
decided to reply.
> Could you please explain yourself why you think this is not a
> vulnerability? Even wanted functuality can constitute a vulnerability
> if looked on closer.
It's not just wanted, it's literally the reason blackbox_exporter exists.
> The software allows to send pre-defined requests to arbitrary targets
> and extract at least parts of the response. This is a typical SSRF.
> Would you require to specify the allowed targets, noone would ask.
Many tools in the networking, security, and monitoring space fit
common exploit characteristics. This is why they are useful as tools.
Precisely this consideration is why our security documentation[1]
talks about exporters and calls out blackbox_exporter and
snmp_exporter as their purpose is to proxy probes from certain vantage
points in networks. This has been pointed out in the GH issue as well.
Related: Before we even close the issue, I have suggested within
prometheus-team@ that we might want to consider allowlists in those
two exporters. Allowing users to itemize URLs, glob on FQDNs/URLs, and
subnet-match in their configuration may be striking a better balance.
The counterargument is that you should not be exposing internal
debugging tools on the public Internet anyway and that snmp_exporter
has secret data (SNMP communities) so it MUST NOT be on the public
Internet. As of today, there is no consensus within -team either way.
Based on my experience, I would expect to receive fewer, but not none,
false reports if/when we carry an allowlist. It will still allow
"SSRF" on _some_ targets which especially tools set up to emphasize a
company's security, and thus domain names etc. And security scanners
need human interpretation and context as this can not reasonably be
codified in scanners as of today.
> Please don't. You just accused the reporter of malpractice on a public
> forum. JFYI, this is punishable in your jurisdiction.
As we have known each other for so long, you know that IANAL and I
know that YANAL unless you changed careers lately. As a layman I do,
however, disagree with your implication/assessment that I exposed
myself legally in my original email. This seems to be a highly
hypothetical consideration anyway.
> Also embargo and posting a public issue on GitHub don't really mix.
That is part of my critique of the CVE's reporter as this is the
status of CVE & GH issue as of today.
> You did not address the reporter at all.
While I did not reply before the issue was closed, Brian replied in
less than seven hours, pointing to our documentation about why we do
not consider this a security vulnerability and how to report them
outside of public GH issues. I did address the reporter asking them to
close the issues, though.
All in all, I am not 100% clear what point you're making here, but I
hope the above is not completely off.
> The reporter is also not a
> regular user of GitHub, where this issue was raised.
Github sends email for issue replies by default. On a more general
point, I would expect anyone who reports a vulnerability to make a
reasonable effort of being available for follow-up questions.
Best,
Richard
PS: Sorry for the TOFU and CCs earlier; GMail's UI is made to
disregard proper quoting and most mailing lists I am on today use,
sadly, GMail and other MUAs which favour TOFU. So I kinda got used to
it but still should not have done it on this list.
[1] https://prometheus.io/docs/operating/security/#exporters
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.
