GNU bug report logs

#60782 Channels and dependency confusion

PackageSource(s)Maintainer(s)
guix PTS Buildd Popcon
Reply or subscribe to this bug. View this bug as an mbox, status mbox, or maintainer mbox

Report forwarded to bug-guix@gnu.org:
bug#60782; Package guix. (Fri, 13 Jan 2023 13:50:02 GMT) (full text, mbox, link).


Acknowledgement sent to Ludovic Courtès <ludovic.courtes@inria.fr>:
New bug report received and forwarded. Copy sent to bug-guix@gnu.org. (Fri, 13 Jan 2023 13:50:02 GMT) (full text, mbox, link).


Message #5 received at submit@debbugs.gnu.org (full text, mbox, reply):

From: Ludovic Courtès <ludovic.courtes@inria.fr>
To: bug-guix@gnu.org
Subject: Channels and dependency confusion
Date: Fri, 13 Jan 2023 14:48:53 +0100
In the light of the “dependency confusion” attack on PyTorch¹, one might
wonder how such a thing could affect Guix.  The threat model is quite
different though because the ‘guix’ channel is peer-reviewed and curated
whereas PyPI isn’t.

Yet, one way to “translate” the attack to Guix is by looking at module
name clashes, as was suggested on Mastodon².

For example, I’m the author of a channel; my packages refer to (@ (gnu
packages guile) guile-3.0), which I expect to be the “genuine” Guile
provided by the ‘guix’ channel.  What happens if the user pulls in an
additional channel that also provides (gnu packages guile) with that
‘guile-3.0’ variable?

Nothing, because the ‘guix’ channel always comes first in the module
search path (see ‘%package-module-path’ in (gnu packages)).  Good.

Now same scenario, but with references to another channel, for example
(@ (past packages boost) boost-1.68) provided by Guix-Past.

This time, if the user pulls in an additional channel that also provides
(@ (past packages boost) boost-1.68), we do not know which one is going
to take precedence.  It may go unnoticed though, because
‘channel-instances->derivation’ calls ‘profile-derivation’, which uses
‘build-profile’, which calls ‘union-build’ with the default file
collision policy, which is to warn (the warning only appears in the
build log).

I think it would be best to error out if multiple channels provide
same-named files.

Thoughts?

Ludo’.

¹ https://pytorch.org/blog/compromised-nightly-dependency/
² https://toot.aquilenet.fr/@Parnikkapore@mastodon.social/109636000975651971




Severity set to 'important' from 'normal' Request was from Ludovic Courtès <ludo@gnu.org> to control@debbugs.gnu.org. (Fri, 13 Jan 2023 13:54:02 GMT) (full text, mbox, link).


Added tag(s) security. Request was from Ludovic Courtès <ludo@gnu.org> to control@debbugs.gnu.org. (Fri, 13 Jan 2023 13:54:02 GMT) (full text, mbox, link).


Information forwarded to bug-guix@gnu.org:
bug#60782; Package guix. (Fri, 13 Jan 2023 17:18:01 GMT) (full text, mbox, link).


Message #12 received at 60782@debbugs.gnu.org (full text, mbox, reply):

From: Simon Tournier <zimon.toutoune@gmail.com>
To: Ludovic Courtès <ludovic.courtes@inria.fr>, 60782@debbugs.gnu.org
Subject: Re: bug#60782: Channels and dependency confusion
Date: Fri, 13 Jan 2023 18:16:41 +0100
Hi,

On ven., 13 janv. 2023 at 14:48, Ludovic Courtès <ludovic.courtes@inria.fr> wrote:

> Nothing, because the ‘guix’ channel always comes first in the module
> search path (see ‘%package-module-path’ in (gnu packages)).  Good.
>
> Now same scenario, but with references to another channel, for example
> (@ (past packages boost) boost-1.68) provided by Guix-Past.

The PyPI attack used to comprised PyTorch exploits that the PyPI index
takes precedence and sadly PyPI is not curated.

    https://github.com/pypa/pip/issues/8606

Well, the assumption for a similar attack using Guix channels is that
the user first adds the channel to their channel list.  Therefore, they
trust what they consider able to be trust. ;-)


> This time, if the user pulls in an additional channel that also provides
> (@ (past packages boost) boost-1.68), we do not know which one is going
> to take precedence.  It may go unnoticed though, because
> ‘channel-instances->derivation’ calls ‘profile-derivation’, which uses
> ‘build-profile’, which calls ‘union-build’ with the default file
> collision policy, which is to warn (the warning only appears in the
> build log).
>
> I think it would be best to error out if multiple channels provide
> same-named files.

Yes, it could be a counter-measure.  Aside the security risk, it even
appears to me sane to error because this collision leads to an undefined
behaviour.  And such undefined behaviour should be removed; they are
never a good thing.


Cheers,
simon




Information forwarded to bug-guix@gnu.org:
bug#60782; Package guix. (Mon, 16 Jan 2023 09:01:02 GMT) (full text, mbox, link).


Message #15 received at 60782@debbugs.gnu.org (full text, mbox, reply):

From: Ludovic Courtès <ludovic.courtes@inria.fr>
To: Simon Tournier <zimon.toutoune@gmail.com>
Cc: 60782@debbugs.gnu.org
Subject: Re: bug#60782: Channels and dependency confusion
Date: Mon, 16 Jan 2023 10:00:01 +0100
Hello,

