Listen to this Post
Introduction:
PuTTY 0.84 has been released, addressing three minor yet important security vulnerabilities that could allow remote attackers to crash the SSH client or deceive users in insecure sessions. Two of these flaws reside in core cryptographic components—ECDSA signature verification and RSA key exchange—and can be triggered by a malicious server or a man-in-the-middle (MITM) attacker before the host key is even verified, leading to a denial-of-service (DoS). The third issue involves a “trust sigil” logic error in legacy Telnet sessions, which could trick a user into entering a proxy password into a spoofed server prompt.
Learning Objectives:
- Identify and explain the three distinct vulnerability classes fixed in PuTTY 0.84 (ECDSA assertion crash, RSA double-free crash, and Telnet trust sigil bypass).
- Implement secure update procedures for PuTTY across Windows and Linux platforms using both graphical and command-line methods.
- Harden PuTTY client configurations and SSH key exchange settings to mitigate similar risks in the future.
You Should Know:
1. The Three Vulnerabilities Fixed in PuTTY 0.84
The release tackles three primary issues. The first, and most technically interesting, is an ECDSA signature verification crash (present since version 0.71). The elliptic curve arithmetic in PuTTY contained an erroneous assertion that failed when adding two elliptic curve points with the same y-coordinate—a perfectly normal operation. This allowed a malicious server or MITM to send a specially crafted host key and signature during the initial key exchange, causing PuTTY to crash with an assertion failure.
The second crash is a double-free vulnerability in RSA key exchange (RFC 4432), affecting versions 0.72 through 0.83. When a malicious server sends an unexpectedly short or malformed RSA key during negotiation, PuTTY mistakenly frees the same memory structure twice, leading to a crash.
The third issue is a logic flaw in PuTTY’s Telnet “trust sigil” feature (present since 0.70, fixed in 0.84). When a user connects through a proxy and authenticates, the trust state is not reset. Consequently, all subsequent server messages are treated as trusted, potentially causing a user to enter a proxy password into a spoofed server prompt. While reliant on the legacy Telnet protocol, it poses a real risk in environments where it is still used.
2. Step-by-Step Guide: Updating PuTTY to Version 0.84
Windows (Using the Installer):
- Backup your sessions: Run `regedit` and navigate to
HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\Sessions. Export this key to a `.reg` file. - Download the latest installer: Visit the official PuTTY download page and download the 64-bit MSI installer (e.g.,
putty-64bit-0.84-installer.msi). - Run the installer: Double-click the MSI file and follow the on-screen instructions, selecting “Upgrade” when prompted.
- Silent installation (enterprise): For mass deployment, run: `msiexec /i putty-64bit-0.84-installer.msi /quiet /norestart`
5. Verify the update: Launch PuTTY, click on the top-left corner icon, and select “About PuTTY”. Confirm the version displays as 0.84.
Linux (Debian/Ubuntu – APT):
1. Update package lists: `sudo apt update`
- Upgrade PuTTY: `sudo apt install putty` (or
sudo apt upgrade putty) - Verify version: `putty -V` This command should output “putty 0.84” (or later).
Linux (Other Distributions):
- Fedora/RHEL: `sudo dnf upgrade putty`
– Arch Linux: `sudo pacman -Syu putty`
– From Source: The source tarball can be downloaded from the official site and compiled with standard./configure && make && sudo make install.
3. Enhancing SSH Security: Key Exchange Hardening Guide
While updating patches known vulnerabilities, configuring your SSH client to use only modern, secure algorithms is a crucial best practice.
Objective: Disable weaker key exchange algorithms, including the vulnerable RSA-based KEX (RFC 4432) and limit elliptic curves to secure ones.
Step 1: Access PuTTY’s KEX Settings
- Open PuTTY. In the left-hand “Category” tree, navigate to Connection → SSH → Kex.
Step 2: Configure Algorithm Selection Policy
- At the top, you will see the “Algorithm selection policy” list. It displays the key exchange algorithms in order of preference.
- Disable
rsa-kex: Locate `rsa-kex` (the vulnerable RSA method). Select it and click the “Down” button repeatedly to move it to the bottom, or “Remove” it entirely. - Promote secure ECDH: Ensure
ecdh-sha2-nistp256,ecdh-sha2-nistp384, and `ecdh-sha2-nistp521` are at the top. These are the secure Elliptic Curve Diffie-Hellman methods. - Enable post-quantum KEX (optional): If your server supports it, move `ntruprime-ntrulpr761-sha256` or `mlkem768-sha256` (post-quantum algorithms) to the top for future-proofing.
Step 3: Save Configuration
- Return to the “Session” category. Enter a name in the “Saved Sessions” textbox and click the “Save” button. This applies your hardened configuration to a specific profile.
4. Verifying and Managing SSH Key Formats
The ECDSA vulnerability in versions prior to 0.84 impacts NIST curves P-256, P-384, and P-521. While the crash is fixed, it’s advisable to review your key usage.
Step 1: Identify Your Key Types
PuTTY’s key generation tool, puttygen.exe, can display the type of your existing keys:
– Run puttygen.exe. Load your private key file (e.g., a `.ppk` file).
– The “Key fingerprint” field will indicate the algorithm and key length (e.g., “ecdsa-sha2-nistp256”).
Step 2: Generate Modern Keys
For new deployments, avoid the NIST P-curves for critical infrastructure. Generate keys using the Ed25519 curve, which was unaffected by both the old biased nonce bug (CVE-2024-31497) and the new assertion crash.
– Open puttygen.exe.
– At the bottom, select “Ed25519” as the type of key to generate.
– Click “Generate” and move your mouse to add randomness.
– Save the public and private keys in a secure location.
5. Detecting Compromise: Monitoring for Malicious PuTTY Activity
Historical incidents involving trojanized PuTTY installers highlight the risk of weaponized freeware. Security teams should actively monitor for:
– Unusual SSH authentication attempts: Large volumes of outbound SSH traffic from a single client or anomalous destination IPs.
– Unauthorized registry changes: On Windows, monitor for changes to `HKLM\SOFTWARE\SimonTatham` and HKCU\Software\SimonTatham.
– File hashes: Maintain a baseline of the legitimate `putty.exe` SHA-256 hash (available on the official download site) and compare via endpoint detection and response (EDR) tools.
What Undercode Say:
- The seemingly “minor” crash vulnerabilities in core cryptographic functions expose a critical truth: an attacker who can force a client crash can disrupt operations and, in targeted scenarios, cause session loss or scrollback data destruction. This is a low-barrier DoS vector.
- The Telnet trust sigil flaw is a masterclass in how subtle logic errors in state management can undermine entire security features. The failure to reset a trust flag after proxy authentication is a textbook example of a “confused deputy” vulnerability.
-
Analysis: This update underscores that even mature, widely-used tools like PuTTY can harbor edge-case flaws that persist across multiple versions. The ECDSA assertion bug, present since 2017 (version 0.71), demonstrates that cryptographic code is notoriously difficult to get right, and even seemingly harmless assertions can become security liabilities. The three CVSS scores are low, but the aggregate risk for organizations with large SSH user bases is not trivial. The proactive update to 0.84 and the adoption of Ed25519 keys are low-effort, high-value security investments that close these specific logic holes. It also serves as a reminder that security is a state, not a product; continuous patching and configuration hardening are required.
Prediction:
We will soon see proof-of-concept (PoC) exploits for these crashes, likely integrated into red team toolkits and MITM frameworks. As more services adopt post-quantum cryptography (PQC), tools like PuTTY will face intense scrutiny, and we can expect more complex vulnerabilities to emerge from the implementation of algorithms like ML-KEM. Organizations that do not deploy 0.84 will face targeted disruption campaigns. Furthermore, the discovery of similar assertion or state-management flaws in other widely used SSH clients (e.g., OpenSSH client-side components) will accelerate, leading to a new wave of “client-side KEX bombing” attacks.
▶️ Related Video (80% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Divya Kumari – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
