[conspire] computer security

[Michael Paoli]

> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [conspire] computer security
> Date: Tue, 9 Mar 2021 15:56:29 -0800

> useless:  It takes for granted that any user will blithely install & run
> software for nowhere-in-particular written by nobody-in-particular
> (and probably do so with system privilege) _because_ that is the
> cultural norm among MS-Windows users.

Yep, key/common with Microsoft Windows.  So much of the typically
needed software comes from other than Microsoft, that the
user(s)/administrator(s) generally need effectively, if not literally,
trust a whole lot of 3rd party software suppliers/authors beyond
Microsoft itself, with their software and operating system.  Compare
that to typical Linux distros, where generally all or nearly all of the
software that one would typically need, want, use, and have installed
or install, typically comes from and is provided by that particular
Linux distro itself - so the software is, at minimum, at least vetted
and generally reasonably checked by that distro, before the distro
packages it and makes it available through the distro for folks to
install.

> There's nothing inherently particularly secure about Unix; never was.

Could quibble over finer points, but yeah, there's no "magic pixie
dust" in Unix/Linux/BSD/*nix that inherently makes it secure or much
more secure.  I would, however, point out, that in addition to common
practices, there are some things that typically make Unix, etc., more
secure than, well, compared to Microsoft operating systems.  Most
notably, Microsoft has a huge set of backwards compatibility and legacy
code running capabilities and APIs, ... many of which really are
significantly not secure.  And to Microsoft's credit, they've been
increasingly, over they years, though generally not fully disabling
such backwards compatibility and hazards in those much older legacy
bits, been generally further isolating and containing them, so, e.g.,
if one wants to run ancient MS-DOS 3.3 stuff on, say, Windows 10, ...
sure, ...  can probably sort'a kind'a mostly still do that ... but it's
generally going to be relatively sandboxed off into some
"compatibility" environment, rather than having unfettered access to
the entire operating system.  So, still some more exposure there ...
but not as big/huge as it was.  But even on the Unix, etc. side,
generally quite backwards compatible ... run old/ancient no longer
supported code, it may have security issues ... and even with
Microsoft, it's more likely to be effectively sandboxed ... Unix etc.
doesn't necessarily automagically do that or force one to do that
if/when runs crusty old unsupported code ... though the typical ID,
etc. isolation (e.g. not running it as root, etc.) may give a fair
degree of protection ... and using suitable ID(s) might be comparable
(+-) to Microsoft's sandboxing.  And, there are architecture/design
differences between Unix, etc. and Microsoft operating systems, that
typically make Unix, etc. fair bit easier to reasonably well secure and
maintain that security ... but that doesn't automagically ensure one's
Unix, etc. installation/configuration is rather to highly well secured.
But the more common practices, etc., Unix, etc. tends to be better
secured, and administered ... but not really a whole lot (if anything?)
that makes it inherently (much) more secure.  There are, however,
additions to, e.g. Linux, that can make it more secure ... at least
if/when properly utilized.  E.g. AppArmor, SELinux, etc.  But, at least
somewhat likewise, Microsoft, there's no shortage of add-ons and
practices, etc. that can generally at least quite help to make it more
secure and/or even quite a bit lock it down.  So again, not exactly
some huge difference there, and also quite different general approaches,
so one can't exactly do an apples-to-apples comparison.

> Quoting Paul Zander (paulz at ieee.org):
>> I recall a few years back that a major Linux repository was hacked.

> No, I'm betting you didn't.

Well ... sort'a kind'a yes ... and no(!).  In most (/ (nearly) all(?))
such cases with at least major/significant Linux / Open Source
repositories, yes, in some cases things have been compromised ... but
relatively slightly, most notably, in most cases, the packages/software
are securely digitally signed/authenticated - directly or indirectly,
such that intruder/"hacker" won't be able to subvert that, and at least
for the most part, anybody / anything (and most typical package
management software will do so) that bothers to check, will detect the
tampering, and generally refuse to use such tampered with, or not
properly securely signed and authenticated by/from the appropriate
trusted party(/ies) ... so such "hacks" generally don't get very far
and are also generally detected in relatively short order and then
generally cleaned up and corrected (including also generally correcting
however the compromise occurred), in relatively short order.

