[sf-lug] Linux Mint iso files hacked.

Rick Moen rick at linuxmafia.com
Sun Feb 21 16:52:03 PST 2016


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.

1.  SSL for the Web site wouldn't have adressed this current threat model,
especially given that the actual downloads are on a large number of
public mirror sites.  (HTTPS is a good idea on its own merits, but would
not have prevented this attack.)

2.  They do post signatures for the checksums of their ISOs, but they've 
been sloppy about it.  And although Clem's signing key for those 
signatures is in the public gpg keyservers, it isn't well attested.
(Near as I can tell via a quick check, there's no chain of trust to 
follow.  I could be missing something.)

I hope the recent WordPress PHP compromise is a sufficient wake-up call
to motivate them to address point #2 above.

As you'll see in my separate post, I gave Clem a polite kick about that.

> Even where they post about the compromise:
> http://blog.linuxmint.com/?p=2994
> The give no trust path to the hashes (and egad, still using md5sum, at that).

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.

> And ... only 1024D?  

That might be a matter of when the key originated.  Until fairly
recently[1], DSA public key encryption was limited to 1024 bits.
By comparison, RSA key length was never limited, so one has always been
able to generate much stronger RSA keys than DSA keys -- which IMO is
one of many reasons to prefer RSA.  (About all DSA ever had for it was 
patent avoidance, and that went away when the RSA patent expired in
2000.

 
> And is there trust path to the signing key?

Probably not.  But they've done a terrible job of even providing public
information about how to get the checksum matching the signature, and
the public key matching the signature.  Seems like the biggest problem,
to me.

[1] NIST defined DSA in fips 186-2 with a 1024-bit limit in the
standard, but that has been superceded twice, the current revision being
fips 186-4, http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf.
I'm not sure when that change occurred, but probably not too many years
back.  FWIW, current revision fips 186-4 is dated July 2013.





More information about the sf-lug mailing list