Security

Bottom line: If someone tells you Chocolatey is insecure, please respond with "You mean Chocolatey used to be insecure. You may want to check out chocolatey dot org slash security and catch up with the last 2+ years. Or do you mean a community package may not be secure? Organizations don't typically use the community repository anyway and only use Chocolatey in a completely secure manner. Individuals looking for more protection with the community repository go Pro." Unfortunately some security features have significant recurring costs based on usage for the Chocolatey team, so they can't be offered for free.

Report Issue

Summary

We take security issues very seriously. Security falls into a few areas of the Chocolatey framework - the clients (choco.exe and ChocolateyGUI), and the community repository (aka https://chocolatey.org/packages). While no one can give you a guarantee of complete security, we can provide information here for you to make the best decision for your use of Chocolatey. The most secure use of Chocolatey is when you use Chocolatey with packages that use embedded or local software resources. If you are super security conscious, you should understand the tradeoffs prior to using the community repository.

Overall

Chocolatey has grown up quite a bit with the release of 0.9.9+ series and has been moving to a more secure by default approach. What that means is that Chocolatey will set the more secure defaults and the user has to do something (e.g.  set a switch, choose to install Chocolatey to a less secure location) to reduce the overall security of Chocolatey.

  1. Requires elevated permissions to make changes to the default location (C:\ProgramData\chocolatey). The default location is locked down to explicitly to Administrators starting in 0.9.10. This reduces escalation of privilege attacks.
  2. Requires elevated permissions to run choco.exe in the default installed location. This reduces escalation of privilege attacks.
  3. Requires administrative permission to add to the Machine PATH environment variable. This reduces escalation of privilege attacks.
  4. Chocolatey by default will stop and ask you to confirm before changing state of the system, showing you the script it wants to execute.
  5. choco.exe supports a -whatif scenario (aka --noop) in 0.9.9+ so you can get a feel for what a package would do to your system.
  6. To reduce MITM (Man in the middle) attacks, package installs support checksums, so that when downloading from a remote location, binaries are verified prior to acting on them. If the package downloads over non-secure urls/FTP, Chocolatey v0.10.0+ requires the package include checksums by default (can be overridden by the user).
  7. Starting with v0.10.0, users can supply runtime checksums so they are not required to just trust what the package supplies (or in the case a package has missing or incorrect checksums).
  8. Starting with v0.10.1, Chocolatey will detect whether an SSL/TLS download is available and automatically switch to that for more security.
  9. Choco will not allow you to push to the community package repository without using SSL/TLS (HTTPS). This reduces DNS poisoning issues and discovery of your Community repository API key.
  10. When you host internal packages, those packages can embed software and/or point to internal shares. You are not subject to software distribution rights like the packages on the community feed, so you can create packages that are more reliable and secure. See What are Chocolatey Packages for more details.
  11. Chocolatey is run by a US-based company.

Chocolatey binaries and the Chocolatey package

The binary choco.exe can be trusted (at least as far as you trust the Chocolatey maintainers, RealDimensions Software, LLC, and Chocolatey Software, Inc).

Using PowerShell, you can verify the binary (the path below is the default install location, adjust if necessary):

C:\ PS> (Get-AuthenticodeSignature -FilePath C:\ProgramData\chocolatey\choco.exe).SignerCertificate | Format-List


Subject      : CN="RealDimensions Software, LLC", O="RealDimensions Software,
               LLC", L=Topeka, S=Kansas, C=US
Issuer       : CN=DigiCert SHA2 Assured ID Code Signing CA, OU=www.digicert.com,
               O=DigiCert Inc, C=US
Thumbprint   : C9F7FD1A91F078DB6BFCFCCE28B9749F8F2A0C38
FriendlyName :
NotBefore    : 3/23/2016 7:00:00 PM
NotAfter     : 3/28/2017 7:00:00 AM
Extensions   : {System.Security.Cryptography.Oid,
               System.Security.Cryptography.Oid,
               System.Security.Cryptography.Oid,
               System.Security.Cryptography.Oid...}

Using a Visual Studio Command Prompt, you can verify the binary (the path below is the default install location, adjust if necessary). You can also download sn separately if necessary:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>sn -T c:\ProgramData\chocolatey\choco.exe

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.1
Copyright (c) Microsoft Corporation.  All rights reserved.

Public key token is 79d02ea9cad655eb

For more information on the specifics, see #36 and #501.

Chocolatey.org Packages

Chocolatey.org has a community repository of packages known as the community feed / community package repository. These packages are created by folks in the community and due to distribution rights, they usually contain executable instructions on how to download software from official distribution points written in PowerShell.

NOTE: For Organizational Use of Chocolatey - First of all, it goes without stating that if you are a business and you are using Chocolatey, you should think long and hard before trusting an external source you have no control over (chocolatey.org packages, in addition to all of the binaries that download from official distribution channels over the internet). It is too easy to set up your own private feed where you can vet packages and have complete control over the binaries and what gets installed. This also provides complete reliability, trust, and repeatability. This is what we recommend for businesses that use Chocolatey in production scenarios (and what many of them do). There is a great article written up on the reasoning and options for hosting your own server.

Security for the Community Repository:

  1. Every package submitted to the community feed (https://chocolatey.org) since October 2014 undergoes a rigorous moderation process before it becomes live. Yes, every package, every version of a package is moderated and approved before they become live. See "Rigorous Moderation Process" below.
  2. Packages are run through VirusTotal to produce a second opinion on the relative safety of the package and underlying software that is contained or downloaded by the package. The verification of this is shown on the site.
  3. Some packages move into a trusted status. This is usually when the package maintainer is also the software maintainer, but can also occur when the maintainer(s) are trusted and multiple versions of a package have been submitted without issues.
  4. Packages that download binaries (installers, zip archives) are checked to ensure that the binary is coming from the official distribution source.
  5. Users can report malicious packages/software directly to the site administrators using a form found on every package page.
  6. Everything is enforced as HTTPS where it should be. This reduces DNS poisoning attacks.
  7. Packages are pushed to the site over HTTPS. The site grabs a SHA512 checksum of the package, then forwards it on to where packages are stored securely. You can see this package checksum in 0.9.10+ if you call choco info packagename.
  8. When installing a package, the site passes the package checksum and then the link for downloading the package. The Chocolatey binaries verify the package meets the package checksum.
  9. If the package automation scripts download binaries from official sources, the scripts used can provide checksums to verify those binaries (and are required for non-secure sources). If the package scripts have a checksum, it provides a further integrity check that the downloadable the maintainer/moderator checked is the same binary that the user gets. Chocolatey clients will enforce a checksum requirement in late 2016 by default and it will become a requirement in 2017 for all packages submitted to the community repository.
  10. Checksums of of included binaries are shown on the package page to allow for folks to perform independent verification. We've moved to adding an additional VERIFICATION.txt file for verifying the binaries.

Rigorous Moderation Process for Community Packages

In October 2014, the community feed had moderation turned on. All community packages (every version of a package) go through a rigorous moderation process prior to any public consumption:

Downloading Internet Resources Can Still Be An Issue

With all of that said, you may want to ensure you build trust with each package as the software is coming from somewhere on the internet sometimes and moderators only validate that the package gets the software from those official distribution points, not necessarily the software itself. While VirusTotal provides a bit more of a validation against the binaries, if the maintainer is not using checksums in the package, there isn't a guarantee that the software vendor did not pull a switch on the binary (the remote distribution source). If you are concerned about that you should look to Pro or Business (next section).

Chocolatey Pro / Chocolatey for Business

  1. Licensed editions of Chocolatey perform runtime virus scan verification. We highly recommend folks concerned about security using the community feed or other packages that download resources from the internet to use Pro.
  2. For organizations, we highly recommend a security conscious company look at the features available in Chocolatey for Business for more security (and locking down of components, like locking down folders even more and other nice tweaks that a business would need to make). Please note that some features are still in development.

Future Chocolatey Enhancements

  1. Moderators will cryptographically sign packages with a PGP key that they own. This will allow folks to trust moderators.
  2. Users will also cryptographically sign packages so we can provide authenticity that the package came from them.
  3. We'll show the package checksum on the website for folks that want to verify the package is brought down appropriately.
  4. A user can optionally pass their own checksums that must be validated for downloaded software - https://github.com/chocolatey/choco/issues/112

History

Some folks may state that Chocolatey is insecure. That is based on older information and is incorrect to be stated in that way. Feel free to correct the person with "You mean Chocolatey used to be insecure." and then point them to this page (https://chocolatey.org/security). It is correct that there were security concerns. However, all known concerns have been corrected and/or have a plan to be resolved (e.g.  package signing). As we learn of new security concerns we put together a plan to resolve those issues with a priority that each CVE (common vulnerabilities and exposures) requires.

Chocolatey has had multiple security audits and findings have been corrected.

Past Security Concerns

These are things that used to be security concerns. They are listed here for historical purposes in case questions come up or someone states misinformation.

  1. Installs without prompting for confirmation - not true as of 0.9.9. Chocolatey by default will stop and ask you to confirm before changing state of the system, showing you the script it wants to execute.
  2. Anybody can put packages up on the community feed and they could be malicious - we put package moderation in place in October 2014. All packages coming in are now moderated BEFORE they are open to the public. See http://codebetter.com/robreynolds/2014/10/27/chocolatey-now-has-package-moderation/ for more details.
  3. Downloads packages from S3 over HTTP (subject to DNS poisoning) - this was corrected in March 2014 (https://github.com/chocolatey/chocolatey.org/issues/70)
  4. Site doesn't require HTTPS (could be subject to DNS poisoning) - https://github.com/chocolatey/chocolatey.org/issues/126 (closed completely in November 2014)
  5. Downloads files from the internet with no integrity check - we've added checksumming in August 2014 and started enforcing it by default for non-secure downloads with 0.10.0 in August 2016. Secure downloads will also require checksums sometime in 2017 (but can be flipped on with choco feature disable -n allowEmptyChecksumsSecure or with a runtime switch).
  6. Poor permissions with c:\Chocolatey at root (allows attacker to gain Admin perms through specially crafted exes dropped in bin folder, among other things) - we don't install here by default anymore. We install to C:\ProgramData\chocolatey by default for more secure permissions. The default location is locked down to explicitly to Administrators starting in 0.9.10.

What about a non-administrative installation of Chocolatey? Is it secure?

In a word, it depends on where you install Chocolatey.

Keep in mind by default that Chocolatey requires elevated rights.

  1. The default install location (C:\ProgramData\chocolatey) requires elevated rights to install to.
  2. It (C:\ProgramData\chocolatey) also requires elevated rights to install packages. To ease this a bit, we add the installing user's ACE with modify access (the user still needs to be elevated/admin at the time of installing/upgrading Chocolatey) (removed in 0.9.10+, for old behavior see #398).
  3. Adding system-wide environment variables (e.g.  Chocolatey's bin directory to System PATH) requires administrative rights to set.

Now with that in mind, let's talk about a non-administrative install of Chocolatey.

  1. A non-admin user installs Chocolatey. They need to select a different install location that they can write to.
  2. When they install Chocolatey, it only adds USER environment variables. That means they only appear systemwide for that user alone.
  3. Chocolatey does not attempt to set or lock down permissions when a different install location is chosen.

Note the administrative install is secure by default, but the non-admin install can be secure depending on where the user decides to install Chocolatey and steps they take afterwards to secure the installation.

A non-administrative user should choose to install Chocolatey in a directory somewhere under C:\Users\<username> to avoid the most security risk. Ensure that Everyone/Users do not have modify access to the folder by checking the ACL (security tab of Folder properties).

Security Scenarios to Keep in Mind / Avoid

  1. Administrative user chooses to install Chocolatey to an insecure location (like the root of the system drive, e.g. C:\Chocolatey). Now anyone that has access to that computer has an attack vector. This is very bad, DO NOT DO THIS. It still requires an administrative execution context to exploit, but it has a high possibility and high impact.
  2. Non-admin user chooses to install Chocolatey to an insecure location (like the root of the system drive, e.g. C:\Chocolatey). Now anyone that has access to that computer has an attack vector for that user alone. This has a medium possibility and low impact.
  3. Installing user is admin during install, but then the admin privileges are removed. That user can still install portable packages that will end up on PATH. This can lead to escalation of privilege attacks. This is an unlikely scenario but one to consider if you reduce privileges for users in your organization. This has a low possibility but a high impact.