Subject: [alpine-devel] What could be done to make Alpine distribution more secure

From: Alba Pompeo <[email-masked]>
Date: Mon, 22 Feb 2016 10:16:13 -0300

A few days ago Linux Mint's website was hacked and their ISOs were
replaced with backdoored images.
This is a great security concern and I think a good opportunity for
Alpine Linux to rethink its distributions of ISOs and what could be
improved.
I'll start with the obvious HTTPS support. The download links on
http://www.alpinelinux.org/downloads/ all point to a HTTP link.
If you try to manually change it to HTTPS you get the message -
wiki.alpinelinux.org uses an invalid security certificate.
The certificate is only valid for the following names:
mail.alpinelinux.org, alpinelinux.org
The certificate expired on 05/17/15 06:04.
The current time is 02/22/16 14:11. (Error code: ssl_error_bad_cert_domain)
And alpinelinux.org also doesn't go to HTTPS by default even with
HTTPS Everywhere installed. Shouldn't it always be preferred?
What else can you think about that would make alpine distribution more secure?
The most advanced security feature I've seen a few distributions doing
is reproducible builds, but it appears to be very hard and maybe not a
priority right now. But for the future maybe it could be an idea.

Ciao.

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Isaac Dunham <[email-masked]>
Date: Mon, 22 Feb 2016 21:13:45 -0800

> replaced with backdoored images.

The most obvious precaution for this is
-sign the images
-checksum the images (ideally, sha256/sha512 and md5)
-sign the checksums
-include checksums and signatures in the release announcements
-have a link to a separately administered archive containing the
 announcement; you want some place that would have to be compromised
 separately.
 (ie, if there's a gmane archive, link there)

> wiki.alpinelinux.org uses an invalid security certificate.

HTTPS downloads will add to the CPU load, without preventing the typical
hacks.
It prevents MITM attacks when endpoint attacks are typical.
Checksums and signatures should be available over HTTPS, though.
(The security benefit proportional to the cost is greater.)

> priority right now. But for the future maybe it could be an idea.

Reproducible builds are not as hard as you'd think (says someone who spent
a few years poking at Debian packages, which were almost fully reproducible
before anyone got into that).
The fundamental requirements are:
-there must be a fully deterministic set of packages installed, if the
 build can vary based on installed packages.
 Solution: use minimal autobuilders, like Debian and Alpine do

-the configuration should be overspecified, not underspecified
 Solution: write out the config options longhand, rather than relying
 on defaults. (We're partway there.)
 This is important for cross-compiling, anyhow.

-the build options (optimization, hardening, and linker flags) must be
 deterministic.
 Solution: specify them in the build scripts and in systemwide,
 distro-provided config files, like Debian and Alpine do.

-the build ID, if provided, should correspond to the source and options,
 rather than varying with the path in which it was compiled.
 This is just a few bytes that can vary.
 Solutions:
 (a) don't build with debug flags, since gcc encodes the path to the
 source in the debug information, making the object files have a variable
 checksum. (True of some packages, but far from all.)
 (b) between prepare and build, come up with a checksum based on the
 build options and the source code checksums.
   For example:
   BUILDID=`{ find -type f -o -type l -exec shasum '{}' +
   echo "$CC $CXX $CFLAGS $CXXFLAGS $CPPFLAGS $LDFLAGS } | sha512sum |cut -c -128`

-there should be no way to circumvent the rules for build environment
 Solution: use a build server instead of package uploads, like Alpine does.

In other words:
Other than the build-id, it should be possible to reproduce Alpine packages.
And if you set up an autobuilder per the standard directions, it should
be fully reproducible.

Now, as far as running from r/o media goes (another possibility that was
mentioned)
-this doesn't prevent hacks, but only prevents adding permanent backdoors.

-this does prevent security updates without physical presence

-a 'cheap' halfway measure would be bind-mounting every path that's only
rarely written to over itself, but readonly.
This doesn't prevent someone who has a root shell from writing,
but it does prevent someone from exploiting symlink attacks or other ways
of writing to arbitrary files without shell access.

Example:
ROPATHS="/usr /lib /bin /sbin /boot /etc /var/www/isos"
for DIR in $ROPATHS; do mount -o bind,ro $DIR $DIR; done
# ... do stuff ...
for DIR in $ROPATHS; do umount $DIR; done
apk update
apk upgrade
for DIR in $ROPATHS; do mount -o bind,ro $DIR $DIR; done

Note that a few scripts may need adjustment to work with RO /etc.

Thanks,
Isaac Dunham

---

---

From: Alexander Dahl <[email-masked]>
Date: Mon, 22 Feb 2016 15:00:37 +0100

Hei hei, 

> What else can you think about that would make alpine distribution more secure?

One thing better than with Linux Mint is already present: PGP signed
images. This would be even better if the signing key had some more
trustworthy signatures, but it's a start. :-)

Greets
Alex

-- 
»With the first link, the chain is forged. The first speech censured,
the first thought forbidden, the first freedom denied, chains us all
irrevocably.« (Jean-Luc Picard, quoting Judge Aaron Satie)
*** GnuPG-FP: C28E E6B9 0263 95CF 8FAF  08FA 34AD CD00 7221 5CC6 ***

---

---

From: Natanael Copa <[email-masked]>
Date: Tue, 23 Feb 2016 10:59:39 +0100

On Mon, 22 Feb 2016 15:00:37 +0100

> trustworthy signatures, but it's a start. :-)

At least you know it is the same person who make every release. (or
someone who has access to the private keys)

-nc

---

---

From: Der Tiger <[email-masked]>
Date: Mon, 22 Feb 2016 19:19:54 +0100

Hi Alba,

> http://www.alpinelinux.org/downloads/ all point to a HTTP link.
Going SSL won't give the downloader any relevant additional security,
since the connection between the server and the downloading client isn't
a likely point of attack. Such a Man in the Middle attack is far too
much effort only to corrupt the transferred ISO image. It is much easier
to take the same approach the Mint hackers took, and attack the website,
directly. SSL won't help your there.

To make the website hacking-proof, the entire content would have to be
on a physically read-only medium (e.g. DVD-R), but I doubt any admin to
be willing to handle such hassle.

> mail.alpinelinux.org, alpinelinux.org
The Alpine website uses several sub-domains and the certificate would
therefore have to be a wildcard certificate in order to be valid on all
sub-levels. Those wildcard certificates are considerably more expensive
than any generic certificate.

> HTTPS Everywhere installed. Shouldn't it always be preferred?
Only, if you can trust the server certificate and you want to transfer
data, that would give any listener valuable information. SSL does
neither hide your IP address, nor your connection state. Surfing the
Alpine website and downloading an Alpine ISO hardly counts as valuable
information.

SSL only hides (too some degree) the information inside the connection,
but not the connection itself. To accomplish a fully encrypted
connection, you need tools like VPN. Furthermore, most certificates can
be faked, spoofed and even most certificate authorities (CA) are not to
be trusted, if it comes to critical data. The entire certificate system
has already collapsed due to the system requiring all CAs to be
trustworthy. If one CA fails, the entire system falls apart. And today,
there are more untrustworthy CAs than trustworthy ones.

Offering checksums to every downloaded file does only verify the file's
consistency with the original file, but does not prevent any tampering
with the files stored on the server. Because, lets face it, if someone
is able to hack the website and replaces the downloadable files, he/she
is certainly qualified to modify the online displayed checksums,
accordingly.

The only way known to me to ensure the file contents validity is to
offline encrypt the file with a private key and hardcode the public
de-cryption key into the static part of the website. Any modifications
to the file alone lets the de-cryption fail, while the public key can't
be modified without locally accessing the web sever.

Regards,

Tiger

---

---

From: Natanael Copa <[email-masked]>
Date: Tue, 23 Feb 2016 11:02:53 +0100

On Mon, 22 Feb 2016 19:19:54 +0100

> be willing to handle such hassle.

We don't use any web application server for main website. It is
generated static pages. So you will not be able to exploit some
wordpress vulnerability to hack the site.

> than any generic certificate.

letsencrypt might be an option.

> be modified without locally accessing the web sever.

We cryptographically sign the content of every package (public keys are
in /etc/apk/keys). So we do verify that the package content is not
tampered with.

If you also check the pgp signature of the iso image, then you can be
relatively sure that the content you get is the the same as was
generated on the build servers, regardless if you get it over encrypted
transport or not.

-nc

---