bug#60782: Channels and dependency confusion

bug#60782: Channels and dependency confusion

[Ludovic Courtès]

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

bug#60782: Channels and dependency confusion

[Simon Tournier]

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

bug#60782: Channels and dependency confusion

[Ludovic Courtès]

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’.

bug#60782: Channels and dependency confusion

[Simon Tournier]

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

bug#60782: Channels and dependency confusion

[david larsson]

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