[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f5595730-197f-41ed-9c72-d92bd6eddd36@canonical.com>
Date: Sat, 30 Mar 2024 09:34:45 -0400
From: Marc Deslauriers <marc.deslauriers@...onical.com>
To: oss-security@...ts.openwall.com
Subject: Re: Re: backdoor in upstream xz/liblzma leading to ssh
server compromise
On 2024-03-29 22:48, Tavis Ormandy wrote:
> 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.
I'll let you in on a little secret: malicious entities also read this list.
There is no way to discuss this in public without turning a single malicious
entity into 10 000 malicious entities once the information is widely known.
Making sure the impact and mitigations are known before posting this publicly so
that everyone knows what to do before the 10 000 malicious entities start
attacking is just common sense.
>
>> 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?
If your organization got compromised because the 0-day was published before a
mitigation was available, would you be thanking the reporters?
>
>>>
>>> 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!
>
That is the problem, having more eyes on a 0-day also means more eyes from
malicious entities. Neither having an embargo nor immediately posting publicly
are ideal solutions. There needs to be a compromise, and while I understand and
respect your point of view, I don't think we'll ever see eye-to-eye on what the
acceptable compromise should be.
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.
