[<prev] [day] [month] [year] [list]
Message-ID: <11f2d0ff-37da-49b2-980a-1b6739aa6ebf@oracle.com>
Date: Sun, 24 May 2026 16:57:05 -0700
From: Alan Coopersmith <alan.coopersmith@...cle.com>
To: oss-security@...ts.openwall.com
Subject: PuTTY 0.84 released with 3 minor security fixes
https://lists.tartarus.org/pipermail/putty-announce/2026/000042.html
announces the release of PuTTY 0.84 with 3 minor security fixes, along
with other bug fixes and new features.
https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/rsakex-double-free.html
provides the following info about the first vulnerability:
> summary: ECDSA signature verification can be made to fail an assertion
> class: vulnerability: This is a security vulnerability.
> present-in: 0.71
> fixed-in: 65b8f37c34cd80680693e813e0081cdafaf58324 (0.84)
>
> The elliptic curve arithmetic in PuTTY contains an assertion statement
> which shouldn't be there. It fails an assertion if you try to add two
> elliptic curve points with the same y-coordinate, which is a perfectly
> normal thing to do and should not be a special or error case at
> all. (Adding points with the same x-coordinate is a special case.)
>
> This assertion failure can be triggered during initial key exchange,
> by sending a carefully chosen host key and signature. The crashing
> calculation does not depend on any other part of the key exchange, so
> the malicious key and signature can be the same every time.
>
> Verification of the host key signature occurs in PuTTY before the host
> key is checked against the cache. So even if you trust the server you
> think you're connecting to, a MITM could substitute this bogus key and
> signature for the real ones, and cause PuTTY to crash with an
> assertion failure before you received any warning about an unknown or
> incorrect host key.
>
> This just about classifies as a DoS attack, and hence a vulnerability.
> However, it is a very minor one, on the borderline of not even counting
> as a vulnerability at all, because:
>
> - A MITM between a particular client and server can always deny service
> in the sense of preventing a successful SSH connection setup. Nothing
> can be done about that.
> - The only interesting thing in this attack is that the MITM can cause
> PuTTY to crash, rather than failing with a more sensible error message
> (which is what happens in the same situation once this bug is fixed).
> - PuTTY is always compiled with assertions turned on. So the crash is
> only an ugly error message, and does not lead to any worse compromise.
> - PuTTY runs one SSH session per process, so this crash does not terminate
> any other running sessions.
> - The only potential damage is that if you had valuable information in
> your terminal scrollback (e.g. because you had already run one
> successful SSH connection in the same window, and then used the
> "Restart Session" menu option), you might lose that information
> because PuTTY crashed.
>
> This bug applies only to elliptic curves in Weierstrass form. In PuTTY that
> means the NIST curves: P256, P384 and P521. Ed25519 (and Ed448) is unaffected.
>
> Thanks to Guido Vranken for reporting this bug, and also providing an
> example case in the P256 curve.
https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/rsakex-double-free.html
provides the following info about the second vulnerability:
> summary: Server can provoke a double free in RSA KEX code
> class: vulnerability: This is a security vulnerability.
> absent-in: 7a49ff9ac1f65944434176251b0bfea9fcc44636
> present-in: 6d7a6d47e68e8368216f3ab1a0d071db32d20a11
> 0.72 0.73 0.74 0.75 0.76 0.77 0.78 0.79 0.80 0.81 0.82 0.83
> fixed-in: ba3ed53e0bf6682f89940bc2c3e83da6b1524024 (0.84)
>
> PuTTY's implementation of the little-used RSA kex exchange method (RFC 4432)
> has a double-free bug: in some situations it frees an RSA key by calling the
> special-purpose function ssh_rsakex_freekey and then also calling the normal
> free function on the outermost struct, which is wrong, because
> ssh_rsakex_freekey already freed the whole struct.
>
> This bug does not happen if RSA kex completes normally. The double-free only
> occurs on an error handling path, triggered if the key sent by the server is
> unexpectedly short.
>
> This bug allows a server to provoke the double-free on purpose, because it
> can present only RSA kex as an option in its KEXINIT, and then deliberately
> send a short key. Since it happens before host key verification, a MITM can
> do the same. Therefore, this bug is listed as a vulnerability, since it's a
> remote-triggerable crash. However, we don't know of any way in which the
> double-free can be exploited to achieve a controllable effect.
>
> Thanks to Ben Smyth for the report.
>
> Apparently this was introduced during work in 2019 to make a test SSH server
> out of the PuTTY code (including an option to pass in a fixed key pair for
> RSA kex, complicating the question of whether to free it after use).
> Confusion was increased by the historical oddity that PuTTY's RSA keys were
> originally held in a struct that was not freed along with its contents.
https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/telnet-trust-sigil.html
descsribes the third vulnerability thusly:
> summary: Telnet session data is marked with trust sigils after authenticating
> to a proxy
> class: vulnerability: This is a security vulnerability.
> present-in: 0.77
> fixed-in: 64712be3cbc4a02bda4a92ca97e8d4f294abbe9a (0.84)
>
> During the initial authentication phase of a network connection, PuTTY
> marks its own prompts with a 'trust sigil': a small copy of the PuTTY
> icon, to the left of the text. This distinguishes prompts that PuTTY
> emitted itself from identical text sent by a server.
>
> The idea is to protect against spoofing attacks in which a server lets
> you log in without any password, and then pretends that it's still
> PuTTY itself doing initial authentication, and presents a prompt for
> something like your SSH private key passphrase. You might be fooled
> into telling the server that passphrase, which shouldn't ever leave
> the client machine. The trust sigil offers some protection, because
> the server can't make PuTTY display one of those, so it can't make its
> spoof password prompt look just like the real one.
>
> In the older protocols such as Telnet and Rlogin, there is no formal
> authentication phase in the protocol itself: if the server presents a
> password prompt then it does it as part of the main session data. So
> trust sigils are not usually shown at all.
>
> However, there's an exception. proxy-password-prompt introduced the
> ability to enter a password interactively when connecting to your
> server through a network proxy. So a trust sigil can be used in a
> Telnet session: it might appear during proxy authentication, before
> the Telnet session itself begins at all.
>
> When this happened in 0.83 and before, the trust status was
> accidentally not cleared between proxy authentication and the main
> session. So the whole session would have trust sigils down the
> left-hand side.
>
> I committed the fix for this in public, thinking it was just a silly
> bug. (When your whole Telnet session has those symbols down the side,
> you're surely going to realise they're a mistake, and not be fooled.)
> But since then, I've re-thought: it is a minor vulnerability, because
> what if the first thing the Telnet server (or MITM) sends is a request
> for your proxy password, perhaps pretending your previous entry of it
> was unsuccessful? That's still be a piece of information you don't
> want attackers knowing, and you might be fooled by the trust sigil
> into believing the request, before you find out that the rest of your
> session is all marked with that same sigil. By the time you notice
> that, it's too late – the damage is done.
>
> So I'm classifying this as a vulnerability, although its impact is
> surely very small compared to most vulnerabilities. (Especially since
> it requires you to be using an old insecure login protocol like
> Telnet.)
Additionally, VulDB has issued CVE-2026-4115 for a bug fixed in this
release that the maintainer does not believe is a vulnerability, as
discussed in detail on:
https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/eddsa-overlarge-s.html
--
-Alan Coopersmith- alan.coopersmith@...cle.com
Oracle Solaris Engineering - https://blogs.oracle.com/solaris
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
