The hidden costs of embargoes (Red Hat Security Blog)

[Posted June 12, 2015 by jake]

Over at the Red Hat Security Blog, Kurt Seifried looks at the costs of security embargoes. Keeping the information about security vulnerabilities quiet until distributions can coordinate their releases of a fix for it seems like it makes a lot of sense, but there are hidden costs to that. "Patch creation with an embargoed issue means only the researcher and upstream participating. The end result of this is often patches that are incomplete and do not fully address the issue. This happened with the Bash Shellshock issue (CVE-2014-6271) where the initial patch, and even subsequent patches, were incomplete resulting in several more CVEs (CVE-2014-6277, CVE-2014-6278, CVE-2014-7169). For a somewhat complete listing of such examples simply search the CVE database for 'because of an incomplete fix for'."

The hidden costs of embargoes (Red Hat Security Blog)

Posted Jun 12, 2015 18:48 UTC (Fri) by dany (guest, #18902) [Link] (6 responses)

and where exactly are these hidden costs?

in worst case (like in 175 incomplete fixes), the outcome is very similar to full disclosure scenario, so I dont see any added hidden cost of this model

The hidden costs of embargoes (Red Hat Security Blog)

Posted Jun 12, 2015 20:08 UTC (Fri) by Wol (subscriber, #4433) [Link] (2 responses)

The costs are twofold ...

Firstly the false sense of security that the problem has been fixed - which leads to sysadmins making mistakes because the security guys are treating them like mushrooms ...

Secondly, in your "worst case scenario", that's 174 lots of wasted effort trying to fix the problem, and thousands of times that of sysadmins installing dud fixes.

Cheers,
Wol

The hidden costs of embargoes (Red Hat Security Blog)

Posted Jun 14, 2015 8:30 UTC (Sun) by NAR (subscriber, #1313) [Link] (1 responses)

What is the guarantee that the first fix is OK for non-embargoed bug reports? Also, as far as I understand, there are nearly 70000 CVSs, 174 is about 0.25% of cases... And why would the efforts to find a fix be wasted? These efforts find part of the solution, so are not wasted...

The hidden costs of embargoes (Red Hat Security Blog)

Posted Jun 14, 2015 9:39 UTC (Sun) by Wol (subscriber, #4433) [Link]

Except how many of those 174 fixes are guys chasing down the wrong rabbit hole, because the guy who really knows isn't part of the security "cabal"?

And the real cost is to the sysadmins :-( Every "fix" that's trapped by QA as no good saves masses and oodles of sysadmin and user time.

Cheers,
Wol

The hidden costs of embargoes (Red Hat Security Blog)

Posted Jun 12, 2015 21:12 UTC (Fri) by raven667 (subscriber, #5198) [Link] (2 responses)

The TLDR; of the article is that the secrecy of embargoed patches prevents open projects from using their standard QA process, leading to security fixes being of lower quality than normal bug fixes. Any QA which is done ad-hoc is done manually which requires greater effort and therefore cost.

So No QA or Manual QA are part of the cost of embargoes, with full disclosure and no embargo then security fixes can use the normal development and QA tools when those tools are publicly accessible.

The hidden costs of embargoes (Red Hat Security Blog)

Posted Jun 13, 2015 5:57 UTC (Sat) by epa (subscriber, #39769) [Link]

I guess Github could support embargoed changes while still being consistent with their business model. If you make an embargoed branch you must provide a date (max two months in the future) when it will be made public. Or you can manually make it public before that date. The branch must be made public before changes can be merged from it to a public branch (using Github's web interface, at least). Similarly private issues could be marked with a release date and must not be referenced by publicly visible commits.

The hidden costs of embargoes (Red Hat Security Blog)

Posted Jun 17, 2015 16:48 UTC (Wed) by jreznik (guest, #61949) [Link]

Yes, that's something we discussed several times in Fedora. Last time I was asked by our OpenJDK guys if we could support private infrastructure. As OpenJDK build and required test suite could take days but you can't start before embargo ends... In the end, Fedora Board (at that time, no Council) approved it. But the amount of work would be so huge, that costs of doing it would be too high. It means support in our dist GIT, support in build system (Koji), same in Bodhi (tool that issues updates). Then private QA where automation is now happening but again - in open manner... And then we have troubles with issuing updates on time, so even we have build and fix, it can take days before it hits users but that's different issue and under discussion right now.

The hidden costs of embargoes (Red Hat Security Blog)

Posted Jun 13, 2015 5:18 UTC (Sat) by ghane (guest, #1805) [Link]

From the article:
> "The answer to the embargo question is surprisingly simple: we only embargo the issues that really matter and even then we use embargoes sparingly."

But that is what I always do anyway. I embargo only those that really matter. Now you are debating, not embargo, but "really matter".

This is like saying ASAP. Of course I will do it as soon as it is possiblle, I cannot do it earlier. And of course I will do it when it is possible, why delay?

The hidden costs of embargoes (Red Hat Security Blog)

Posted Jun 13, 2015 13:20 UTC (Sat) by flussence (guest, #85566) [Link] (1 responses)

There's nothing hidden about the costs when some entity launches a coordinated marketing blitz to broadcast a critical vulnerability to the world and fails to provide a working, tested fix alongside it, or doesn't allow people *with* a clue ample time to produce a fix.

I propose we give them a taste of their own medicine, by labelling this kind of sociopathic conduct "Narcissistic Disclosure".

The hidden costs of embargoes (Red Hat Security Blog)

Posted Jun 13, 2015 17:41 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]

It can be explained in a pretty straightforward manner by their business model. If a security company gets publicity, they are likely to get clients. They wouldn't get as much publicity waiting for the fix to be released.

The hidden costs of embargoes (Red Hat Security Blog)

Posted Jun 16, 2015 13:50 UTC (Tue) by jcpunk (subscriber, #95796) [Link] (1 responses)

I'd rather we stop hiring graphic designers, publicists, and branding security issues.

The hidden costs of embargoes (Red Hat Security Blog)

Posted Jun 23, 2015 13:57 UTC (Tue) by mirabilos (subscriber, #84359) [Link]

+1 Insightful