<div dir="auto">Rick, absolutely right. Features you do not implement do not have bugs. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 4, 2024, 9:43 PM Rick Moen <<a href="mailto:rick@linuxmafia.com">rick@linuxmafia.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Quoting Ron / BCLUG (<a href="mailto:admin@bclug.ca" target="_blank" rel="noreferrer">admin@bclug.ca</a>):<br>
<br>
> It cannot be overstated how devious this hack was!<br>
<br>
Yes.  The technical details are impressive and twisty.<br>
It was very stealthy in execution and well hidden in design -- really a<br>
masterclass in how to do something covertly in a way well hidden against<br>
scrutiny.<br>
<br>
> It cannot be overstated how devastating this hack would have been.<br>
<br>
Yes.  Almost all the world's Linux servers (the ones reachable in public<br>
via SSH) getting coverly rooted, even for days, would have been<br>
catastrophic.  And we really did come pretty close.<br>
<br>
Also, it's still not completely clear what else the successful bits<br>
allowed the unknown attackers into, or what other similar projects they<br>
or others have or had.<br>
<br>
> It cannot be overstated how lucky we all are that Adreas just happened<br>
> to be testing at the right time, noticed delays of *under* ½ second on<br>
> failed logins, and despite it being outside his area of expertise,<br>
> decided to look into it further.<br>
<br>
Andres has given an appearance on a security podcast, BTW.<br>
<a href="https://risky.biz/RB743/" rel="noreferrer noreferrer" target="_blank">https://risky.biz/RB743/</a>  He's hilariously on-type.<br>
<br>
> We'll have the discussion, then carry on as we are currently.<br>
<br>
Probably.  But:  I know this is talking big, as I haven't exactly made<br>
tracks on this larger project, but while thinking about next-gen system<br>
software for my server, I've often thought I need do better at applying<br>
the lessons of my Ops / InfoSec background.  And one of my recurring<br>
frustrations with commodity distro packaged software (especially but not<br>
limited to binary-package distros) is security-critical, public-facing<br>
software being overfeatured by selection, by configuration, and by<br>
choice of compilation options.<br>
<br>
Let me back into what I'm thinking about.<br>
<br>
Some years ago at $FIRM, an important part of my job was to be one of<br>
two senior sysadmins for a semi-autonomous division functioning as a<br>
"merchant bank".  In the USA tech field, that is a term of art meaning <br>
"credit card transaction processor for e-commerce".  Other companies'<br>
public-facing online "stores" could back-end into $FIRM's "merchant<br>
bank" to accept and process the card charges.<br>
<br>
All merchant banks must periodically (every 6 mos., if memory serves)<br>
pass "PCI testing", the Payment Card Industry assocation's Payment Card<br>
Industry Data Security Standard (PCIDSS) security-quality testing.  And<br>
I was the lucky sod who had to shepherd our farm of CentOS-based servers<br>
through that periodic process.<br>
<br>
PCIDSS testing was, in a way, a little lame.  A chosen PCIDSS testing<br>
vendor would, twice a year, port-scan your IP netblocks with some<br>
secret-sauce perl script, making guesses based on fingerprinting of what<br>
public-facing software comprised your public attack surface, and then<br>
you as the customer (and I as the fix-it guy at the customer) would get<br>
a report saying "Hey, our probe claims you're running Foo daemon version<br>
XX.YY.Z rev. A, so kindly prove to us that your implementation isn't<br>
vulnerable to the following CVEs...."  And each of those would be a CVE<br>
that _might_ apply to Foo XX.YY.Z rev. A.  (Likewise for other<br>
software.)  My job would be to prove to the vendor that our site<br>
_lacked_ that possible vulnerability, either because we'd upgraded to<br>
CentOS update this-or-that, or because we'd specifically disabled that<br>
functionality entirely in /etc/foo/*.conf .  <br>
<br>
Sometimes, the vendor's claim would be one of many bizarre types of<br>
false positive.  Then, my job was to explain why their script had been a<br>
prat and was mistaken.  Either way, my explanations (rarely, after<br>
rolling out some upgrades or conffile mods) would be sanity-tested by <br>
some functionary, and (at the end) accepted as a "pass" for 6 months.<br>
<br>
It worked well enough, and we never had security incidents -- to our<br>
knowledge, at least.<br>
<br>
Getting back to distro software choice and packaging:  The "every<br>
possible use-case must be supported out of the box" syndrome is<br>
dispiritingly ubiquitous.  Some stuff is compiled into a daemon binary <br>
even though almost nobody will use it, just because someone might.<br>
Why is Apache httpd almost always the default, rather than Lighttpd,<br>
nginx, sthttpd, or Hiawatha?  Because its big dumb software that does<br>
everything, that everyone's used to.<br>
<br>
$FIRM ran Apache httpd, but many PCIDSS complaints got finessed by<br>
sending them our conffiles where various buggy features were<br>
specifically disabled.<br>
<br>
Network Time Foundation's NTP Project software, used by damned near all<br>
server-oriented distros by default, is likewise big dumb software that<br>
does everything, that everyone's used to.  OpenBSD Foundation's OpenNTPd<br>
was founded with the specific aim of avoiding NTP Project's featuritis, <br>
and has succeeded (with only minor cavils).  Red hat's Chrony is a<br>
similar story.<br>
<br>
I'm sure you get my point:  You get a smaller attack surface by choosing<br>
security-relevant software with minimal unneeded servers coded in, and if<br>
possible further cut back on unwanted functions in the runtime config.<br>
<br>
And, last, there are times you want to rebuild a distro package from<br>
source to use different compile options.  For daemons, this can be a<br>
reasonable local admin burden, depending.  For example, imagine I were <br>
looking at the (newest) Debian Portable OpenSSH package's dependencies,<br>
and said "Eh?  Needs liblzma.so.5?  I don't need that.  I don't _want_<br>
that."  I'd check, and find that the package got compiled to require it,<br>
in order to be able to report service-readiness to libsystemd -- which <br>
I would not have any interest in, therefore compiling a local OpenSSH <br>
package with that compile-time option disabled would do the trick.<br>
<br>
But Portable OpenSSH isn't the only choice, either.  There are respected<br>
SSHDs that are _much_ smaller/lighter with a smaller attack surface,<br>
like Dropbear and wolfSSH.  "But they're less well known!"  Do I care?<br>
Hell no.<br>
<br>
Anyway, it seems to me that substantial improvement can be made on a<br>
local system through active system administration, picking wiser choices<br>
of software packages, paring down configurations, and in some cases<br>
compiling locally to reduce runtime dependencies.<br>
<br>
All of which is only a _little_ helpful against insider threats such as<br>
"Jia Tan", whoever that was.  But OTOH shying away from big dumb<br>
software and featuritis can help defang even the Jia Tans.<br>
<br>
> There's been some interesting analysis of the timestamps of JiaTan's git<br>
> commits showing odd patterns.<br>
> <br>
> Jia claims to be from California (GMT -8) but timestamps tended to be<br>
> GMT +8 - same as Singapore.<br>
> <br>
> Many commits were GMT +2 or +3 (DST dependent), pointing to Eastern Europe.<br>
<br>
APT29 aka Cozy Bear is a popular guess.<br>
<a href="https://en.wikipedia.org/wiki/Cozy_Bear" rel="noreferrer noreferrer" target="_blank">https://en.wikipedia.org/wiki/Cozy_Bear</a><br>
<br>
The list of possiblities is very broad, though.<br>
<br>
-- <br>
Cheers,             "Are you sure it’s that simple?  After all my time here, <br>
Rick Moen           I’ve yet to see any problem, however complicated, which <br>
<a href="mailto:rick@linuxmafia.com" target="_blank" rel="noreferrer">rick@linuxmafia.com</a> when you looked at it the right way, didn’t become still <br>
McQ! (4x80)         more complicated."     -- Poul Anderson, in "Call Me Joe"<br>
<br>
_______________________________________________<br>
conspire mailing list<br>
<a href="mailto:conspire@linuxmafia.com" target="_blank" rel="noreferrer">conspire@linuxmafia.com</a><br>
<a href="http://linuxmafia.com/mailman/listinfo/conspire" rel="noreferrer noreferrer" target="_blank">http://linuxmafia.com/mailman/listinfo/conspire</a><br>
</blockquote></div>