Re: Travis CI MITM RCE

[Jakub Wilk <jwilk () jwilk net>]

Response from Travis CI:
https://blog.travis-ci.com/2018-08-29-addressing-reported-mitm-rce

Some clarifications:

* Jakub Wilk <jwilk () jwilk net>, 2018-08-25, 23:49:
> On 2018-07-05, --force-yes was replaced with --allow-downgrades 
> --allow-remove-essential --allow-change-held-packages: 
> https://github.com/travis-ci/travis-build/pull/1422
>
> 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…

It did work, because Travis CI folks installed backported APT 1.2.X, 
with support for these options...

> So a few days later --force-yes was added back: 
> https://github.com/travis-ci/travis-build/pull/1433

...but this fix had an off-by-one bug in version check, which made APT 
1.2.X still use --force-yes. The bug was fixed soon after my advisory:
https://github.com/travis-ci/travis-build/commit/1ee43f25e45cad99c283b8fe53145617fd115dbb

> 2) On 2017-10-12, code was added to refresh an expired signing key: 
> https://github.com/travis-ci/travis-build/pull/1192
>
> The code used 32-bit key ID to retrieve the key from the keyserver. I 
> reported this on 2017-12-06: 
> https://github.com/travis-ci/travis-build/pull/1269

My proposed fix was to use "gpg --recv-key" with full fingerprint. But I 
now discovered that even this is not resistant against MitM attacks:

https://dev.gnupg.org/T3398

"[...] modern gpg automatically applies an import screener that only 
accepts OpenPGP certificates that have the given fingerprint [...]

However, it's possible for someone else to make a new OpenPGP 
certificate that includes the key in question without knowledge of the 
secret key (e.g. as a non-cross-signed subkey).

As a result, an attacker can bypass the import screener and inject new 
primary keys into the keyring. [...]"

--
Jakub Wilk