Mitigating "dependency confusion" attacks on Guix users

Mitigating "dependency confusion" attacks on Guix users

[Ryan Prior]

[-- Attachment #1: Type: text/plain, Size: 1739 bytes --]

Hi Guix! I've been digesting this piece, published hours ago, describing
dependency confusion attacks that revealed severe vulnerabilities at
many major organizations: https://medium.com/@alex.birsan/dependency-
confusion-4a5d60fec610

Guix users already have a few mitigations against this sort of attack.
Most importantly, no substitute servers or channels are installed by
default which allow arbitrary uploads by community contributors. That
feature of the affected public registries (npm, pypi, rubygems) is so
convenient, but contributes to this kind of attack. This is a great
motivation for people to move to Guix from those other package systems.

However, I'm still thinking about how to attack Guix users. Somebody who
adds an internal channel for their own packages could still be
vulnerable to a dependency confusion attack via a compromised or
manipulated Guix maintainer. The target of the attack could install
packages they believed would be provided by their internal channel but
actually get another package provided upstream.

The degree of vulnerability increases further with each channel used,
with each channel maintainer becoming another potential vector of
compromise. How can we make this kind of attack even more difficult?

What comes to my mind is that we should encourage (require?) people to
specify the channel name a package belongs to, if it's not the "guix"
channel. So instead of referring to "python-beautifulsoup4" (ambiguous:
is this from my channel or upstream Guix?) we say that "python-
beautifulsoup4" always means that package from the "guix" channel and a
version provided by my channel called "internal" needs to be called for
explicitly, like "@internal/python-beautifulsoup4".

Cheers,
Ryan

[-- Attachment #2: Type: text/html, Size: 4087 bytes --]

Re: Mitigating "dependency confusion" attacks on Guix users

[Lars-Dominik Braun]

Hi,

very interesting read.

> However, I'm still thinking about how to attack Guix users. Somebody who
> adds an internal channel for their own packages could still be
> vulnerable to a dependency confusion attack via a compromised or
> manipulated Guix maintainer. The target of the attack could install
> packages they believed would be provided by their internal channel but
> actually get another package provided upstream.
Usually you’d use module imports and variable names inside your
channel’s packages. Wouldn’t that defeat this attack? (Depending on
Guix’/Guile’s module loading order of course.)

What about substitute servers? As far as I understand as soon as they’re
authorized they can deliver substitutes for *any* package.

Lars

Re: Mitigating "dependency confusion" attacks on Guix users

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 1555 bytes --]


Ryan Prior <ryanprior@hey.com> writes:

> However, I'm still thinking about how to attack Guix users. Somebody who
> adds an internal channel for their own packages could still be
> vulnerable to a dependency confusion attack via a compromised or
> manipulated Guix maintainer. The target of the attack could install
> packages they believed would be provided by their internal channel but
> actually get another package provided upstream.
>
> The degree of vulnerability increases further with each channel used,
> with each channel maintainer becoming another potential vector of
> compromise. How can we make this kind of attack even more difficult?
>
> What comes to my mind is that we should encourage (require?) people to
> specify the channel name a package belongs to, if it's not the "guix"
> channel. So instead of referring to "python-beautifulsoup4" (ambiguous:
> is this from my channel or upstream Guix?) we say that "python-
> beautifulsoup4" always means that package from the "guix" channel and a
> version provided by my channel called "internal" needs to be called for
> explicitly, like "@internal/python-beautifulsoup4".

I'm not sure you can escape trusting the collection of channels you're
using. Because channels are code that's expected to interact, I'm not
sure it's easy to target a single package from a specific channel, and
expect that this provides some security. A malicious channel could
simply reach out and modify the state in modules from a different
channel, which would circumvent the protection you're suggesting.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

Re: Mitigating "dependency confusion" attacks on Guix users

[Jonathan Frederickson]

On 2/10/21 2:51 AM, Christopher Baines wrote:
> I'm not sure you can escape trusting the collection of channels you're
> using. Because channels are code that's expected to interact, I'm not
> sure it's easy to target a single package from a specific channel, and
> expect that this provides some security. A malicious channel could
> simply reach out and modify the state in modules from a different
> channel, which would circumvent the protection you're suggesting.

Not that it's necessarily possible to prevent at this moment with the 
tools available to us, but... is there any case in Guix's normal usage 
where the modules containing package definitions need to reach out and 
modify the state in other modules?

Re: Mitigating "dependency confusion" attacks on Guix users

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 2051 bytes --]

