[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 30 Mar 2024 07:36:50 -0400
From: "Mike O'Connor" <mjo@...o.mi.org>
To: oss-security@...ts.openwall.com
Subject: Re: Re: backdoor in upstream xz/liblzma leading to
ssh server compromise
:Okay, but do we agree that if there is a mitigation available, it's better
:for it to be public?
:
:Isn't doing `dnf downgrade xxx` a mitigation, or `systemctl xxx stop`?
Downgrage *probably* is, for what was known at the time. But if you
weren't sure of scope, "systemctl xxx stop" could become "/sbin/halt
until we know it's safe(r)". Sounds like overreaction? *Probably*.
Probably is such a *fun* word.
Typically, there's an attempt to work it out with upstream for a fix,
It's one thing when "upstreamn" is belligerent, missing, or filled
with drain-bamaged agendas -- all common-enough reasons for problems
in engaging upstream. It's another thing when they appear to be
criminally malicious. Then, it might make sense to take it to the
"authorities", maybe get guidance like "don't touch the active crime
scene", perhaps get that helicopter of agents you spoke fondly of (*).
If upstream's been compromised for awhile, as *seems* to be the case
here, that calls for a broader inspection. The mitigation might be
"remove xz from OS altogether", or "downgrade several years worth",
before the bad actor(s) (if you're sure you can isolate). Either of
those might involve more than split-second "consumer first" decision.
Going public with "backdoor" without that thought through a bit might
be more risky for consumers than the backdoor.
And all this assumes you aren't being victimized by your own product
due to the issue. A wise flight attendant once said to me "in case of
an emergency, please assist youtself before assisting others".
:We all want users to be secure as fast as possible. The discussion is
:whether keeping backdoors embargoed helps achieve that.
How are remote backdoors different than other severe remote auth vulns
from an embargo perspective? Does backdoor imply MORE or LESS abuse
than "weird magic packet = r00t"? Perhaps both were implemented with
malicious intent, but the latter hides their tracks better. Network
backdoors tend to wither with overuse, due to flow data and such.
(Oh, and folks like Andres Freund turning into modern-day Cliff Stolls
chasing down CPU time irregularities -- thanks muchly!)
I don't pretend to know any of the answers here. I'm glad smart and
wise people are asking the questions, trying to do the right thing,
willing to (re)calibrate response as necessary.
(Heck, I'm just grateful that someone assigned a CVE, so we don't HAVE
to talk about this issue as "the sshd vulnerability" or, worse yet,
the "Bad Friday" branded vulnerability.)
Take FWIW...
-Mike
(*) They never tell ME when they're sending out the helicopters of
agents. Hwo rude of them! :)
--
Michael J. O'Connor mjo@...o.mi.org
=--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--=
"Ball don't lie!" -Sheed
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.
