oss-sec mailing list archives

Re: Travis CI MITM RCE


From: Phil Pennock <oss-security-phil () spodhuis org>
Date: Sat, 25 Aug 2018 20:56:59 -0400

On 2018-08-25 at 23:49 +0200, Jakub Wilk wrote:
The new code looks like this:

   apt-key list | awk -F'[ /]+' '/expired:/{printf "apt-key adv --recv-keys --keyserver keys.gnupg.net %s\\n", $3}' | 
sudo sh
...
  $ apt-key list | grep -A1 -w A15703C6
  pub   4096R/A15703C6 2016-01-11 [expires: 2020-01-05]
  uid                  MongoDB 3.4 Release Signing Key <packaging () mongodb com>

As a security/scalability aside which might amuse and/or cause
face-palming: I used to run an SKS keyserver in the pool; one time, when
debugging, I enabled request logging ...

Well over 50% of all requests were for that one key.

I'm not the only one to have noticed and I know that I was not alone
amongst keyserver operators in being annoyed that a free service to the
community was suddenly being hammered by one actor.  I recall discussing
with at least one person either blacklisting the key or the IP addresses
used frequently for that key.

The keyservers are a swamp; if you want to include one key, then include
the key as static data in your builds/CI configuration, so that it's
coming from a trusted source each time: your own data.

If you're building infrastructure which needs to get data from off-site,
then consider whether or not you can provide template directives which
people can include in their command lists, and you then populate the
template with the correct current commands for that directive.  Eg, if
I'm talking to Docker inside Circle CI, I don't set a bunch of variables
myself, I just say `setup_remote_docker` and let Circle CI figure out
which commands should be run.  For "everything is a shell command"
setup, then perhaps `$CICMD_APT_KEYS_UPDATE` could be made available.
Or `"${CICMD_APT_KEYS_UPDATE[@]}"` if even more constrained.

-Phil


Current thread: