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.
While researching, we'd like to ask you to refrain from:
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:
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
/usr/lib/sftp-server, then those are also vulnerabilities the
developers would like to find and fix!
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.)
Known bugs listed here: https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/ __
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
Those builds are made directly from the
master branch in the git repository.
Vulnerabilities in the 0.70 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.70 will not attract a bounty.
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!
Attacks that involve timing and cache side channels are possibly interesting,
depending what protocol component they are in. Many of our older cipher
implementations are not well defended against attacks of that kind (DES,
Blowfish, Arcfour and software AES all use in-memory lookup tables), so cache
or timing weaknesses in those would not be surprising. But we hope that
hardware AES and ChaCha20 are robust, and we also hope that's true of all the
hash functions and MACs and also (on the
master branch, following a rewrite
after 0.70) all the asymmetric cryptography.
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.
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.
SEVERITY | CVSS SCORE | REWARD
critical | 9.0 - 10.0 | €5000
High | 7.0 - 8.9 | €2500
Medium | 4.0 - 6.9 | €1000
Low | 0.1 - 3.9 | €250
There is a 20% bonus for including a fix in the report, when accepted by the maintainers.
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 firstname.lastname@example.org.
Contact us if you want more information.