On Wed, Feb 10, 2021 at 07:51:23AM +0000, Christopher Baines wrote:
> 
> Ryan Prior <ryanprior@hey.com> writes:
> 
> > However, I'm still thinking about how to attack Guix users. Somebody who
> > adds an internal channel for their own packages could still be
> > vulnerable to a dependency confusion attack via a compromised or
> > manipulated Guix maintainer. The target of the attack could install
> > packages they believed would be provided by their internal channel but
> > actually get another package provided upstream.
> >
> > The degree of vulnerability increases further with each channel used,
> > with each channel maintainer becoming another potential vector of
> > compromise. How can we make this kind of attack even more difficult?
> >
> > What comes to my mind is that we should encourage (require?) people to
> > specify the channel name a package belongs to, if it's not the "guix"
> > channel. So instead of referring to "python-beautifulsoup4" (ambiguous:
> > is this from my channel or upstream Guix?) we say that "python-
> > beautifulsoup4" always means that package from the "guix" channel and a
> > version provided by my channel called "internal" needs to be called for
> > explicitly, like "@internal/python-beautifulsoup4".
> 
> I'm not sure you can escape trusting the collection of channels you're
> using. Because channels are code that's expected to interact, I'm not
> sure it's easy to target a single package from a specific channel, and
> expect that this provides some security. A malicious channel could
> simply reach out and modify the state in modules from a different
> channel, which would circumvent the protection you're suggesting.

perhaps with module-set! ? Is that the one that lets you redefine a
package in a different module, from, say, your os-config?

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Mitigating "dependency confusion" attacks on Guix users

[zimoun]

Hi Ryan,

On Wed, 10 Feb 2021 at 00:08, Ryan Prior <ryanprior@hey.com> wrote:

> What comes to my mind is that we should encourage (require?) people to
> specify the channel name a package belongs to, if it's not the "guix"
> channel. So instead of referring to "python-beautifulsoup4" (ambiguous:
> is this from my channel or upstream Guix?) we say that "python-
> beautifulsoup4" always means that package from the "guix" channel and a
> version provided by my channel called "internal" needs to be called for
> explicitly, like "@internal/python-beautifulsoup4".

Could you provide an concrete example of such attack?

I am not able to imagine a scenario.  Alice uses the official Guix
channel and another custom channel.  It is hard to compromise the
official Guix channel, IMHO.  Compromise the custom channel, well it
depends on the custom channel. ;-)

Since channels are Git repo, compromise a channel means more or less
compromise a Git repo.  IMHO.  And Guix provides the tools for
authenticate channels so it is up to Alice to trust or not a custom
channel, i.e., the people behind such channel.

Therefore, if Alice trusts the custom channel, your proposal only adds
complexity, IMHO.  If Alice does not trust the custom channel, there is
2 cases: a) she is already aware that installing packages from this
channel should be done with care because she is not trusting and b) the
packages in this custom channel cannot be used by other official
packages because of modules, or Alice has to explicitly use “untrusted“
module.  Well, below examples.

From my understanding, the design of channels using Git repo with Guile
modules is different from the PyPI&co repo where literally anyone has
the right to upload packages without a strict DAG.  Thus, the
«dependency attack» seems defeated by Guix design, i.e., it is hard to
find a scenario where Alice is really mislead and not explicitly shoot
herself in her foot.  But I could be wrong and just missing
imagination. :-)


Cheers,
simon

PS:
Some details with a naive scenario.

$ cd /tmp/
$ mkdir -p custom.git
$ cd custom.git
$ git init
Dépôt Git vide initialisé dans /tmp/custom.git/.git/


