[sf-lug] Linux Mint iso files hacked.

[Michael Paoli]

> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [sf-lug] Linux Mint iso files hacked.
> Date: Sun, 21 Feb 2016 16:52:03 -0800

> Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):
>
>> One of the things that has always caused me to not consider Linux Mint to
>> be a "serious" Linux distribution, is they *never* established a
>> trust path to their ISOs!  Sure, they'd put a hash of the ISO on their
>> web site.  But not even SSL for the web site, and no signature for the
>> ISO file.
>
> The relative weakness of md5 hashing is the tiniest part of this
> problem, and trivia by comparison.  When your security is so tight that
> it's worth your time to worry about exploitable md5 hash collisions,
> you've done well indeed.  A much bigger problem, IMO, is that they
> omitted the stronger sha256 hashes from the main download page --
> suggesting a slapdash attitude to verification and integrity-checking
> generally.

Yes, you make good points about the relative (un)importantce of the
various pieces present - and missing.  Perhaps I was quite meaning to
imply, but didn't explicitly state, more generally their relatively
lackadaisical (in)actions regarding assurances of the integrity of
ISO downloads.  Their attitudes/(in)actions always seemed to strike
me as, approximately, "We threw it up there, here's an unsigned hash
that's enough for you to check if it got corrupted, so long as nobody
does anything nasty.  And, well, we're not going to worry too much
about if somebody does something nasty."  Now they're trying to play
catch-up, and fix/address what should've been done much earlier.
It's not like I and others hadn't given them sufficient prodding
on it earlier, e.g.:
http://blog.linuxmint.com/?p=2361#comment-93804
I also found their response at the time quite unsatisfactory.
Sure, the response gave link to location that had a hash and detached
signature for that hash - but alas, it was not for the production version
they were distributing, but some beta version with a different hash.
This was pretty consistent with what I'd seen before - they just couldn't
be bothered, though they certainly ought know better.  And yes, now folks
are (relatively) beating them over the head with the point I, and many others
made earlier, and after they've now been twice compromised in short order,
they're getting many reminders from lots of folks on these points.  If only
they'd properly addressed it much earlier - but they didn't (and still haven't
quite covered it, last I peeked.).  And also, like you, I tried to see  
if there
was any trust path to the key they use for signing - I've yet to find such a
path (the couple tools I've checked on also fail to find a path, some  
also reporting
that the key is not in the "strong set" - implying it's relatively  
small isolated
unconnected set - which isn't exactly worthless for signing, but is a  
relatively poor
and rather suspect place to come from - especially for a signing key  
for what is or
wants to be a significant, or even "major" Linux distribution).

And ... https?  Yes, wouldn't have done anything for *this* particular  
issue, but
does generally thwart *other* problems.  The general complete lack of  
that *also*,
I found pretty consistent with their, "What, me, worry?" attitude  
towards security -
or at least reasonably well ensuring the integrity of the iso  
downloads - which left
me very wholly unimpressed by Mint.  And yes, as you pointed out, even  
when the
clueful find it difficult to unfeasible to come up with trust path to the ISO,
I consider that  "fail" for a distribution that is or wishes to be a quite
significant Linux distribution.  Heck, even some distributions that are pretty
much a one person operation - e.g. Knoppix - has no difficulty whatsoever to
properly get the data out there to make trust past to assure the  
integrity of the
iso very easy to check and verify and get such assurances.  Yet Linux Mint
just hasn't really bothered ... well, ... now maybe finally they'll bother to
get around to actually doing that much more properly.

Yes, they were relatively lucky - issues fairly quickly detected by  
... gee, we've got
lots of copies of the hash out there, and folks are noticing suddenly  
some of 'em
don't match to the ISOs, or they match, but the ISOs now have  
different hash value on
the site that doesn't match what it was earlier, gee, what's up with  
that?  And
the download locations are now pointing to *where*?  Uhm ...
Well, much better than not being detected, but the detection should've  
been more like
WTF is up with your site?  There's no longer trust path from an  
assured/known key to
your ISO images.  Did you not get those properly updated signed and  
uploaded, or has
your site and upload locations it points to been had?  Essentially it  
should've been
the case that anyone who bothered to check would quite instantly know  
something was
not right - but appears they didn't take the proper steps to ensure  
that such would be
definitely caught, but rather relied upon (or more like fell back on)  
the community
noticing some discrepancies between current site and current site  
download locations,
and some of the earlier published data (gee, that seems like it might  
be a little odd).

Best detection of compromise: automated checks detect and alert of it  
- one knows of
the issue, if not "instantly", at least in short order.  Not quite so good
detection: Yo, dude, looks like you're site's been had.  Of course  
too, there's
yet worse, like "oops, our site and data and intergrity was had many  
months or more
ago, ... but we're just starting to realize that now", or worse yet,  
along with that,
"but we won't tell anybody about it.".