Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Sat, 25 Aug 2018 23:49:23 +0200
From: Jakub Wilk <>
Subject: Travis CI MITM RCE

Travis CI <> is a popular continuous integration 
service used to build and test software projects hosted at GitHub. 
(Travis itself is free software, but the primary reason I'm writing this 
is mail is that the service is used by many free software projects.)

I discovered multiple bugs in the way Travis CI uses APT and GnuPG that 
defeat the package authentication mechanism. As a consequence, the bugs 
allow man-in-the-middle attackers to execute arbitrary code in the 
context of a Travis build that uses the APT add-on.

This is probably not a big deal if use Travis CI only for running tests.  
But Travis also supports deployment (grep for “Deployments and Uploads” 
on <>); if you entrust Travis with any 
secrets, this is bad news for you.

Here are the bugs details:


1) On 2015-04-13, the “--force-yes” option was added to apt-get 

This option name doesn't sound very dangerous, but it makes APT assume 
the “yes” answer to all questions, including the question about 
installing packages that couldn't be authenticated…

On 2017-10-12, I reported this bug to the Travis CI security team.

On 2018-07-05, --force-yes was replaced with --allow-downgrades 
--allow-remove-essential --allow-change-held-packages:

I'm not sure how could this change possibly work, because APT in the 
Ubuntu versions Travis CI supports (precise, trusty) doesn't have these 
options… So a few days later --force-yes was added back:


2) On 2017-10-12, code was added to refresh an expired signing key:

The code used 32-bit key ID to retrieve the key from the keyserver. 
I reported this on 2017-12-06:

My patch was not accepted. Instead, more generic code to refresh expired 
keys was added:

The new code looks like this:

    apt-key list | awk -F'[ /]+' '/expired:/{printf "apt-key adv --recv-keys --keyserver %s\\n", $3}' | sudo sh

The “apt-key list” format varies with GnuPG version, but on Ubuntus 
Travis supports, it uses… 32-bit key IDs.

(For extra fun, this code happily executes code embedded in user IDs. 
I don't believe this is exploitable on Travis CI, though.)

Apparently some joker already exploited this bug to add their own key to 
the APT keyring <>:

   $ apt-key list | grep -A1 -w A15703C6
   pub   4096R/A15703C6 2016-01-11 [expires: 2020-01-05]
   uid                  MongoDB 3.4 Release Signing Key <>
   pub   1024R/A15703C6 2016-06-25
   uid                  Totally Legit Signing Key <>

I can neither confirm nor deny that it was me. It might be a mere 
coincidence that I wrote a tool to brute-force 32-bit key IDs:


3) For many repositories in the APT source whitelist 
<>, the signing key is 
downloaded over HTTP. For example:

    "alias": "cassandra",
    "sourceline": "deb \"\" 39x main",
    "key_url": ""

Jakub Wilk

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.