$ mkdir -p gnu/packages
$ cat gnu/packages/other-base.scm
(define-module (gnu packages other-base)
  #:use-module (guix packages)
  #:use-module (guix build-system gnu)
  #:use-module (guix git-download)
  #:use-module (guix licenses))

(define-public hello
  (package
    (name "hello")
    (version "2.10")
    (source (origin
              (method git-fetch)
              (uri (git-reference
                    (url "https://github.com/zimoun/hello-example.git")
                    (commit "e1eefd033b8a2c4c81babc6fde08ebb116c6abb8")))
              (sha256
               (base32
                "1im1gglfm4k10bh4mdaqzmx3lm3kivnsmxrvl6vyvmfqqzljq75l"))))
    (build-system gnu-build-system)
    (synopsis "Hello, GNU world: An example GNU package")
    (description
     "GNU Hello prints the message \"Hello, world!\" and then exits.  It
serves as an example of standard GNU coding practices.  As such, it supports
command-line arguments, multiple languages, and so on.")
    (home-page "https://www.gnu.org/software/hello/")
    (license gpl3+)))

$ git add gnu/packages/other-base.scm
$ git commit -m 'Add (gnu packages other-base)'
[master (commit racine) 0eabc08] Add (gnu packages other-base)
 1 file changed, 26 insertions(+)
 create mode 100644 gnu/packages/other-base.scm


$ cat /tmp/channels.scm
(list (channel
        (name 'guix)
        (url "https://git.savannah.gnu.org/git/guix.git")
        (introduction
          (make-channel-introduction
            "9edb3f66fd807b096b48283debdcddccfea34bad"
            (openpgp-fingerprint
             "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA"))))
      (channel
       (name 'custom)
       (url "file:///tmp/custom.git")))

$ guix pull -C /tmp/channels.scm -p tmp/new
Mise à jour du canal « guix » depuis le dépôt Git « https://git.savannah.gnu.or\
g/git/guix.git »...
Mise à jour du canal « custom » depuis le dépôt Git « file:///tmp/custom.git ».\
..
Construction depuis ces canaux :
  custom    file:///tmp/custom.git      62a12ec
  guix      https://git.savannah.gnu.org/git/guix.git   091ce05
[...]

$ /tmp/new/bin/guix build hello
guix build: warning: spécification du paquet « hello » ambiguë
guix build: warning: choix de hello@2.10 à l'emplacement gnu/packages/base.scm:\
77:2
/gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10



$ touch README
$ git add README
$ git commit -m 'Tweak.'
[master 69e2eac] Tweak.
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 README


$ cat /tmp/channels.scm
(list (channel
       (name 'custom)
       (url "file:///tmp/custom.git"))
      (channel
       (name 'guix)
       (url "https://git.savannah.gnu.org/git/guix.git")
       (introduction
        (make-channel-introduction
         "9edb3f66fd807b096b48283debdcddccfea34bad"
         (openpgp-fingerprint
          "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA")))))

$ guix pull -C /tmp/channels.scm -p /tmp/new
ise à jour du canal « custom » depuis le dépôt Git « file:///tmp/custom.git ».\
..
Mise à jour du canal « guix » depuis le dépôt Git « https://git.savannah.gnu.or\
g/git/guix.git »...
Construction depuis ces canaux :
  guix      https://git.savannah.gnu.org/git/guix.git   091ce05
  custom    file:///tmp/custom.git      69e2eac
Computing Guix derivation for 'x86_64-linux'...
[...]


$ /tmp/new/bin/guix build hello
guix build: warning: spécification du paquet « hello » ambiguë
guix build: warning: choix de hello@2.10 à l'emplacement gnu/packages/base.scm:\
77:2
/gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10


At this point, Alice cannot be mislead because the 2 package 'hello' are
in 2 different modules, one is (gnu packages base) and the is (gnu
packages other-base).

What happens if the corrupted 'hello' in the custom channel lives in a
module named (gnu packages base).


$ git show 90ee24f
commit 90ee24f24b721cd73c4e2f86883da18a51ce0116 (HEAD -> master)
Author: zimoun <zimon.toutoune@gmail.com>
Date:   Wed Feb 10 12:11:36 2021 +0100

    (gnu packages other-base) -> (gnu packages base)

diff --git a/gnu/packages/other-base.scm b/gnu/packages/base.scm
similarity index 95%
rename from gnu/packages/other-base.scm
rename to gnu/packages/base.scm
index 4a1e33f..c547df6 100644
--- a/gnu/packages/other-base.scm
+++ b/gnu/packages/base.scm
@@ -1,4 +1,4 @@
-(define-module (gnu packages other-base)
+(define-module (gnu packages base)
   #:use-module (guix packages)
   #:use-module (guix build-system gnu)
   #:use-module (guix git-download)


$ guix pull -C /tmp/channels.scm -p /tmp/new
Mise à jour du canal « custom » depuis le dépôt Git « file:///tmp/custom.git ».\
..
Mise à jour du canal « guix » depuis le dépôt Git « https://git.savannah.gnu.or\
g/git/guix.git »...
Construction depuis ces canaux :
  guix      https://git.savannah.gnu.org/git/guix.git   091ce05
  custom    file:///tmp/custom.git      90ee24f

[...]

construction de /gnu/store/60ab9ayq6954g9aplmi0zdhg8rw24qh0-custom.drv...
|builder for `/gnu/store/60ab9ayq6954g9aplmi0zdhg8rw24qh0-custom.drv' failed to\
 produce output path `/gnu/store/bwfswna2mva90z66r1bsszj9wbhypakn-custom'
la compilation de /gnu/store/60ab9ayq6954g9aplmi0zdhg8rw24qh0-custom.drv a écho\
ué
Vous trouverez le journal de compilation dans « /var/log/guix/drvs/60/ab9ayq695\
4g9aplmi0zdhg8rw24qh0-custom.drv.bz2 ».
cannot build derivation `/gnu/store/byajgdx0xyy4ln8cgf5hg6mcc1yxlxfa-profile.dr\
v': 1 dependencies couldn't be built
guix pull: error: build of `/gnu/store/byajgdx0xyy4ln8cgf5hg6mcc1yxlxfa-profile\
.drv' failed


So I am lacking imagination to realize the «dependencies attack» because
of the Guile modules.