[sf-lug] sudo problem for users
Michael Paoli
Michael.Paoli at cal.berkeley.edu
Mon Feb 1 20:19:50 PST 2021
> From: "Bobbie Sellers" <bliss-sf4ever at dslextreme.com>
> Subject: [sf-lug] sudo problem for users
> Date: Mon, 1 Feb 2021 12:13:13 -0800
> I checked and no one has noted anything about this problem.
Well, I saw it, acted in timely manner - including notifying relevant
co-workers, and appropriate timely action was generally taken.
I thought about posting it to one of the LUG lists or something like that,
but I figured for the most part, those that were particularly interested
in it and cared about about it, already knew. Most any reasonable distro
with reasonable security alert mechanisms, it was there well to see in
quick order - that's where I first spotted it - or at least I'd presume
that was generally the case.
Let's see ... hit my "inbox" at ...
Received: ... Tue, 26 Jan 2021 10:06:34 -0800 (PST)
Anyway, can't find it now, but there was mention in at least one
bit I read on a specific coordinated embargo/release time (wan't thinking
to particularly note/remember it at the time - but I thought it said something
about 6pm ... but I don't recall mention of timezone ... looking at
that bit from my Received header, I'm guestimating it may have been
6PM / 18:00 UTC / GMT0 on 2021-01-26) - so once that
time hit, essentially everyone that had security fixes or (to be) public
releases/advisories - that all basically hit right at or very shortly
after that time - so I think most picked up on it quite right away,
and of course the security news articles and the like followed fairly
shortly thereafter.
So, ... believe I did mention in another context about that,
essentially saying my email "inbox"/incoming, I see
something in there that says DSA and SECURITY - I at least skim the
Subject: - I see "sudo" in that also I think, knowing the critical role
sudo plays on lots of hosts, I figure uh oh, this might be a biggie, I
read the email. Yup, pretty dang important, easy local exploit. Time to
update now - or at least as soon as feasible (sure, test non-production
first - but be quick about it - and always have ways to rollback anyway).
This isn't a "wait for your monthly / quarterly / major point release /
yearly patch updating", no, this is more like a "patch it now" - or pretty
dang soon - or at least if/where feasible if it can't be done that soon,
and appropriate, apply appropriate mitigating controls if/as/where
feasible. So, yep, ... basically done. Heck, even some hosts I have set
to automatically apply such updates on about a 24 hr. check/install
cycle ... I didn't even wait for that ... nope, this one goes in
now - more risk (at least in my guestimation) on this one of not
putting it in sooner, vs. any potential regression bug of "fixed"
version.
And, in quick bits 'o research, etc., there seemed to be plenty of
tech / tech security "news" and such on the matter - I figured any folks
with a more casual interest that wanted and paid attention, would likely
have seen it there, or would likely see it sooner or later anyway.
Perhaps if it had been more of a "network exploitable, this is gonna spread
and impact most everyone", I might've bothered with a prompt mention ...
but in such a case, likely others would've beat me too it anyway - and
others following upon that would probably also be commenting and correcting
misinformation/hype of those that posted first (or about the materials to
of which they quoted or to which they referenced/linked).
So, mostly not all that much to see here. Somebody did a significant
security booboo. Sometimes it's not caught/spotted for a long time.
Sometimes it's widely deployed. And when it becomes known, well, in
many cases it may be time for a prompt updating - at least where
applicable.
And don't forget - how's your mitigation strategies? How do you recover
after you've been compromised? How do you detect that you've been
compromised? E.g. Solarwinds supply chain issue, etc., that was a
particular nasty one. And, much of what made it particularly nasty is
how far reaching it's been. It got into a whole lot of places, including
important/critical ones, exploited and leveraged on a large scale - and for
many months, it went undetected - including all the various exploiting,
information gathering, network scanning, etc. I think that's the much
bigger issue on that one.
Yet another security bug in yet another piece of software - it happens.
Expect it will probably continue to happen. And yes, running less
bloated software - as feasible - and other things that improve software
quality are a good preventive. Likewise limiting network exposure,
unneeded "features", etc. But even that doesn't guarantee
immunity. Mistakes will be made, there will be bugs, there will be
security bugs. Mostly a question of how many, how often, and how bad.
And that's mostly a matter of the nature and quality of the software,
and also the checks and countermeasures and backups (and/or lack
thereof). E.g. every time I look at the bloat of bash, I shudder ...
that's why most of my scripts don't use bash, but use dash - about 1/10th
the possible code to potentially have exploitable bugs in it. Likewise
vim. Major bloat. I mostly use nvi (which is the vi on BSD systems).
Again, about 1/10th the size. How many security issues come up with
nvi? About zero (or pretty close). And, comparatively with vim?
Yeah, I see those once in a while ... probably at or more than 10x the
rate of anything like that with nvi. And so it goes.
More information about the sf-lug
mailing list