Racket Package Server Security Vulnerabilities

[Sam Tobin-Hochstadt]

Recently, we discovered several security vulnerabilities with how both the Racket package catalog server and the Racket package client work. The vulnerabilities have now all been fixed, and we do not know of any exploitation of them. However, we encourage you to take the following steps:

* Change your password on the http://pkgs.racket-lang.org site.

* Check any packages you have uploaded to the site, to ensure that no unexpected changes have been made to them.

* Do not use the released versions of the `raco pkg catalog-archive` command, or the `file/untar` and `file/unzip` libraries, on untrusted inputs. If you use these tools or libraries, use a snapshot build available from http://pre.racket-lang.org/.

## The errors, and how they were fixed

A total of 5 errors related to package handling were reported to us by Tony Garnock-Jones and Asumu Takikawa. Two were XSS vulnerabilities relating to handling user input in the package administration dialog. One was an error where unsanitized email addresses with path name components in them could allow a malicious user to impersonate someone else, whom they shared an email suffix with (such addresses are illegal on most mail servers, like Outlook and GMail, but not illegal in SMTP itself.) Two were errors in handling MANIFEST files and tar/zip archives, which allowed decompression to write to arbitrary locations on the file system. These last errors affected not only the server, which decompresses packages to analyze them, but also clients using the commands described above.

The relevant server-side code was fixed to appropriately sanitize user input. The package handling libraries now reject any attempts to navigate up the filesystem hierarchy, meaning that these attacks are no longer possible.

Unfortunately, due to the nature of these attacks, we cannot be sure that they were not exploited, but we have no evidence that they were. Therefore, we encourage anyone with an account to change their password, and to treat the password as compromised. Please also check your existing packages to make sure they are as you left them.

Furthermore, using the `file/untar` and `file/unzip` libraries, the `raco pkg catalog-archive` command, and the internal functions that manipulate packages is not safe on untrusted inputs in released versions of Racket. Since `raco pkg install` executes code, it is already unsafe to use on untrusted packages, but simply extracting malicious packages is also unsafe.

We have not released a new version of Racket, but encourage anyone who needs to perform these commands to use a snapshot build. The next version of Racket will be released on-schedule in October. If, however, you would benefit from a patched version of Racket 6.2.1, please let us know.

The Racket Team

[Alexis King]

> * Change your password on the http://pkgs.racket-lang.org site.

For anyone confused about how to do this, I just spent a few minutes trying to figure it out, myself. You have to log out, then log back in with your email address and intentionally specify an incorrect password. The package server will send you an email with a code that you can use to reset your password to whatever you’d like.

(It would be nice to have a “change password” button!)

[Laurent]

The server says that my package MrEd Designer ( http://pkgs.racket-lang.org/#[mred-designer] ) has been updated on 9/21/2015, 2:55:41 PM but my last commit is from 2 years ago and I haven't updated the package info in ages. The package description doesn't look suspicious. Should I be worried or is it part of some maintenance task?

Laurent

--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Laurent]

Also, were the passwords salted?

[Laurent]

On Tue, Sep 22, 2015 at 1:14 PM, Laurent <laurent...@gmail.com> wrote:

Also, were the passwords salted?

Sorry, I pressed 'Send' too early: the website says the passwords are stored in bcrypt format.

[Sam Tobin-Hochstadt]

On Tue, Sep 22, 2015 at 9:04 AM Michael Wilber <wilmi...@gmail.com> wrote:

Thank you for disclosing these vulnerabilities! Responsible disclosure
helps everyone.

Sam Tobin-Hochstadt <sa...@cs.indiana.edu> writes:
> * Check any packages you have uploaded to the site, to ensure that no
> unexpected changes have been made to them.

Is package signing on Racket's roadmap? The only way to protect against
these kinds of attacks is to have clients verify package signatures.
Every major Linux package manager now does this. I think it's at least
worth seriously considering.

This is definitely worth considering. I know people have thought about it, but I don't think it's on anyone's near-term roadmap that I know of -- but maybe someone's working on it an planning to speak up.

One challenge here is that the majority of the packages on the site are pointers to GitHub, which update continuously. That means we could sign the GitHub reference, but not the package contents, unlike in a Linux distribution where they sign the actual package you download.That might still be worth it, though.

 

One question: If an attacker was able to access the server under the
privileges of the package website, what's stopping them from just
silently uploading a change and then removing that entry from the
"Package Changes" list?

That is certainly a possibility, and it's why we can't rule out a compromise even though we have no evidence for one. We recommend that you look at the actual contents of your package entries on the server, and make sure that they're correct.

Sam

 

[Juan Francisco Cantero Hurtado]

On 09/22/2015 03:16 PM, Sam Tobin-Hochstadt wrote:
> On Tue, Sep 22, 2015 at 9:04 AM Michael Wilber <wilmi...@gmail.com> wrote:
>
>> Thank you for disclosing these vulnerabilities! Responsible disclosure
>> helps everyone.
>>
>> Sam Tobin-Hochstadt <sa...@cs.indiana.edu> writes:
>>> * Check any packages you have uploaded to the site, to ensure that no
>>> unexpected changes have been made to them.
>>
>> Is package signing on Racket's roadmap? The only way to protect against
>> these kinds of attacks is to have clients verify package signatures.
>> Every major Linux package manager now does this. I think it's at least
>> worth seriously considering.
>>
>
> This is definitely worth considering. I know people have thought about it,
> but I don't think it's on anyone's near-term roadmap that I know of -- but
> maybe someone's working on it an planning to speak up.

If you want something like GPG but simpler, take a look to signify. It
was created by an OpenBSD developer and is used to sign the OpenBSD
releases and snapshots.

http://www.openbsd.org/papers/bsdcan-signify.html
http://www.tedunangst.com/flak/post/signify

>
> One challenge here is that the majority of the packages on the site are
> pointers to GitHub, which update continuously. That means we could sign the
> GitHub reference, but not the package contents, unlike in a Linux
> distribution where they sign the actual package you download.That might
> still be worth it, though.

I have an idea for packages which use a git repo. You could add an
option to raco to generate a file with the sha256 checksum of every file
in the repo (or maybe to add the hashes to info.rkt), then to sign the
git sha reference and the file with the checksums in the server. raco
could install two versions of each package, the latest signed checkout
(it would be the default) and the HEAD (raco pkg --insecure).

If the developers want to update the version signed in the pkg server,
they only need to regenerate the checksum file, to sign it locally and
to commit the changes.

The server would check everyday each repo for changes in the checksum
files. If it find any change in that file, then it downloads the git
repo and checks the checksums and signed files.

As always, the ideas are cheap but the code is the hard part :)