Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 30 Mar 2024 02:48:45 -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-30, Marc Deslauriers wrote:
> On 2024-03-29 19:49, Tavis Ormandy wrote:
>> On 2024-03-29, Marc Deslauriers wrote:
>>>> I think we should have a policy that if issues are suspected to be actively exploited, that the issue goes public immediately.  If even there is no patch or mitigation, there's not a lot of benefit to keeping it private.
>>>
>>> In this case, we had no reason to believe it was being actively exploited.
>>>
>> 
>> Yeah... but you also have no reason to not believe that?
>> 
>> What do you propose they were doing with their backdoor?
>
> They were still attempting to get it into distros,
>

You can do two things at once, I suspect attackers can too :)

>> Isn't doing `dnf downgrade xxx` a mitigation, or `systemctl xxx stop`?
>
> All we knew was that a payload was being attached to liblzma, it took a while to 
> get the other details. We wanted to make sure it wasn't propagating to packages 
> it compressed.
>

Sure - but why do you have to do that in private? You can get everyone
to help get those answers and converge on the correct solution
quickly.

The attackers already knew about this issue, so you were just keeping it
from defenders... that doesn't make sense to me.

> It wasn't obvious at the time that simply reverting to the previous version 
> would be a complete solution, and I don't think telling everyone to stop ssh on 
> all their servers and cloud instances is a viable mitigation at all.
>

Yeah, you're making big decisions for a lot of people here.

If your organization was not on the list and got compromised during the
embargo, do you think you would be thanking everyone for delaying your
response?

>> 
>> We all want users to be secure as fast as possible. The discussion is
>> whether keeping backdoors embargoed helps achieve that.
>
> It took a day to figure out what it was, what the impact was, and how to get it 
> fixed, at which point there was agreement it shouldn't be keep embargoed. Nobody 
> was pushing for it to be embargoed any longer than it needed to be.
>

Yeah, my point is just this would have been better handled in public!

I respect your work and I'm glad you were working on this, but in public
we could have got more eyes on this!

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.