Simon Tournier <zimon.toutoune@gmail.com> skribis:

> On ven., 13 janv. 2023 at 14:48, Ludovic Courtès <ludovic.courtes@inria.fr> wrote:
>
>> Nothing, because the ‘guix’ channel always comes first in the module
>> search path (see ‘%package-module-path’ in (gnu packages)).  Good.
>>
>> Now same scenario, but with references to another channel, for example
>> (@ (past packages boost) boost-1.68) provided by Guix-Past.
>
> The PyPI attack used to comprised PyTorch exploits that the PyPI index
> takes precedence and sadly PyPI is not curated.
>
>     https://github.com/pypa/pip/issues/8606
>
> Well, the assumption for a similar attack using Guix channels is that
> the user first adds the channel to their channel list.  Therefore, they
> trust what they consider able to be trust. ;-)

Right, users would have to explicitly add the offending channel to their
channel list in the first place.  (And there are many other ways channel
code could mess up with one’s machine.)

>> This time, if the user pulls in an additional channel that also provides
>> (@ (past packages boost) boost-1.68), we do not know which one is going
>> to take precedence.  It may go unnoticed though, because
>> ‘channel-instances->derivation’ calls ‘profile-derivation’, which uses
>> ‘build-profile’, which calls ‘union-build’ with the default file
>> collision policy, which is to warn (the warning only appears in the
>> build log).
>>
>> I think it would be best to error out if multiple channels provide
>> same-named files.
>
> Yes, it could be a counter-measure.  Aside the security risk, it even
> appears to me sane to error because this collision leads to an undefined
> behaviour.  And such undefined behaviour should be removed; they are
> never a good thing.

+1!

Ludo’.




Information forwarded to bug-guix@gnu.org:
bug#60782; Package guix. (Mon, 16 Jan 2023 11:53:02 GMT) (full text, mbox, link).


Message #18 received at 60782@debbugs.gnu.org (full text, mbox, reply):

From: Simon Tournier <zimon.toutoune@gmail.com>
To: Ludovic Courtès <ludovic.courtes@inria.fr>
Cc: 60782@debbugs.gnu.org
Subject: Re: bug#60782: Channels and dependency confusion
Date: Mon, 16 Jan 2023 12:18:58 +0100
Hi,

On lun., 16 janv. 2023 at 10:00, Ludovic Courtès <ludovic.courtes@inria.fr> wrote:

>> Well, the assumption for a similar attack using Guix channels is that
>> the user first adds the channel to their channel list.  Therefore, they
>> trust what they consider able to be trust. ;-)
>
> Right, users would have to explicitly add the offending channel to their
> channel list in the first place.  (And there are many other ways channel
> code could mess up with one’s machine.)

To be precise, the user must add a compromised channel; either
compromised by the packages which this channel offers or either by some
dependencies channel of this very same channel.

For instance, consider the user adds the channel guix-bimsb which
contains this .guix-channel [1] file:

--8<---------------cut here---------------start------------->8---
(channel
 (version 0)
 (dependencies
  (channel
   (name guix-past)
   (url "https://gitlab.inria.fr/guix-hpc/guix-past"))
  (channel
   (name guix-science)
   (url "https://github.com/guix-science/guix-science.git"))))
--8<---------------cut here---------------end--------------->8---

Here, the user could be compromised if the attacker is able to
compromise guix-past or guix-science.  The user who trusts guix-bimsb is
maybe not aware of this recursive dependencies; but because they trust
guix-bimsb in the first place, somehow it means they trust people behind
guix-bimsb to check that guix-past or guix-science is not compromised.

Well, somehow it is a web of trust.

And if all channels are using authentication, then the attack is hard,
no?

1: <https://github.com/BIMSBbioinfo/guix-bimsb/blob/master/.guix-channel>


Cheers,
simon




Information forwarded to bug-guix@gnu.org:
bug#60782; Package guix. (Mon, 16 Jan 2023 19:50:01 GMT) (full text, mbox, link).


Message #21 received at 60782@debbugs.gnu.org (full text, mbox, reply):

From: david larsson <david.larsson@selfhosted.xyz>
To: Ludovic Courtès <ludovic.courtes@inria.fr>
Cc: bug-guix-bounces+someone=selfhosted.xyz@gnu.org, 60782@debbugs.gnu.org
Subject: Re: bug#60782: Channels and dependency confusion
Date: Mon, 16 Jan 2023 20:49:40 +0100
On 2023-01-13 14:48, Ludovic Courtès wrote:
[..]
> 
> I think it would be best to error out if multiple channels provide
> same-named files.
> 
> Thoughts?

An option to erroring out: how about make it a feature to be able to 
specify precedence-order, say in the .guix-channel file. For example, 
that might make it easier to customize files present in guix master by 
copying them and making modifications. A custom channel might also want 
to specify the option to disallow a dependent channel to take any 
precedence.

Best regards,
David




Send a report that this bug log contains spam.


debbugs.gnu.org maintainers <help-debbugs@gnu.org>. Last modified: Sun Sep 8 03:27:24 2024; Machine Name: wallace-server

GNU bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.