|
Message-ID: <55385A44.2030509@canonical.com> Date: Wed, 22 Apr 2015 22:34:44 -0400 From: Marc Deslauriers <marc.deslauriers@...onical.com> To: oss-security@...ts.openwall.com Subject: Re: Re: USBCreator D-Bus service On 2015-04-22 08:50 PM, Tavis Ormandy wrote: > On Wednesday, April 22, 2015, Seth Arnold <seth.arnold@...onical.com> wrote: >> On Thu, Apr 23, 2015 at 03:04:23AM +0300, Solar Designer wrote: >>> Either way, it sounds weird to keep a low severity issue private. Low >>> severity usually means not needing an embargo in the first place. But I >>> guess it was the vendor's preference? >> >> In this case, no, Ubuntu would have preferred several days embargo for >> this issue. Hypothetically speaking, Monday would have been ideal, as >> we prefer to not release updates on Friday, Saturday, or Sunday. >> >> We treat local root escalation vulnerabilities with a high priority[1]. > > I wish you had spoken up during the previous discussion. It was my > impression that embargoes for local privilege escalations were universally > considered deprecated. Nonsense, embargoes for local or remote privilege escalations are still considered to be high priority and should be handled with an embargo. Making this type of information public without giving the vendor a chance to publish updates within a reasonable timeframe is a great disservice to users and exposes them to great risk. > >> Please do inform us privately of further local root escalations in the >> future, either via security@...ntu.com or filing "private security" >> bugs against the corresponding package in Launchpad. >> >> Thanks > > Embargoes tend to make things worse, see your apport patch developed during > embargo or shellshock for examples. However, if you're sure, I'm willing to > do so for Ubuntu specific bugs in future. No they don't. They allow vendors time to develop a proper fix without exposing users to unneeded risk. Yes, sometimes the fix is inadequate and needs to be fixed, but publishing an exploit without a few days notice just makes matters unbearable for users and encourages vendors to keep security issues secret. Marc.
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.