[talk] Embargo/Foundation questions, Intel CPU/speculation bugs

[Shawn Webb]

On Sun, Jun 17, 2018 at 03:59:01PM -0400, Isaac (.ike) Levy wrote:
> Hi All,
> 
> I'm sure folks have been tuned in to the fragmented security news of the week: Intel and more speculative execution security flaws.  (If not, check the URL footnotes below).
> 
> With that, questions for list, genuinely looking for some logical answers in favor of the NDA/embargo on critical fixes we've seen in recent months:
> 
> - What do folks think about these Intel NDA-covered embargo, (or any vendor for that matter)?
> The embargoed information really doesn't seem to be doing us all any good at all here as users.
> I'd really love to hear any constructive reasons why the NDA's are necessary or good for any project developement?!  How does this help the world?
> 
> - Specific to FreeBSD, and the Foundation: I've been a huge fan of the FreeBSD foundation since it's inception.  To separate assets from the FreeBSD codebase was certainly born in the SCO era, with the the USL vs. BSDi era in mind, etc... this part of the mission of the Foundation has always made a lot of sense to me- separating legal assets from the codebase for the longevity of the codebase itself.  The Foundation has done some excellent work, from handling donations, coordinating conference attendance, project grants, developer hardware and donations- and of course supporting the amazing RELENG work as a J.O.B. job for Glen Barber (et. al.).  This has produced amazing things for FreeBSD.
> 
> Yet, what are the *boundaries* of the mission of the FreeBSD foundation?
> Does the foundation even facilitate vendor relationships and shepherd NDA's for developers, or am I just totally mistaken here?
> I mean, a while back they were becomming involved with humanitarian projects- wonderful stuff, but not what I donate to the FreeBSD Foundation for- and certainly quite a deviation from strategically shepherding the legalities of NDA's with Intel.
> These days, I see a lot of great press stuff on the Foundation site, but I don't see any clear "here is why we help sign NDA's with Intel."  I can't even find mention of "NDA" on the Foundation site.
> 
> Assuming FreeBSD devlopers/Foundation does have NDA with Intel (others) for chip documentation, as well as security vulnearabilities:
> 
> For Meltdown/Spectre, well, I don't know if if NDA's were in place at the time- but if it was, it didn't seem to help FreeBSD get any mitigations out- (even for several weeks past public disclosure).
> 
> Frankly, if the FreeBSD Foundation appears to have handled taking on the burden of NDA's which enforce embargos on critical security fixes to the FreeBSD codebase, why would various fixes be prevented from being applied to the codebase by developers not under NDA, (and not in the know)?  Excepting that this activity could naturally lead Intel legal or others to believe that NDA holders are leaking info, is there anything which actually prevents fixes from going into the FreeBSD codebase from non-NDA committers?
> 
> Last question- stance on Intel::
> Aside from the fact that I'm typing this on an Intel CPU, and this message has proably only touched Intel CPU's on it's way to your eye-balls reading it, why are we treating Intel so special not to hold them accountable or even to ask them to provide user manuals and documentation for the CPU's we buy from them, particularly in the case of security problems with undocumented features?
> 
> Best,
> .ike

Hey Ike,

Thank you for sharing your thoughts and starting this much-needed
discussion. I'm in the process of gathering my thoughts and writing a
rather lengthy article.  I've pasted below an incomplete rough draft.
I still have a lot more to write and I'm gethering input from a few
other peeps, both individuals and businesses. I cannot stress enough
that this is an _incomplete_ and _rough_ draft. I'm no where close to
finished with it, yet.

It's in Markdown format.

Full Disclosure Versus Responsible Disclosure
=============================================

Very special and crucial note: This article discusses my personal
feelings regarding vulnerability disclosure methods. This article is
not written on behalf of HardenedBSD. This article does NOT reflect
the opinions, beliefs, or actions of The HardenedBSD Project.

Meltdown and Spectre, along with the other CPU microarchitecture
speculation vulnerabilities, will be the prime use case in this
article.

It's fine if you don't agree with this article. If everyone held my
same opinions and beliefs, the world would be a very boring place.
Diverse thought makes experiencing and living in this world exciting.

My goal with this article is to start a much-needed discussion. I hope
we in the infosec industry can learn from recent events and move
forward together.

Definitions
-----------

We live in a time when vendors prefer security researchers disclose
newly-found vulnerabilities responsibly. We don't have a firm
definition of what "responsible disclosure" is, though. Usually,
researchers will follow this pattern:

1. Researcher finds exploitable vulnerability
1. Researcher notifies vendor, giving a projected embargo date
1. Vendor resolves issues prior to expiration of embargo
1. Researcher and vendor release a joint announcement

This workflow typically works when the vendor produces easy-to-update
products that don't have many (or any) downstream dependent consumers.
Firefox is an easy example. All Mozilla has to do is fix the bug and
cut a new release. The package maintainers for the various operating
systems will perform a version bump and the problem is largely solved.

The definition of "Responsible Disclosure" becomes murky when a
researcher finds a vulnerability in a hard-to-update product used in a
massive scale, like Intel CPUs. Sure, Intel should be notified, but
certain vulnerabilities have much larger impact than Intel's
product line by itself. Meltdown and Spectre provide an excellent case
study.

Thus, when we define "Responsible Disclosure," we also need to define
"Coordinated Disclosure." Vendors must responsibly decide which
downstream projects get notified and in which order.

The Coordinated Disclosure Problem
----------------------------------

A lot of business today is about relationships. This is especially
true in information security. We value the opinions of people we know
and trust and distrust everyone else.

When a vendor receives a security notification, the vendor must
evaluate who could be impacted and of those impacted, who to notify.
Coordinated disclosures usually come with either a Non-Disclosure
Agreement (NDA) or an embargo until a specified date. The vendor can
choose to collaborate with zero or more impacted entities of the
vendor's own choosing.

When Intel received notice from Google regarding Meltdown and Spectre,
Intel chose to notify only a few larger entities (eg, Amazon, Google,
and Linux). Those entities got a six-month advanced notice and had at
least some semblance of a fix the day the story broke in January 2018.
FreeBSD received notice the week around Christmas 2017 only after
certain researchers in-the-know pushed Intel hard to notify FreeBSD.
Smaller hosting companies and all of the other BSDs were left out.

Thus, Intel only coordinated the disclosure with a few larger players.
Favoritism is at play here. Such favoritism has a direct impact on the
economy of the less fortunate. Why would I go with a smaller hosting
provider when Amazon receives and can take action on advanced
vulnerability notifications? If security is of any concern, I should
only use Amazon's and Google's services. Screw the smaller players,
right?

Coordinated disclosure, as currently performed, should be called
unethical selective disclosure. Pay the right people your agreed
extortion, and you're now on the favorites list. When did it become
acceptable to pay someone to tell you you're vulnerable because of
their mistakes?

The Case For Full Disclosure
----------------------------

Since so-called responsible disclosure inevitably leads to greed and
extortion, full disclosure is the responsible way forward. All
downstream vendors become equals.

Full disclosure lends itself to a better collaborative effort. Now
that all entities are on equal footing, they can work together to
provide their communities the best quality fix. No one single vendor
has an omniscient developer capable of writing "the perfect fix." If
vendors work side-by-side, they can anticipate future problems along
with providing innovative fixes and mitigations for current issues.

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

Tor-ified Signal:    +1 443-546-8752
Tor+XMPP+OTR:        lattera at is.a.hacker.sx
GPG Key ID:          0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.nycbug.org/pipermail/talk/attachments/20180617/0508a751/attachment.bin>