PuTTY semi-bug false-positive-malware

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

PuTTY seems to have a persistent problem with virus-scanning software. Most release builds of the PuTTY tools in the last few years have been accused by one or more virus checker of being malware of some kind.

Top-level summary: We have every reason to believe that all of these reports are false positives. As far as we know, the legitimate, signed builds of PuTTY are free of malware and safe to use. But we don't know why these reports happen; we don't even know whether it's because of anything we are doing; so we also don't know what – if anything – we can do to stop them.

History

Here's a list of accusations we have observed ourselves, or had reported to us by users.

• 0.74 (as of August 2020):
  • According to Malwarebytes: Malware.Generic.622351592
  • According to Antiy-AVL: Trojan/Win32.Swrort
  • According to Jiangmin: Trojan.Generic.fppbc
  • According to Rising: Trojan.Generic@ML.90 (RDML:L2kuAr0kZuIw8c+l3U6LAA)
  • According to SentinelOne: DFI - Suspicious PE
  • According to Yandex: Trojan.Rozena!HzkpdhLd3Ls
  • According to Zillya: Trojan.Metla.Win32.216
• 0.70 (as of July 2017):
  • According to Avira: TR/Crypt.XPACK.Gen
  • According to Baidu: Win32.Trojan.WisdomEyes.16070401.9500.9972
  • According to Rising: Malware.Heuristic!ET#86% (rdm+)
  • According to Ikarus: Win32.Outbreak
• 0.69 (as of May 2017):
  • According to DrWeb: Trojan.PWS.Siggen1.64270
  • Malwarebytes was also reported to have blocked our download server the.earth.li, though another report said that upgrading Malwarebytes fixed it
• 0.68 (as of Apr 2017):
  • According to ClamAV: Win.Trojan.Generic-6296445-0
  • According to TrendMicro: HT_RAZY_GC280119.UVPM
  • According to VBA32: Trojan.Shelma
  • According to Zillya: Trojan.Shelma.Win32.582
• 0.67 (as of Mar 2016):
  • According to ClamAV: Win.Trojan.Rozena-1115
• 0.66 (as of Mar 2016):
  • According to ClamAV: Win.Trojan.Rozena-1138
• 0.65 (as of Aug 2015):
  • According to ClamAV: Win.Trojan.Rozena-1108
• 0.64 (as of Feb 2015):
  • According to ClamAV: PUA.Spyware.XPCSpyPro, PUA.Win32.Packer.Armadillo-59, Win.Trojan.Rozena-1094
  • According to NANO-Antivirus: Trojan.Win32.Swrort.dlnmjx
  • According to Zillya: Trojan.Horst.Win32.1
  • According to nProtect: Backdoor/W32.Swrort.200704

Of course, we weren't able to investigate most of these claims, because proprietary antivirus organisations don't provide much information we could use, and undoubtedly would say they have sound security reasons for keeping quiet. So we mostly don't know what might have caused all those people to flag PuTTY as malware.

ClamAV is a partial exception: because it's free software, we were at least able to find the entries in its database that caused four successive releases of putty.exe to be flagged as various kinds of Win.Trojan.Rozena-NNNN. When we did, it turned out that each of those accusations was based on ClamAV's database containing an MD5 hash of the code segment of the corresponding putty.exe. In other words, it wasn't that PuTTY was exhibiting any kind of general behaviour or matching a general pattern that made it look like malware; it's that ClamAV's database was identifying PuTTY specifically as malware, apparently on purpose – there is no way that a database entry of that kind could have matched anything other than the specific PuTTY executable in question.

In several cases, we submitted a false-positive report to ClamAV, and they withdrew the database entry in question. And then, the next time we put out a release, they turned round and flagged that one as another kind of Rozena.

Analysis

It would be nice if we could give some explanation here of why antivirus software is so keen to call us names. Unfortunately, we don't know!

Some possibilities that have occurred to us in the past include:

• Old build tools? PuTTY was built with Visual Studio 2003 for a long time, and that also meant it didn't have up-to-date executable security features like ASLR and DEP enabled. We wondered if that might be considered an indicator of malware. But then we upgraded to Visual Studio 2015 and that didn't stop the accusations.
• No code signing? We also wondered if antivirus people had adopted a default policy of extreme suspicion towards any unsigned Windows executable. But when we started code-signing PuTTY, the accusations didn't stop.
• Incorporation into real malware? We've heard in the past that at least one real piece of malware had reused PuTTY or pieces of it (among other legitimate communications software) as a means of keeping in touch with its command and control servers. Perhaps that was enough to get the legitimate PuTTY tarred with the same brush? But that surely wouldn't explain the ongoing deliberate flagging of every release as a new kind of virus.
• Download by real malware? Another possibility is that some piece of malware might cause an infected machine to download PuTTY and then use it (which we know has happened at least once), and that this is causing virus checkers to assume the PuTTY executable being downloaded is guilty by association. That would plausibly explain the immediate flagging of each new release, if the malware is using our recommended URL that redirects to the latest version.
• Strange API usage patterns? PuTTY uses the Windows API in some unusual ways. For example, it collects various data from around the system to seed its cryptographic random number generator (a policy dating from before CryptGenRandom was available, and still used as well as CryptGenRandom). Also, it loads a lot of standard Windows DLLs at run time rather than load time, partly as a DLL hijacking defence and partly as a means of retaining support for old Windows versions. Perhaps one of those, or some other particular thing we're doing with the Windows API, is causing all this suspicion? But we don't have any clues other than our own guesswork to imagine what it might be.
• Campaign of harassment? Of course, we can't actually rule out the possibility of malice rather than disorganisation: perhaps somebody somewhere is intentionally trying to get legitimate security tools flagged as malware for some reason (perhaps to discourage people from using them?). We don't have any specific evidence for this, but it's a big Internet and there's plenty of room for a bad actor or two. It would be interesting to know if any other security projects have similar problems.

Of course, the other possibility is that the accusations might be right, and that there really is malware in PuTTY, either because it managed to get on to our build machine and infected the binaries at build time, or else (someone might imagine) because we put it there on purpose.

We don't believe that is true, and here are some reasons why:

• Our build setup does not involve Windows! As of 0.70, PuTTY's build process for Windows executables and installers goes from source code to digitally signed build products entirely on Linux, without involving Windows or even WINE at any point. (We use clang-cl as a compiler, and run the WiX installer-constructor using Mono plus some home-grown glue code). So malware that runs on Windows would have a very difficult time attacking our build machine.
• The names of the alleged viruses are too generic and too varied to be plausible. If PuTTY really was infected with some specific piece of malware, then I'd expect more than one antivirus system to agree on what it was. Instead, every one of the above reports has called us by a different name, and many of those names look suspiciously non-specific. (A couple of them even say ‘Generic’; another outright admits to being a heuristic; and the Rozena series looks more like some kind of cataloguing system than a description of a specific piece of code).
• We aren't doing anything malicious on purpose. But of course you only have our word for that! Ultimately, if anyone reading this does not trust our good intentions, there's nothing we can do to convince you. All we can say is that PuTTY is free software, so you have the last-ditch fallback option of reviewing the source code for evidence of malice, and then doing your own builds from the source you reviewed. Or, of course, using a different tool, if you really feel there's no way you can trust our code.