PuTTY vulnerability vuln-rng-reuse

This is a mirror. Follow this link to find the primary PuTTY web site.

Home | FAQ | Feedback | Licence | Updates | Mirrors | Keys | Links | Team
Download: Stable · Snapshot | Docs | Privacy | Changes | Wishlist

summary: Cryptographic random numbers can occasionally be reused
class: vulnerability: This is a security vulnerability.
difficulty: fun: Just needs tuits, and not many of them.
priority: high: This should be fixed in the next release.
fixed-in: 320bf8479ff5bcbad239db4f9f4aa63656b0675e 0.71

Up to and including version 0.70, PuTTY's cryptographic random number generator could occasionally use the same batch of random bytes twice.

This occurred because of a one-byte buffer overflow in the random pool code. If entropy from an external source was injected into the random pool exactly when the current-position index was pointing at the very end of the pool, it would overrun the pool buffer by one byte and overwrite the low byte of the position index itself.

If the index was increased by this overwrite, then a range check would fail, and everything would be reset to a sensible state. But if the index was decreased (which is possible, since the pool size of 1200 is not a multiple of 256), then previously output random numbers could be accidentally recycled.

It's not clear to us whether this could be exploited on purpose.

As of 0.71, that entire random number generator has been completely replaced with a freshly written one based on Schneier and Ferguson's ‘Fortuna’ design, so the affected code is completely absent.

If anybody needs a point fix for this issue in 0.70 without applying the entire RNG rewrite, there is one available as a commit in Debian's downstream packaging repository for PuTTY.

This vulnerability was found by Marius Wachtler, as part of a bug bounty programme run under the auspices of the EU-FOSSA project. It has been assigned CVE ID CVE-2019-9898.


If you want to comment on this web site, see the Feedback page.
Audit trail for this vulnerability.
(last revision of this bug record was at 2019-04-14 15:26:38 +0100)