And ... "worst" such case? ... well, at least that I can think of -
though I think even it was discovered and corrected in relatively short
order.  Linux Mint.  Though no longer the case, some number of years
back, Linux Mint did not so sign their ISOs ... directly nor
indirectly.  There was no trusted secure path to validate the ISOs and
that they'd not been tampered with (or compromised in transmission).
And likewise, though not as strong, there wasn't even a secure https
path to such ISOs, as the site(s) didn't even offer https.  Every time I
looked at that I was like, "Yeah, ... I can't take a (Linux) distro
seriously if they can't even be bothered to do that" ... especially
since, at least by then, they certainly ought to have known (and done)
better.  And, not only did I point this out to them that they ought fix
it
https://blog.linuxmint.com/?p=2361#comment-93804
but other(s) had also earlier pointed this out to 'em and called it
to their attention.  And their response was essentially, "Yeah, not
gonna bother, not a concern, don't worry about it.".  Well, within a
couple years or so, ... their site got "hacked", and ISOs and/or other
data on their site compromised ... "oops".  Who could'a ever
guessed/predicted that?  Yeah, ... right.  Well, *after* that happened,
they finally got their sh*t together and started doing appropriate
digital signing (directly or indirectly) of their ISOs.  I mean after
all, their ISOs were the only means of initially getting and installing
their software (or at least kicking off that process), and they offered
no alternative means to securely do that.  In any case, I believe that
compromise was detected and corrected in relatively short order.  But
it probably got a wee bit further with the less than quite aware users,
notably due to the lack of any such digital signing.

> As mentioned downthread, some source tarballs at kernel.org were
> trojaned briefly during the famous incident, _but_ that did not succeed
> in infiltrating the kernel git repo, where all check-ins are
> SHA1-signed, and even compomise of hosts holding the repo could not
> suffice to break the repo-hosted source integrity.
>
> That was a shell-level breakin via a stole key from one kernel dev, that
> permitted the host compromise.  If memory serves, the suspect tarballs
> did not validate to signature hashes, by the way, so _even_ people who
> checked out Linux kernel tarballs instead of doing git pulls had the
> means readily at hand to detect the brief fraud.
>
> Likewise, when a zero-day kernel exploit got used to briefly take over a
> couple of Debian Project hosts and a couple of Gentoo Project ones, the
> intruders were not able to compromise crypto signed distro package contents,
> for pretty much the same reasons.

Yep ... one of the ones I also recently pointed out - though it
happened quite a while ago.  In the Debian case, things properly
digitally signed and such, so no major impact, and quickly detected.
And I compared that to SolarWinds ... Debian detected and corrected the
issue in under 29 hours.  SolarWinds took well over 29 *weeks*(!) to
even know they had a problem and were compromised, ... and they never
even detected it themselves, but eventually someone else detected the
compromise and called it to their attention.  See my earlier at:
https://groups.google.com/g/berkeleylug/c/mrcpBK37EEM/m/mnhZmDVHBAAJ
Not that all Closed Source producers are so horrible at that, but
SolarWinds majorly screwed up on that one - with it being such a nice
fat juicy security important/critical bit 'o software, and
significantly/widely used, and the issue having gone undetected for so
very long ... and of course bad things happened ("oops").  Not that I'm
a Microsoft fan, but when goop like that occasionally happens to
Microsoft (at least within their own software on their own sites), at
least they generally detect and correct it in reasonably short order,
and I think nowadays (and probably for some fair while now), they
generally have their software securely digitally signed, at least for
the most part, one way or another.

> http://linuxmafia.com/~rick/faq/ lists very similar incidents where
> shared hosts got rooted that hosted dev trees / tarballs of the
> following codebases that are or were frequently used on Ix:
>
> o  Wietse Venema's TCP wrappers
> o  sendmail
> o  SquirrelMail
> o  ProFTPD
> o  vsftpd
>
> In every case, PGP-signed checksums were either suspiciously lacking for
> the trojaned replacement tarballs, or failed to validate, thus making
> the (brief) forgeries easy to spot.

Yep, so, properly digitally signed, and such signatures generally
used/validated, such tampering is generally detected in short order,
and is mostly a non-issue.

> Of course, if you naively download upstream source code (why?) and
> naively ignore code-signing (why?), then you might have gotten bitten
> during the brief period before the dev noticed and corrected the
> host-level compromise.  But then, as my saying goes, you have bigger
> problems.
>
> As pointed out on my (above-cited) anti-virus software for my Linux
> page, if you are terribly, terribly worried about compromise of software
> distribution chains on Linux distributions, then you are going to be
> _really_ frightened when you hear about the risks you face with
> proprietary software and platforms, as they are rather more
> considerable.