Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Credentials from configured source used for a non-configured source when the URL is similar #3566

Open
6 tasks done
gep13 opened this issue Nov 18, 2024 · 1 comment
Open
6 tasks done

Credentials from configured source used for a non-configured source when the URL is similar #3566

gep13 opened this issue Nov 18, 2024 · 1 comment
Assignees
@corbob
Labels
3 - Review Bug Customer Security
Milestone
1.4.1

Comments

@gep13
Copy link
Member

gep13 commented Nov 18, 2024 •
edited
Loading

Checklist

  • I confirm there are no unresolved issues reported on the Chocolatey Status page.
  • I have verified this is the correct repository for opening this issue.
  • I have verified no other issues exist related to my problem.
  • I have verified this is not an issue for a specific package.
  • I have verified this issue is not security related.
  • I confirm I am using official, and not unofficial, or modified, Chocolatey products.

What You Are Seeing?

When performing package operations against a source, Chocolatey CLI may choose to use credentials stored against a different source.

What is Expected?

If credentials are not provided, Chocolatey CLI should not use credentials stored against a different source.

How Did You Get This To Happen?

  1. Install Chocolatey on a machine
    Set-ExecutionPolicy Unrestricted Process -Force; irm https://ch0.co/go | iex
  2. Install Sonatype Nexus Repository ('Nexus') on a machine (note: also installing NexuShell)
    choco install nexus-repository nexushell --confirm
    a. Log in to Nexus
    Connect-NexusServer -Hostname LocalHost -Credential ([PSCredential]::new('admin', (Get-Content C:\ProgramData\sonatype-work\nexus3\admin.password | ConvertTo-SecureString -Force -AsPlainText)))
    b. Create ChocolateyInternal NuGet repository
    New-NexusRepository -Name ChocolateyInternal -Format nuget -Type hosted -DeploymentPolicy Allow
    c. Create AdminOnly NuGet repository
    New-NexusRepository -Name AdminOnly -Format nuget -Type hosted -DeploymentPolicy Allow
    d. Push a package to the AdminOnly repository
    $ApiKey = (Get-NexusNuGetApiKey -Credential ([PSCredential]::new('admin', (Get-Content C:\ProgramData\sonatype-work\nexus3\admin.password | ConvertTo-SecureString -Force -AsPlainText)))).apiKey; choco push $env:ChocolateyInstall\lib\nexus-repository\nexus-repository.nupkg --source http://localhost:8081/repository/adminOnly/ --api-key="$ApiKey"
    e. Turn off anonymous access (last, because otherwise you can't push the package)
    Set-NexusAnonymousAuth -Disabled
  3. Add the ChocolateyInternal repository to the Chocolatey install, including the valid username and password you are using for Nexus.
    choco source add -n=ChocoInternal --source=http://localhost:8081/repository/ChocolateyInternal/ -U=admin -P="$(Get-Content C:\ProgramData\sonatype-work\nexus3\admin.password)"
  4. choco search --source $AdminOnlyFeedUrl, where the AdminOnlyFeedUrl is the URL of the AdminOnly repository on Nexus, without specifying credentials.
    choco search --source http://localhost:8081/repository/adminOnly/

At the end of the configuration, the server should be configured as follows:

  • Nexus installed
  • Anonymous authentication turned off, an account ready to be used
  • Two sources created
  • A package pushed to AdminOnly
  • The ChocolateyInternal authenticated source added to Chocolatey CLI
  • The AdminOnly source not added to Chocolatey CLI

System Details

  • Operating System: Windows Server 2022
  • Windows PowerShell Version: 5.1.20348.2849
  • Chocolatey CLI Version: 2.4.0
  • Chocolatey Licensed Extension version: 6.2.1 (but seemingly N/A)
  • Chocolatey License type (Professional / Business / ?): Business
  • Terminal/Emulator: bare PowerShell.exe

Installed Packages

N/A

Output Log

See [GitLab issue](https://gitlab.com/chocolatey/solutions/support-issues/-/issues/107).

Additional Context
@gep13 gep13 added this to the 1.4.1 milestone Nov 18, 2024
@gep13
Copy link
Member Author

gep13 commented Nov 18, 2024

NOTE: This is a backported security issue, which is related to this issue, which is set to ship as part of Chocolatey CLI 2.4.1

@corbob corbob self-assigned this Nov 22, 2024
corbob added a commit to corbob/choco that referenced this issue Nov 25, 2024
@corbob
(chocolatey#3566) Add ExplicitSources property
e9911c6 
The ExplicitSources property is used when looking up credentials. This
backports this property from 2.x to 1.x.
corbob added a commit to corbob/choco that referenced this issue Nov 25, 2024
@corbob
(chocolatey#3566) Rework NugetCredentialProvider
f4797ef 
Previously we looked up any available sources in the config by the
hostname, before falling back to trying an exact match if we had
collisions.

This still allowed credentials to be reused in situations where we don't
actually know if they're applicable; many repository servers will
support different credentials for individual repositories, so we cannot
and should not assume that credentials for one repository will actually
match another repository, nor that users want the credentials to be
shared for both.

It also led to the possibility of users storing one repository first,
and then later specifying a different repository on the same server, and
choco would try to use the stored credentials for the first repository
for the explicitly-entered URL which is nowhere in config.

Instead, we should only match the whole URL (which can be done with
Uri. Equals to ensure that we match hostnames case-insensitively, but
routes case-sensitively), and expect users to provide credentials if
they provide a URL that is not explicitly in the sources.

Additionally, we try to ensure that if a user has named a specific
source, rather than themselves providing a URL at the command line, we
prioritise finding that in the already-configured sources and use that
source if the URL matches the current URL that NuGet requires a
credential for.
corbob added a commit to corbob/choco that referenced this issue Nov 25, 2024
@corbob
(chocolatey#3566) Add Pester tests for Credential Provider
9d6c439 
Add Pester tests to ensure we don't inadvertently bleed configured
credentials into scenarios where they should not be used.
@corbob corbob mentioned this issue Nov 25, 2024
Merged
10 tasks
corbob added a commit to corbob/choco that referenced this issue Nov 25, 2024
@corbob
(chocolatey#3566) Add Pester tests for Credential Provider
ab46595 
Add Pester tests to ensure we don't inadvertently bleed configured
credentials into scenarios where they should not be used.
corbob added a commit to corbob/choco that referenced this issue Nov 25, 2024
@corbob
(chocolatey#3566) Rework NugetCredentialProvider
bafa7eb 
Previously we looked up any available sources in the config by the
hostname, before falling back to trying an exact match if we had
collisions.

This still allowed credentials to be reused in situations where we don't
actually know if they're applicable; many repository servers will
support different credentials for individual repositories, so we cannot
and should not assume that credentials for one repository will actually
match another repository, nor that users want the credentials to be
shared for both.

It also led to the possibility of users storing one repository first,
and then later specifying a different repository on the same server, and
choco would try to use the stored credentials for the first repository
for the explicitly-entered URL which is nowhere in config.

Instead, we should only match the whole URL (which can be done with
Uri. Equals to ensure that we match hostnames case-insensitively, but
routes case-sensitively), and expect users to provide credentials if
they provide a URL that is not explicitly in the sources.

Additionally, we try to ensure that if a user has named a specific
source, rather than themselves providing a URL at the command line, we
prioritise finding that in the already-configured sources and use that
source if the URL matches the current URL that NuGet requires a
credential for.
corbob added a commit to corbob/choco that referenced this issue Nov 25, 2024
@corbob
(chocolatey#3566) Add Pester tests for Credential Provider
d22a10d 
Add Pester tests to ensure we don't inadvertently bleed configured
credentials into scenarios where they should not be used.
corbob added a commit to corbob/choco that referenced this issue Nov 26, 2024
@corbob
(chocolatey#3566) Add Pester tests for Credential Provider
3d599b1 
Add Pester tests to ensure we don't inadvertently bleed configured
credentials into scenarios where they should not be used.
vexx32 added a commit that referenced this issue Nov 26, 2024
@vexx32
Merge pull request #3572 from corbob/source-auth-1.x
a71108c 
(#3566) Avoid credential bleed from saved sources with the same hostname
corbob added a commit to corbob/choco that referenced this issue Nov 28, 2024
@corbob
(chocolatey#3566) Ensure package download from authed source
23f2aa7 
Update the Credential lookup logic to account for the scenario where
NuGet has forgotten the credentials for the source between determining
the download Uri and trying to download from it. In this instance the
target Uri is a superstring of the source Uri (that is for a source of
`https://repo/repository/my-repository/`, the download might be
`https://repo/repository/my-repository/my-package/1.1.1`). This would
not match the credential lookup, but it should use the configured
credential.
@corbob corbob mentioned this issue Nov 28, 2024
Merged
10 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@corbob corbob

Labels
3 - Review Bug Customer Security
Projects
None yet
Milestone
1.4.1
Development

No branches or pull requests
2 participants
@gep13 @corbob