[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 22 Apr 2015 20:49:27 -0700
From: Tavis Ormandy <taviso@...gle.com>
To: oss-security@...ts.openwall.com
Subject: Re: Re: USBCreator D-Bus service
On Wed, Apr 22, 2015 at 7:34 PM, Marc Deslauriers
<marc.deslauriers@...onical.com> wrote:
> 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.
Well, that's your opinion Marc, and I'd disagree!
Working in the shadows and keeping secrets does everyone a far greater
disservice.
>>
>>> 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.
Sure, that's the theory. It doesn't work that way in practice!
The history of Zardoz, vendor-sec and others are littered with doing
more harm than good. Frankly, they usually end up being secret feeds
of free exploits for attackers while their victims sit in blissful
ignorance.
> 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.
Naturally, I think it makes things better. There are only two possible
states during an embargo, vulnerable and ignorant or vulnerable and
aware. I certainly prefer the latter, and I'm quite sure I'm not
alone. Information allows action to be taken, where as secrecy
requires hoping and praying that only one person is smart enough to
discover the problem.
There are so many advantages to discussing and developing software in
the open that it's tough to enumerate them all! Presumably you agree
this is true for software development in general (or why would you
care about free software?), but dismiss it when security is involved.
You get peer review, and you get to mitigate bugs as early as possible
- this is more important than ever when security is involved!
Nevertheless, I'm willing to do as you wish in future for other Ubuntu bugs.
Tavis.
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.
