Addressing reported MITM RCE
We recently received a support email notifying us about a report to the oss-sec mailing list entitled “Travis CI MITM RCE”.
This notice came nearly a year after the post’s author, Jakub Wilk, contacted us via email about issues with the APT package integration implemented in travis-build. I would like to publicly thank Jakub Wilk for the investigative work and desire to improve Travis CI’s offerings, and offer our apologies for not communicating our actions and intentions in a timely fashion.
With that said, I would like to provide some clarity about the current status of the issues Jakub described and what we are changing in response.
The report clearly shows that if an attacker were able to MITM the traffic coming from an APT source and GnuPG key download URL, then arbitrary code could be executed within a given job. Executing arbitrary code in this way could be used to expose or extract secrets present in the job execution environment. This type of secret is commonly present when using one of the deployment providers.
In response to Jakub’s findings, we are now storing public GnuPG keys on GitHub and fetching them at job execution time over https from the travis-build web server. Based on our current analysis and understanding, we assume that none of our users have been exposed to an attack, but we are investigating further.
We have also addressed a bug in the APT version detection used to decide which
options to use during
apt-get install. The intended behavior since October
20171 has been to use the
--allow-change-held-packages options. Thanks
to Jakub’s report, we found that the detection code contained a
>= operator was intended. This means that between early July and
August 28th, all jobs using the APT packages addon were erroneously being run
While not directly related to the report, we are currently reviewing the
restrictions in container-based Linux. If we remove them, this will mean that
the APT addons and the associated safelists would no longer be required.
I am looking forward to posting an update about this and other relevant changes in the near future, and in the meantime I encourage any interested parties to reach out to us via our security email inbox.
1: It was in late September of 2017 that the rollout of Trusty as default was completed.