[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 29 Mar 2024 22:43:07 -0000 (UTC)
From: Tavis Ormandy <taviso@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: backdoor in upstream xz/liblzma leading to ssh server compromise
On 2024-03-29, Andres Freund wrote:
> Hi,
>
> On 2024-03-29 21:54:11 -0000, Tavis Ormandy wrote:
>> On 2024-03-29, Solar Designer wrote:
>> >> I have a minor procedural question for Solar though, shouldn't this
>> >> have been redirected to oss-security immediately from distros? What's
>> >> the rationale for an embargo here?
>> >
>> > We don't have a clear policy for such case. Some distros list members
>> > have indeed suggested making this public ASAP. We ended up delaying
>> > publication by one day per my suggestion (as a compromise between ASAP
>> > and having no specific CRD), and I think these are some reasons why:
>>
>> Thanks, a compromise is better than nothing :) I think I would have
>> argued for immediately discussing this in the open.
>
> FWIW, I don't know much of the tradeoffs in this space. With that caveat:
>
Sure, it's distros moderators job to determine if an embargo is
necessary :)
> Personally I would have felt quite hesitant to post to distros@ if I knew that
> distros wouldn't get a reasonable, small, amount of time to prepare, so they
> have fixed packages available at the time of the public posting.
>
I guess I would hope you would trust the moderators to evaluate the
necessity of an embargo.
>> > 2. We didn't know how the culprit (or group) would react when they
>> > learned of the full extent of the community's awareness.
>>
>> This is true with any vulnerability, there is always the possibility an
>> attacker is already aware of it. They could respond to a patch being
>> released by trying to extract as much value from their exploit before
>> it's worthless.
>>
>> I'm not convinced that's a good argument to delay making the patch
>> available?
>
> What patch? You mean going back to an older version?
>
No, vulnerabilities usually require a patch, and we never know if bad
guys already know about the bug (unfortunately they won't tell us). You
could argue that if we release a patch, the attacker might respond by
trying to compromise as many targets as possible before their exploit is
worthless.
After all, if you're spending $1M to develop an exploit, why not keep an
eye on git commits to monitor if your investment is about to be ruined?
If someone said "it's better to let the attackers work slowly and
stealthily than alert them and potentially incentivize them to
compromise lots of people". I think most people would be strongly
opposed, I know I am!
I think this is not significanly different to Solars argument - If we
discuss this in public, maybe the attackers will start compromising
systems more aggressively.
Tavis.
--
_o) $ lynx lock.cmpxchg8b.com
/\\ _o) _o) $ finger taviso@....org
_\_V _( ) _( ) @taviso
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.
