|
|
|
|
|
by shykes
3435 days ago
|
|
It's not infrequent to see occasional tension between vendors around the wording and timing of security disclosures. There are frequent examples of this with Google's Project Zero for example. As far as disagreements on the best way to handle a security disclosure, this one is pretty straightforward and was entirely avoidable. The vulnerability in question is a runC vulnerability, it affects equally all products with a dependency on runC (not just Docker). The vulnerability had already been patched in runC, and an update to Docker had already been released and announced. So it was not a zero day. A few vendors (not just Red Hat) have incorrectly announced to their users that they didn't need to upgrade to the latest version of Docker because their enterprise-grade commercial platform would "stop the vulnerability cold". In the case of Red Hat, the commercial differentiator is what they call "security-enhanced Linux" using SELinux. These vendors are under a lot of pressure to justify the high cost of their enterprise subscription by demonstrating concrete value. A great way to do that is to describe a scary vulnerability in a well-known product like Docker, and show that buying their product is the best protection against it. That is why the article talks about a "Docker vulnerability" instead of a "runC vulnerability" - Docker is a better-known product so the story will be more impactful that way. And it's also why the vulnerability is qualified as a "zero-day" even though it wasn't: it makes the vulnerability scarier. Red Hat was privately contacted to inform them of their mistake. They privately acknowledged the mistake. When the article hit the Hacker News front page, they were again privately informed of that as well. In spite of multiple requests, after several days they have still not corrected the article. This puts the security of Red Hat users at risk by continuing to tell them that an upgrade to Docker 1.12.6 is not necessary. This is especially disappointing because of the obvious conflict of interest. It was a perfect opportunity for Red Hat to set the bar high for themselves and remove any doubts that they might put the security of their users before commercial interest. The saddest part is that RHEL and SELinux have genuine security benefits that could be explained in very compelling ways without these shady marketing tactics. |
|
Because if the answer is "No", and there's some other way to bypass SELinux and exploit this bug, it raises more grave accusation of RedHad - false statement about the vulnerability workaround.