Introduction

This project has been sponsored by the European Commission as part of the EU-Free and Open Source Software Auditing (EU-FOSSA) project designed to improve the security of free software.

This program will be open for submissions for 8 weeks, though rewards may be processed beyond the 8 week period in order to allow for full evaluation of the impact of valid vulnerability reports.

Note: This program has now been extended for a further two months until 7th of July 2019

Disclosure Policy

• Follow HackerOne's disclosure guidelines.
• Let us know as soon as possible upon discovery of a potential security issue, and we'll make every effort to quickly resolve the issue.
• Please provide detailed reports with reproducible steps demonstrating a plausible exploitation scenario.
• If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.
• Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.
• The project maintainers have final decision on which issues constitute security vulnerabilities. We will respect their decision, and we ask that you do as well.

Exclusions

While researching, we'd like to ask you to refrain from:

• Denial of service
• Spamming
• Social engineering (including phishing) of staff or contractors

Description

The PuTTY suite of tools are usually thought of as a Windows SSH client, but they run on Unix as well, and they contain a lot more potentially attackable pieces than that:

• The main network protocols include the modern SSH-2, the old SSH-1, Telnet and Rlogin. (Also it can talk directly to a raw TCP connection with no protocol interpretation at all, and to serial ports.)
• The primary GUI tool, PuTTY itself, includes a terminal emulator supporting a system of escape sequences in the general style of DEC VT100-series / ECMA-48 / xterm.
• The file transfer tools, PSCP and PSFTP, implement the SFTP protocol and the BSD rcp protocol, using SSH as its transport.
• For talking to network proxies, PuTTY implements two versions of the SOCKS protocol and also the HTTP CONNECT command.
• The SSH agent, Pageant, implements a protocol for clients to talk to it, over a secure IPC channel that only permits connections from the same user id on the local machine.
• When PuTTY is running with SSH connection sharing enabled, it listens on another secure IPC channel to allow other copies of PuTTY to connect to it and reuse its SSH connection.
• The key generator PuTTYgen implements support for its own private-key file format and those of several other SSH implementations.

Any of those protocols or file formats is a potential attack vector, the smaller ones no less than the larger ones. The most obvious place to look for holes is in the SSH protocol itself, but if PuTTY can be successfully attacked by (for example) a malicious SOCKS server, a maliciously constructed private key file, a malicious series of escape sequences sent to its terminal or a malicious /usr/lib/sftp-server, then those are also vulnerabilities the developers would like to find and fix!

Scope

The target for this exercise is the full set of tools distributed in the PuTTY suite: PuTTY, PSCP, PSFTP, Plink, Pageant and PuTTYgen, and (on Unix only) pterm.

(The latest PuTTY code also includes an SSH server, but it is exclusively for testing purposes and not expected to be secure. Vulnerabilities in that are out of scope.)

Out of Scope

Known bugs listed here: https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/

Versions

The PuTTY team is most interested in making the next release of PuTTY as secure as possible. So the most important place to find bugs is in the most up-to-date version of the code, available from the development snapshots page. Those builds are made directly from the master branch in the git repository.

Vulnerabilities in the 0.71 release are also interesting, even if they are already fixed in the newer snapshot code, so that users can be warned to upgrade urgently when a fixed release is available.

Vulnerabilities that only exist in versions older than 0.71 will not attract a bounty.

Types of vulnerability

The PuTTY team does not control the design of the network protocols and file formats that PuTTY implements. Therefore, design flaws in the protocols themselves are out of scope: they would affect any implementation of the same protocol, and we can't fix them by ourselves anyway. We're interested in flaws in this particular implementation of the protocols.

One exception is the .ppk file format for private keys, which we do control. A design flaw in that particular file format is potentially worth reporting, if it has serious impact.

We're not interested in attacks on a PuTTY tool that can be performed by another process running as the same user on the local machine (e.g. by reading its memory using operating system debugging APIs such as ptrace). Once an attacker can do that, all the defending program can do in any case is to make the job marginally more difficult; there's no really effective defence.

One exception is if PuTTY fails to wipe a piece of sensitive data completely out of its memory when it is no longer needed. It's unavoidable that reading PuTTY's memory can expose the current session keys for an SSH session, or that reading Pageant's memory can reveal private keys, because those have to still be in memory for the tools to do their jobs at all. But if examining the address space of a running PuTTY can find out the password the user entered during authentication, after authentication is over, then that is still of interest.

We are interested in attacks by another process on the same machine running as a different user. If the secure IPC endpoints used by Pageant and by PuTTY's connection sharing can be accessed by a non-administrator user other than the one running the application, that is a flaw we definitely want to know about!

POC

Vulnerabilities are to be evaluated given contemporary computer architectures.

The PoC must work on the respective repository trunk heads or the latest released version. Older builds are explicitly out of scope.

Please send reproducers in the form of a static output data file rather than instructions to run a fuzzer. A reproducer needs to allow the developer to confirm that the bug has been fixed by a candidate code change as well as confirming that it is still there, so probabilistic reproducers only do half the job.

Rewards

Our rewards are based on the severity of a vulnerability. HackerOne uses CVSS 3.0 (Common Vulnerability Scoring Standard) to calculate severity. We will update the program over time based on feedback, so please give us feedback on any part of the program you think we can improve on.

A bonus structure is in place from the 14th of June to 10th July 2019

Critical severity bugs - €5000 €7500

• Remote Code Execution

High severity bugs - €2500 €3250

• Code Execution without user intervention

Medium severity bugs - €1000 €1300

• Code Execution with user intervention
• High-impact Crashes
• Infinite loops

Low severity bugs - €250 €325

• Information leaks
• Crashes
• OOM

Bonus

There is a 20% bonus for including a fix in the report, when accepted by the maintainers.

Note: The 20% bonus is calculated off the new bonus structure.

Safe Harbor

Any activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.

Thank you for helping keep PuTTY and our users safe!

If you have any questions or concerns on this Challenge, please contact [email protected]