Channels and dependency confusion

  • Open
  • quality assurance status badge
Details
4 participants
  • david larsson
  • Ludovic Courtès
  • Ludovic Courtès
  • Simon Tournier
Owner
unassigned
Submitted by
Ludovic Courtès
Severity
important
L
L
Ludovic Courtès wrote on 13 Jan 2023 14:48
(address . bug-guix@gnu.org)
87r0vybl4q.fsf@inria.fr
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’.

L
L
Ludovic Courtès wrote on 13 Jan 2023 14:53
control message for bug #60782
(address . control@debbugs.gnu.org)
87pmbibkx0.fsf@gnu.org
severity 60782 important
quit
L
L
Ludovic Courtès wrote on 13 Jan 2023 14:53
(address . control@debbugs.gnu.org)
87o7r2bkwv.fsf@gnu.org
tags 60782 + security
quit
S
S
Simon Tournier wrote on 13 Jan 2023 18:16
Re: bug#60782: Channels and dependency confusion
87sfgeuzgm.fsf@gmail.com
Hi,

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

Toggle quote (6 lines)
> 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.


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. ;-)


Toggle quote (11 lines)
> 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
L
L
Ludovic Courtès wrote on 16 Jan 2023 10:00
(name . Simon Tournier)(address . zimon.toutoune@gmail.com)(address . 60782@debbugs.gnu.org)
87cz7e7t2m.fsf@inria.fr
Hello,

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

Toggle quote (17 lines)
> 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.)

Toggle quote (16 lines)
>> 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’.
S
S
Simon Tournier wrote on 16 Jan 2023 12:18
(name . Ludovic Courtès)(address . ludovic.courtes@inria.fr)(address . 60782@debbugs.gnu.org)
874jsqvial.fsf@gmail.com
Hi,

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

Toggle quote (8 lines)
>> 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:

Toggle snippet (11 lines)
(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"))))

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?



Cheers,
simon
D
D
david larsson wrote on 16 Jan 2023 20:49
(name . Ludovic Courtès)(address . ludovic.courtes@inria.fr)
269d9fff51e61065afb28945795f87e8@selfhosted.xyz
On 2023-01-13 14:48, Ludovic Courtès wrote:
[..]
Toggle quote (6 lines)
>
> 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
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 60782@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 60782
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch