oss-sec mailing list archives
Re: Re: backdoor in upstream xz/liblzma leading to ssh server compromise
From: Marc Deslauriers <marc.deslauriers () canonical com>
Date: Sat, 30 Mar 2024 09:34:45 -0400
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.
Current thread:
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise, (continued)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Tavis Ormandy (Mar 29)
- Re: Re: backdoor in upstream xz/liblzma leading to ssh server compromise Andres Freund (Mar 29)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Tavis Ormandy (Mar 29)
- Re: Re: backdoor in upstream xz/liblzma leading to ssh server compromise Liguori, Anthony (Mar 29)
- Re: Re: backdoor in upstream xz/liblzma leading to ssh server compromise Marc Deslauriers (Mar 29)
- Re: Re: backdoor in upstream xz/liblzma leading to ssh server compromise Russ Allbery (Mar 29)
- Re: Re: backdoor in upstream xz/liblzma leading to ssh server compromise Marc Deslauriers (Mar 29)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Tavis Ormandy (Mar 29)
- Re: Re: backdoor in upstream xz/liblzma leading to ssh server compromise Marc Deslauriers (Mar 29)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Tavis Ormandy (Mar 30)
- Re: Re: backdoor in upstream xz/liblzma leading to ssh server compromise Marc Deslauriers (Mar 30)
- Re: Re: backdoor in upstream xz/liblzma leading to ssh server compromise Marcin Wolcendorf (Mar 30)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Tavis Ormandy (Mar 30)
- Re: Re: backdoor in upstream xz/liblzma leading to ssh server compromise Marc Deslauriers (Mar 30)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Tavis Ormandy (Mar 30)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Bo Anderson (Mar 30)
- Re: Re: backdoor in upstream xz/liblzma leading to ssh server compromise Loganaden Velvindron (Mar 30)
- Re: Re: backdoor in upstream xz/liblzma leading to ssh server compromise Bjoern Franke (Mar 30)
- Re: Re: backdoor in upstream xz/liblzma leading to ssh server compromise Pierre-Elliott Bécue (Mar 30)
- Re: Re: backdoor in upstream xz/liblzma leading to ssh server compromise Jeffrey Walton (Mar 30)
- Re: backdoor in upstream xz/liblzma leading to ssh server compromise Solar Designer (Mar 30)