unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Julien Lepiller <julien@lepiller.eu>
To: guix-devel@gnu.org
Subject: Sniping "guix deploy"
Date: Fri, 10 Sep 2021 01:45:04 +0200	[thread overview]
Message-ID: <20210910014504.77da1263@tachikoma.lepiller.eu> (raw)

Hi guix!

A few months ago, I published a paper on "Analyzing Infrastructure as
Code to Prevent Intra-update Sniping Vulnerabilities"
(https://lepiller.eu/pdf/hayha-extended.pdf) (and the tool:
https://github.com/roptat/hayha).

Although in the paper we focus on cloudformation and AWS, I believe the
same kind of issues can be found in any cloud or IaC toolings, such as
guix deploy.

To give you a concrete example, imagine the following situation. Not
very realistic, but I hope it gets the point across.

You manage your local network with guix deploy, and it contains a
router and a web server. Imagine you want to update the web server's
config to add an ssh service that listens for root and logs you in with
no password. You are aware this is a security risk, but you trust your
local network, so you also update the router's configuration to add a
firewall rule blocking any SSH attempt from the outside.

Unfortunately, although each system is updated atomically (although,
services are not reloaded atomically), the infrastructure is not. It
could be the case that the server is updated first, exposing root login
to the internet, for as long as the router is not updated, hence the
name "sniping".

I think this is a serious threat, despite the silly example, as the
attacker only needs to be there at the right time, with no specific
knowledge or technique. In the example, any bot would soon discover the
root login and maybe take automated actions to retain access.

However, it is also an inherent security issue to this type of tools
(and you could also very well mess up manually), so it's not clear to
me what to do.

Possible mitigations rely on user's awareness of the potential issue.
In the previous example, we would need to update the router first, and
only update the server once the router is updated. For a roll-back
(resetting the firewall and removing ssh access), the other order is
required. In other IaC tools, there is at least a way to describe
dependencies between systems/services. I think we should at least
implement such a feature in Guix too.

As a rule of thumb, when you update multiple systems and one system
provides security for another, you should update the security system
before the protected system if you restrict access, and the other way
around if you allow more access. Maybe we could add that to the manual,
in addition to letting users configure upgrade order?

In our paper, we were able to see that because Cloudformation has
explicit "references" between systems. It's also more of an issue in
Cloudformation, since you declare only small independent components and
not whole systems (security resources are always separate from the
resources they protect). There might be a way to improve guix language
to force using references between systems, which would allow us to
adopt a similar solution to what we propose in the paper. Or maybe it's
time to advocate for "immutable infrastructure" :)

Wdyt?


             reply	other threads:[~2021-09-09 23:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-09 23:45 Julien Lepiller [this message]
2021-09-10  4:06 ` Sniping "guix deploy" Katherine Cox-Buday
2021-09-10  5:07   ` Jack Hill
2021-09-10 15:36     ` Katherine Cox-Buday

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210910014504.77da1263@tachikoma.lepiller.eu \
    --to=julien@lepiller.eu \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).