
Remote Code Execution in Alpine Linux - justicz
https://justi.cz/security/2018/09/13/alpine-apk-rce.html
======
justinsaccount
> When apk is pulling packages, it extracts them into / before checking that
> the hash matches what the signed manifest says it should be.

Pros: downloading and installing packages is faster.

Cons: vulnerabilities like this.

Reading the commit message in [https://github.com/alpinelinux/apk-
tools/commit/6484ed9849f0...](https://github.com/alpinelinux/apk-
tools/commit/6484ed9849f03971eb48ee1fdc21a2f128247eb1) I'm not convinced they
fixed it.

~~~
justicz
Just to preempt some replies to this I can already picture: if you find more
bugs, please report them to the maintainers I mentioned in the post and not
via an HN comment!

~~~
justinsaccount
Of course :-)

------
alpb
> This is especially bad because packages aren’t served over TLS when using
> the default repositories. This bug has been fixed and the Alpine base images
> have been updated [...]

Do I understand this right: They fixed the apk vulnerability but the packages
are still downloaded without TLS in default repositories?

~~~
Sir_Cmpwn
I'm usually the first to step up to the plate and insist on HTTPS, but it's
not actually necesary here. The packages are PGP signed, and the public keys
are established securely at install. This is actually more secure than SSL imo
because it uses web-of-trust for key exchange rather than easily compromised
certificate authorities.

~~~
icebraining
I don't disagree that SSL/TLS doesn't add much security (though it does
provide privacy regarding the packages being pulled), but don't conflate it
with the CA system; they could just as easily pin the SSL/TLS cert at install.

~~~
Sir_Cmpwn
Fair point, but this would still be less secure. Packages are generally signed
by individual maintainers and as maintainers come and go, the trusted keyring
evolves. It also puts the power of signing packages directly into the hands of
maintainers, rather than granting access to a single all-powerful private key.

~~~
iancarroll
I don't think anyone is arguing that you should replace PGP signing with
HTTPS.

~~~
Sir_Cmpwn
I don't think that anyone is arguing that, either. I'm saying adding HTTPS
isn't an improvement.

~~~
vlovich123
And yet the existence of this exploit, which would have been prevented with
HTTPS as I understand, counterproves your point. There's a reason security
engineers advocate for defense in depth; even if one system fails you have a
higher likelihood of preventing any issue or perhaps at least mitigating the
scope/severity because other systems are still there. Self-signed HTTPS certs
seems about as safe & secure as self-signed PGP packages so how can having
both in any way reduce the overall security.

~~~
Sir_Cmpwn
"The existence of an exploit" will undermine literally any system and you
can't meaningfully use that argument.

~~~
moosingin3space
"The existence of an exploit" is an argument in favor of defense-in-depth
techniques, as an exploit in one layer does not result in full-system
compromise.

------
malikolivier
The author launched a bug bounty program for open source projects:
[https://bountygraph.com/](https://bountygraph.com/).

That's a wonderful endeavor and I would gladly try to "convince" people I know
to pledge money in it.

Monetary incentives are important for open source maintainers, as they cannot
always afford the time to work on their projects.

~~~
crispweed
I don't know exactly how that bug bounty program works, but it feels like
there may be some fundamental issues with bug bounties in the context of open
source projects.

For example, what is there to prevent someone from introducing a bug into an
open source project, first of all, and then subsequently claiming a bounty for
identifying and/fixing it?

(Maybe this can end up by forcing more careful pull request auditing for
security critical projects, but that seems like a big ask..)

------
ollieparanoid
@justicz: that's one clever hack, thanks for explaining in detail how it
works!

In case somebody is wondering about Alpine Linux based postmarketOS, this is
what I wrote on /r/linux regarding this issue:

postmarketOS is directly using Alpine's apk-tools package from their
repositories, so a simple "apk upgrade" will install the latest apk version
where this is fixed.

Regarding the pmbootstrap tool we are using for development to set up Alpine
Linux chroots, just update to the latest git version with git pull as usually,
and it will make sure that the apk version is installed where this is fixed
before you can use any of the chroots. Pulling from git may seem strange, but
we do not have a stable release yet for pmbootstrap, so this is the normal way
to update the code anyway. We're getting closer to a stable release of
pmbootstrap though.

------
btmiller
I can only think about this and be fearful due to the staggering number of
Docker tutorials that happily whisk away the details as a sales pitch for
streamlining the development process. Similar to the Node ecosystem, there's
bound to be lots of junk out there that will never be updated.

~~~
swingline-747
Docker containers multiply faster than rabbits in a forkbomb. It behooves
Docker to do vulnerability and malware scans of containers, because letting
random people have semi-sandboxed write and execute permissions on random
other people's systems is a dangerous combination. That will cover some cases,
but end-to-end personal accountability of container publishers is a necessary
evil as there is unlikely a reasonable technical way to ensure there aren't
malicious scripts in a given docker container. Signature-based malware
scanning operates only in a limited fraction of the past since it requires
submittal and review of what has been seen by a particular user AND submitted
to a malware scanner publisher for analysis.

Scenario: Anonymous docker publisher installs a kiddie porn i2p or tor
downloader service hidden in a container for Apache Kafka. Random corporate
trainer accidentially picks said container, blogs a howto with it and suggests
its use in in-person and web-based courseware. IANAL but Who's liable? The
end-users using it? The trainer? Docker?

Disclaimer: I love Docker, but it needs some chain-of-custody assurance and
greater visibility of container contents.

~~~
zerotolerance
Docker ships with support for image signing, execution authorization (based on
trusted signatures), and distribution endpoint authentication (TLS / PKI).
Most image registries offer deep package inspection, OSS package manifests,
and CVE visibility.

If all that isn't enough, individual image layers can be accessed and
inspected by hand (they're just tar files).

If you're looking for "end-to-end chain of custody" you're going to need to
specify the ends. Image signatures get you point-in-stack authorship
assertions. I'm not sure what else anyone could ask for here.

------
monksy
Isn't that the distro that the jre docker containers use as the base?

EDIT: Just looked into that.. it looks like just the java 8 containers.

~~~
atmosx
Alpine is a popular choice for containers because it has very small footprint.

------
tedunangst
Looks mostly avoidable if O_NOFOLLOW had been used? But the fix doesn't seem
to add that, instead relying on other checks?

------
efiecho
It seems like the attack is not completely quiet as an error is printed while
installing a modified package, either from compromised mirror or by man-in-
the-middle:

    
    
        ERROR: ${package_name}: BAD signature
    

Remote code execution will happen, but at least you will get a warning that
something suspicious is going on.

~~~
owl57
That is even red and there's no obvious way for the attacker to disable that.
But do people really look at the build log as long as the build is successful
and the intended containerized program seems to work just fine?

~~~
rmetzler
Maybe it's possible to overwrite already printed lines with terminal
sequences.

------
ris
People really have to stop thinking they can write package managers.

~~~
interfixus
This is a bummer, clearly. Otherwise, apk is pure joy to work with, as is
indeed all of Alpine.

