freebsd security - Jun 2019 - CVE-2019-5599 SACK Slowness (FreeBSD 12 using the RACK TCP Stack)

On Tue, Jun 18, 2019 at 05:34:32PM -0400, grarpamp
wrote:
>
https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5599
> NFLX-2019-001
> 
> Date Entry Created: 20190107
> Preallocated to nothing?
> Or witheld under irresponsible disclosure thus keeping
> users vulnerable to leaks, parallel discovery, and exploit
> for at least five months more than necessary, and
> unaware thus unable to consider potential local mitigations?
Other than the inappropriate tone, there is a reasonable question here.
MITRE allocates blocks of CVEs to FreeBSD as a CNA. We can then decide
when to assign and disclose them. The 2019-01-07 date is when MITRE
allocated a block of CVEs to FreeBSD, not when they are assigned to an
issue. We generally get a block in the beginning of each year.

If you would like to have an actual discussion around disclosure
policies, I'm happy to have one, but by your tone above, I don't think
there is any reason to do so. It seems unlikely you are open to
debate in a fashion that would be productive.

Thanks,
Gordon
Hat: Security Officer

On Tue, Jun 18, 2019 at 04:55:35PM -0700, Gordon Tetlow
wrote:
> On Tue, Jun 18, 2019 at 05:34:32PM -0400, grarpamp wrote:
> >
https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5599
> > NFLX-2019-001
> > 
> > Date Entry Created: 20190107
> > Preallocated to nothing?
> > Or witheld under irresponsible disclosure thus keeping
> > users vulnerable to leaks, parallel discovery, and exploit
> > for at least five months more than necessary, and
> > unaware thus unable to consider potential local mitigations?
> 
> Other than the inappropriate tone, there is a reasonable question here.
> MITRE allocates blocks of CVEs to FreeBSD as a CNA. We can then decide
> when to assign and disclose them. The 2019-01-07 date is when MITRE
> allocated a block of CVEs to FreeBSD, not when they are assigned to an
> issue. We generally get a block in the beginning of each year.
> 
> If you would like to have an actual discussion around disclosure
> policies, I'm happy to have one, but by your tone above, I don't
think
> there is any reason to do so. It seems unlikely you are open to
> debate in a fashion that would be productive.
Hey Gordon,

Thank you for your reply, and especially for the respectful tone. I
hope to drive a further positive discussion in the goal of enhanced
transparency.

It appears that Netflix's advisory (as of this writing) does not
include a timeline of events. Would FreeBSD be able to provide its
event timeline with regards to CVE-2019-5599?

Were any FreeBSD derivatives given advanced notice? If so, which ones?

Thanks for your time, resources, and continued correspondence.

Thanks again,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

Tor-ified Signal:    +1 443-546-8752
Tor+XMPP+OTR:        lattera at is.a.hacker.sx
GPG Key ID:          0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9  3633 C85B 0AF8 AB23 0FB2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL:
<http://lists.freebsd.org/pipermail/freebsd-security/attachments/20190618/2fa5f46b/attachment.sig>

On 6/18/19, Gordon Tetlow <gordon at tetlows.org>
wrote:
> On Tue, Jun 18, 2019 at 05:34:32PM -0400, grarpamp wrote:
>>
https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md
>> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5599
>> NFLX-2019-001
>>
>> Date Entry Created: 20190107
>> Preallocated to nothing?
>> Or witheld...?
> MITRE allocates blocks of CVEs to FreeBSD as a CNA. We can then decide
> when to assign and disclose them. The 2019-01-07 date is when MITRE
> allocated a block of CVEs to FreeBSD, not when they are assigned to an
> issue. We generally get a block in the beginning of each year.
So preallocated to nothing, ok very well, no problem,
priors amended herein as such, thx.

As it is not in the current .md, when was the issue
discovered by Netflix / Looney?
> discussion around disclosure policies
In today's world of parallel discovery, leaks, sec org infiltration by
adversary, surveillance, no crypto, rapid automated exploit, etc...
to wait for patch, polish, and press release advert, to not disclose,
afford users local action up to immediate offlining for safety and wait,
to draw upon entire community pool that has time*ability to fix... is
thought by many [users] as irresponsible to users. There is no tone. And
of course this one isn't currently a remote or local root. But what if it
was...
For those interested or new, there's lots of historical discussion with
and without tone that can be found on any seclist, yet is no universal..

Having just noted these...

https://www.freebsd.org/security/
https://www.freebsd.org/security/charter.html
https://svnweb.freebsd.org/doc/head/en_US.ISO8859-1/htdocs/security/

The charter last marked current 2002... is there any actual and
posted mandatory timeliness disclosure trigger component?
One that gets overall reviewed for user input say every N-years?
Perhaps something more security focused than the general...

https://www.research.net/r/freebsd2019


Hack happily :)


Netflix dedication to FreeBSD much appreciated by many too.

>>>
https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md
>> discussion around disclosure policies
> In today's world of parallel discovery, leaks, sec org infiltration by
> adversary, surveillance, no crypto, rapid automated exploit, etc...
> to wait for patch, polish, and press release advert, to not disclose,
> afford users local action up to immediate offlining for safety and wait,
> to draw upon entire community pool that has time*ability factor to fix...
is
> thought by many [users] as irresponsible to users. There is no tone. And
> of course this one isn't currently a remote or local root. But what if
it
> was...
> For those interested or new, there's lots of historical discussion with
> and without tone that can be found on any seclist, yet is no universal..
https://www.zdnet.com/article/firefox-zero-day-was-used-in-attack-against-coinbase-employees-not-its-users/
https://tech.slashdot.org/story/15/09/04/206228/bugzilla-breached-private-vulnerability-data-stolen
A recent Firefox zero-day that has made headlines across the tech news
world this week was actually used in attacks against Coinbase
employees, and not the company's users. Furthermore, the attacks used
not one, but two Firefox zero-days, according to Philip Martin, a
member of the Coinbase security team, which reported the attacks to
Mozilla. One was an RCE reported by a Google Project Zero security
researcher to Mozilla in April, and the second was a sandbox escape
that was spotted in the wild by the Coinbase team together with the
RCE, on Monday.
The question here is how an attacker managed to get hold of the
details for the RCE vulnerability and use it for his attacks after the
vulnerability was privately reported to Mozilla by Google. The
attacker could have found the Firefox RCE on his own, he could have
bribed a Mozilla/Google insider, hacked a Mozilla/Google employee and
viewed details about the RCE, or hacked Mozilla's bug tracker, like
another attacker did in 2015.
> https://www.freebsd.org/security/
> https://www.freebsd.org/security/charter.html
> https://svnweb.freebsd.org/doc/head/en_US.ISO8859-1/htdocs/security/
>
> The charter last marked current 2002... is there any actual and
> posted mandatory timeliness disclosure trigger component?
> One that gets overall reviewed for user input say every N-years?
> Perhaps something more security focused than the general...
>
> https://www.research.net/r/freebsd2019