Subscribe to this thread
Home - General / All posts - Bitdefender detects Trojan in Radian installation file. False positive???
JiriD3 post(s)
#17-Feb-17 06:02

Bitdefender Total Security 2017 detects Trojan virus in both Radian 9 installation and exe files. I hope that this is only a false positive.

Attachments:
Radian_9.exe-Bitdefender_message.jpg
Radian_9.msi-Bitdefender_message.jpg

danb

2,064 post(s)
#17-Feb-17 06:17

I have similar when I attempt to download the 'Cutting Edge' builds using Avast. It is a pain as it blocks the download at the end, causing the download to fail. More details if required, otherwise Avast will be replaced with something else.


Landsystems Ltd ... Know your land | www.landsystems.co.nz

JiriD3 post(s)
#17-Feb-17 06:25

I had to turn off Bitdefender to finish the install (Perhaps blind trust in Manifold team?). Bitdefender reports the Trojan in the msi file even a day after installation. I assume this is due to daily scanning rather that some nefarious activity on the part of the msi file.

adamw


10,447 post(s)
#17-Feb-17 06:50

Here are the checksums for all installation packages for 9.0.158:

manifold-9.0.158.msi - SHA1: 5041237d66f7ac6ea58c8cbc5ffb23aeda3b5e96

manifold-9.0.158-x64.msi - SHA1: 7abfc644546a5df5b5c37d99bb82eb1b6ae698e6

manifold-9.0.158-x64.zip - SHA1: b3c8f8bc7f8d9acf7dca3f369e8191fbff8ff7b9

And here are the checksums for executables:

manifold.exe (32-bit) - SHA1: d62c8c105591be4cd6f00a571199b928024f57ba

manifold.exe (64-bit) - SHA1: 66da7353393efa47e3d2ae85e8bbab6c8f418563

All in all, this isn't news, you can bet that there will be some antivirus tool going off on every build, but please still check the sums to be sure this is, indeed, a false alarm. (You can compute checksums using this Microsoft tool, for example.)

tjhb
10,094 post(s)
#17-Feb-17 21:19

Besides Microsoft's FCIV, recent versions of 7-Zip make it super-easy to compute checksums. (Right-click on file, open CRC SHA menu, choose SHA-1.)

JiriD3 post(s)
#18-Feb-17 03:52

Any suggestions, Adam?

Attachments:
Radian_9_64bit-checksum_failure.jpg

Dimitri


7,413 post(s)
#18-Feb-17 06:29

Don't ask direct questions of people in this forum. Post a general question to the forum and if somebody wants to help you, they will.

If you need on-demand tech support on Manifold products without taking your chances that somebody may or may not volunteer to help you, follow the procedure at http://manifold.net/tech/contacting_tech.shtml

But tech support won't teach you how to correctly operate Windows or Windows utilities such as (hint...) when Windows blocks you from working with a file. Sounds like you might want to search this forum for "unblock"...

adamw


10,447 post(s)
#18-Feb-17 07:07

Well, Dimitri said it above - the file is blocked. Get it unblocked so you can verify the checksum.

Also, all of the sums in the screen are MD5. You need SHA1 (so, do 'fciv -sha1 <filename>').

(And yes, please frame your questions as general questions to everyone. It's in the terms at the bottom.)

Dimitri


7,413 post(s)
#17-Feb-17 07:05

False positive.

I am not criticizing Bitdefender because there should be no expectation they always get it right. A few false positives to block many genuine threats is a fair exchange.

Given the automated creation of malware using latest generation malware tools it could be that a million new variations are created every day. It's amazing that any anti-malware product can remotely keep up with that flow without generating so many false positives it is unusable, and doubly amazing that a $20 product like Bitdefender is as good as it is.

Also, keep in mind that Bitdefender does not have the trillion-dollar resources of the US military, which has emerged as the new adversary. That is because after spending a few billion dollars on truly sophisticated malware tools the military made the mistake of not securing them very well, getting hacked, and discovering that their own tools are now out on the dark net in the hands of any hacker who wants to apply them. Bitdefender no longer has to guard only against extremely talented 13 year olds in Bulgaria but now has to deal with threats crafted using a billion dollars of military investment. That's a very tough proposition and kudos to Bitdefender, Avast, Kaspersky and all the others who have taken on the job.

But because of the sophistication and the epic scale of the adversaries, more risky than putting blind faith in a specific vendor is putting blind faith in anti-malware tools. The potential risk from a vendor is highly localized and extremely rare while infection vectors from other causes that slip by anti-malware tools are extremely common, more likely by perhaps a factor of a billion to one.

As long as fundamentally insecure operating systems continue to be used and as long as all common sense measures to protect against malware are eviscerated to support the two goals of a) allowing Internet companies to sell users as a product and b) enabling technologically illiterate users to play stupid cat videos from whatever source they are sent without involving the use of the slightest iota of intelligence, malware will be a problem.

As for replacing one anti-virus with another, none of them are perfect and all will sometimes give false positives. It helps to run a currently updated OS like Windows 10 as well.

Regarding Adamw's post:

Checking the checksum guarantees that what you downloaded is what was on Manifold's servers. It is a way to ensure that a clean package on Manifold's servers was not infected enroute as it passes through a proxy or by a malware package that intercepts a download and infects it as it comes in.

Theoretically, it is not a guarantee that what is placed on Manifold's servers is not infected. In practice, it is a very strong indicator because that checksum is generated when the software is compiled. If the checksum the compiler issues is the same as the checksum for the file on the server and that is the same as the checksum for the file that was downloaded, that's as strong as it gets and any worries should be directed in some other direction.

cartomatic

905 post(s)
#17-Feb-17 14:06

just for the record: f-secure also complained on earlier builds


maps made easy - www.cartomatic.pl || www.cartoninjas.net

atomek

422 post(s)
#17-Feb-17 16:08

After going through the most convoluted installation process any software ever required from me on Windows, eventually I still had to grab the portable version, and again - not w/o problems, I managed to get it up & running, though the x86 version of 158.3 won't start (I've got 64 and 86 in the release 158 and 64x 158.3 working ok).

Like others here said, all antivirus, firewall and Win'10 itself were discouraging me from using the software.

Someones comment from other thread ("It would include malware, obviously.") just got a whole lot of (false-positive) substance.

You may want to reconsider:

  • filenames, as Radian is (said to be) not Manifold 9
  • default installation path, as it's the same as Manifold's
  • getting the false-positives finally sorted

Anyway, I'm glad I'm done with it now.

Again, just like in that other thread, this is just my experience, although some appear pretty common, plus few words of advice and I don't want anyone, nor I won't get, pulled into a raised tone discussion.

adamw


10,447 post(s)
#17-Feb-17 16:31

Regarding the 32-bit version not working, can it be that you didn't install the 32-bit portion of the Visual C++ Redistributable (see this post for links)? (Although if I am reading you correctly, the 32-bit version of 9.0.158 is working, it's just the 32-bit version of 9.0.158.3 that isn't - is that right? That'd be surprising, but if that's the case, we will investigate.)

The default installation path for Radian is different from that for Manifold 8. It is similar (because the product lines are similar), but different.

Finally, unfortunately, we can do very little regarding false positives from the antiviruses.

Very roughly, here's what happens: they search for viruses using both fixed signatures and heuristics that aim to detect viruses that aren't yet known. The heuristics fail and produce false positives on a percentage of executables. Heuristics get vetted by running them against the list of known-good modules - these tend to be system modules from Windows plus some very widely used open-source / commercial apps. If a heuristic throws a false positive on any of these modules, it is either disabled or reworked or the antivirus gets a shim that tells that this particular hit is a false positive. That's all the testing that goes on (kind of understandable, because what else can you do with an algorithm that is imprecise by design, but it bites everyone who (a) produces big binaries, (b) does that often, and (c) is not Microsoft / Oracle / Google). Finally, since there are many various antivirus-like tools, each with different (although partly similar) heuristics, the probability that one of them produces a false positive on any new build of a product the size of Radian is high. The end. (The solution is to become as popular as Microsoft Office after which the antivirus companies will start checking new heuristics against our modules.)

atomek

422 post(s)
#17-Feb-17 16:38

Thanks Adam. Your bit about the cause behind false-positives shed much needed light, and though discouragements from the system/antivir/firewall had not made my eye even blink (as alerts were kind of expected), there may be many new users effectively put back by these.

As for the system requirements I was sure I'm compliant with these but run the installers anyway but was informed my system is up to date. Not a biggie, three other executables work fine.

adamw


10,447 post(s)
#17-Feb-17 17:14

OK.

A little more on this. I ran a few of our last executables through virustotal.com, the results are as follows:

  • no products on virustotal.com have issues with 64-bit executables,
  • quite a number of products have issues with 32-bit executables - that's where most of the super-wide heuristics are, because 32-bit executables are more universal: they can target more machines and I guess the 32-bit subsystem frequently has less protection for compatibility reasons.

Now, the executables we are talking about that get flagged by various antiviruses are ~300 K in size, they are merely launchers that set up things and then redirect to EXT.DLL. There's next to no code yet for some reason what little code is there gets flagged as 'Trojan.GenericKD.4401123', 'Trojan.Generic.D4327E3', 'Heur.Adware' and all other kinds of scary names. Moreover, the 32-bit executable for 9.0.158.3 while being nearly completely identical to the 32-bit executable for 9.0.158.0 -- the difference is in the version numbers and timestamps = 13 bytes total, we didn't need to change any code for obvious reasons, it's just the launcher -- gets flagged differently (!). Apparently, a switch of '9.0.158.0' to '9.0.158.3' in the loadable resources section which contains no executable code "morphs" 'Trojan.GenericKD.4401123' into 'Gen:Variant.Graftor.341470'. :-)

Anyway, you can see that this is entirely bogus.

That said, I guess it might be a good idea to shuffle the code in the 32-bit executable around just for the sake of it compiling to a different binary pattern to try and make virustotal.com happier. We might try that.

(By the way, it occurred to me that you might have issues with the 32-bit executable for 9.0.158.3 but not the 64-bit one precisely because the 32-bit executable got blocked by an antivirus.)

adamw


10,447 post(s)
#18-Feb-17 12:02

We spent some more time on this, a couple of things I thought worth reporting for anyone interested:

The default example application generated by Visual Studio 2015 (File - New - Project, Visual C++, Win32 Project), compiled without any changes whatsoever in 32-bit mode is reported to contain 'TrojanDownloader.Generic.avcx' by one tool and 'HEUR/QVM10.1.0000.Malware.Gen' by another tool.

The same example application with all the code deleted and with the main entry point set to immediately return to the operating system without doing anything at all is reported to contain both of the things above PLUS one more tool thinks it contains 'Win32.Trojan.WisdomEyes.16070401.9500.9947'. (This is a bit crazy. The tools are basically raising flags on the code that initializes the C++ runtime library - it is Microsoft's code *and* we can't get rid of it, that requires tons of changes.)

We managed to reshuffle enough code in the 32-bit launcher (MANIFOLD.EXE) to convince all but two of the tools that it is clean. The remaining two tools are very hard to convince. Sometimes one of them gets convinced, but a whiff of a wind makes it go back to reporting malware, and the other tool just never stops reporting (it's one of those that reports malware in default example applications above). Still, all other tools are now quiet.

So, we'll probably make it better, but maybe not perfectly.

tjhb
10,094 post(s)
#18-Feb-17 23:54

You don't want to name the craziest culprits, by any chance?

If I were writing malware, if I were clever enough and wicked enough, wouldn't shuffling code around, making entry points and call points difficult to find, be the very first thing I would do to fool antivirus software? This is so backwards.

adamw


10,447 post(s)
#19-Feb-17 06:31

I will tell this - thankfully, the tools that currently seem the hardest to convince that the code is clean (because they flag Microsoft's CRT initialization code, not our code) seem to be relatively obscure.

adamw


10,447 post(s)
#19-Feb-17 06:46

Also, tools flagging innocent code as potentially malicious is fine - it's heuristics, heuristics fail, we get it.

Issues start when the tools allow heuristics to flag too aggressively (some would say because erring on the side of flagging too much is safer for the business), when the tools - and especially aggregators like virustotal - fail to discriminate between real signature hits and heuristic hits (the severity is vastly different), and most of all when people start using aggregators as if all of the antivirus tools they show are always right in all cases (which is absolutely not true, heuristics fail fairly frequently and even a 0.5% failure rate translates into 26% failure rate with 60 independent reporters).

tjhb
10,094 post(s)
#17-Feb-17 17:22

Possibly worth adding that Microsoft's default, basic anti-virus products and firewalls (the ones built in to Windows 7 and 10) have never questioned any Manifold or Radian product on my machines, not once in all the public and beta builds.

That's not the only relevant question, obviously. Other security products might be better in other ways.

#17-Feb-17 22:03

I have had a reply from my IT department about the Portable Radian Studio installation zip file. That file is being detected by 16 different anti-virus tools as a trojan. The IT tech support person in my department said that if I do find that Trend Micro detects that or other trojans from installing from the .msi installers for Manifold 8.0.xx or Radian Studio (Manifold.9xxx) that They we wipe and re-image my workstation. It seems that there's some sort of malicious code injected into the \bin\manifold.exe or the \bin\ folder.

tjhb
10,094 post(s)
#17-Feb-17 22:14

Please do read this thread. Pay special attention to posts by adamw and Dimitri.

There is no malicious code.

Great idea to wipe and reimage though. Everyone should do this frequently, regardless of detected threats.

#17-Feb-17 22:15

I've attached the virus scan results I got from my IT department regarding the portable Radian Studio installation file.

Attachments:
Virus_Scan_Results_Feb17_207.png

Dimitri


7,413 post(s)
#18-Feb-17 07:00

This is like pulling teeth...

It seems you are really, totally determined to absolutely not read this thread.

That's a shame because understanding the limitations of anti-virus products and why they often make the error of calling something malware when it is not is a very important part of maintaining good security.

Just as important as using anti-malware products is knowing they are highly imperfect. It is important to understand that because otherwise, the terrible mistake of putting blind faith into an anti-malware product is often replaced by the even more terrible mistake of saying "oh, none of those products work... they're just a swindle to get money and they don't have any ability to tell good software from bad."

If you have the misfortune of being saddled with an IT department that doesn't understand any of that, well, that's certainly a drag. But if you don't educate yourself and know this stuff well you won't be able to pass on important knowledge to your IT group.

adamw


10,447 post(s)
#18-Feb-17 07:57

We realize you are fighting an uphill battle with the IT department here.

Very shortly:

These are false positives. False positives happen all the time, read other posts in the thread to know more.

Your protection against false positives (and a way to determine whether the anti-virus alerts are false positives) is (a) always taking the installation packages strictly from the Manifold web site (I assume you did that), and (b) verifying their checksums. I posted the checksums for all installation packages of Radian above, we will post them on the main web site as well.

If the checksums on the files you downloaded are the same as the ones posted, you have the exact same files that we published. The probability of two different files having the same checksum is exceedingly small, that's guaranteed by math. The files that we published came straight from the compilation tools that built them from the source code. We aren't producing viruses or malware, we are producing spatial / database tools, that's guaranteed by our users and our long history.

So, if the checksums on the files you downloaded are the same as the ones posted, you know that the files are clean and contain no viruses, and anti-virus alerts are a false alarm.

Sum:

Verify the checksums on installation packages. If they check out, show that to your IT department. If they don't check out, delete the packages that you have and redownload them.

Sergio40 post(s)
#19-Feb-17 14:55

For the records, here is what I have experienced.

1. Received a message from Avast claiming (wrongly, see below) about infection while attempting to download installer file manifold-9.0.158-x64.msi from Manifold website.

2. Sent an e-mail to tech@manifold.net

following instructions provided here : http://www.manifold.net/tech/activation_support.shtml and paying particular attention to: the paragraph on "Contacting Tech Support: Required Information".

3. Manifold answered immediately that it was a false positive and advised to notify Avast about this, since virus protection is none of Manifold business.

4. I notified Avast as suggested, and

5. (one day later) answer from Avast:

"This is a false positive, it should be fixed in the new update."

Hopefully this has helped improving the quality of service of Avast (which is an antivirus I use for free) and help other users of Manifold as well.


s

#23-Feb-17 22:39

Thanks adamw and Dimitri for your efforts explaining this to all of us. My IT department after sending the manifold-9.0.158-x64.zip file to TrendMicro enterprise support did in fact say that the manifold.exe in the binary folder of the zip file is not a trojan, as you and Dimitri so artfully pointed out. I appreciate as well as I know everyone else appreciates your efforts to communicate the realities of new code to the world of antivirus/antimalware companies and their customers.

However, I did notice a post on Toms Hardware today that stated that Google has now successfully broken the SHA-1 hash:

http://www.tomshardware.com/news/google-breaks-sha-1-hash-function,33719.html

Perhaps it's time to move on to SHA-3 or some other hash?

Dimitri


7,413 post(s)
#24-Feb-17 08:15

Perhaps it's time to move on to SHA-3 or some other hash?

Sure, but mainly because that is a good marketing thing and not because of any real world threat. It is much easier to cater to - nay, exploit! - people's fears than to roll the education rock uphill. :-)

It takes zero effort for Manifold to simply publish SHA256 codes. No extra work involved, just add a string of hexadecimal numbers to the web site and then do a victory lap to bask in the glory of doing something really technical to address a problem that, as yet, in no practical way exists. Will it exist in the future? Of course, so no harm done doing a pre-fetch on the "cover oneself with glory" bit. :-)

In fact, as soon as Google announced the attack, savvy marketing people everywhere immediately thought "hey... we can leverage this..." and called their engineers to send bigger SHA strings to the web team. Why pass up on something that can be positioned as a competitive advantage, right?

I predict that over the next few days or weeks web masters all over the world will be busy publishing bigger SHA hashes. Google will be pleased but ordinary folks around the world will be perplexed and people coding applications that utilize such hashes in security will be thinking... "OK... here we go again, Chinese fire drill iteration i of N..."

The toms hardware article touches on how many people are displeased with Google for, in effect, promoting a threat that serves to drive people into Google's way of doing things, supposedly (according to the critics) to benefit Google's commercial interests in controlling the technology used by web sites. They may have a point in that, but if Google is using fear to herd people Google's way at least give them credit for not making stuff up out of thin air. But a review of the technical nuances shows there is no need to panic.

Technical criticisms of SHA1 often revolve around two poles, one totally bereft of common sense and the other one a more genuine criticism that only becomes stronger and more valid over time.

The first pole is that SHA1 as an algorithm does not guarantee a lack of collisions, it just makes them unlikely. That's a criticism that has zero common sense to it, because you'd need a million billion life times of the universe in seconds as a numeric analogy to the large numbers associated with the unreality of such a collision.

A second pole of SHA1 criticism is that as a cryptographic technology it is vulnerable to breaking given enough resources. That criticism I think has been less strenuously advanced because the cryptographic community considers what it takes to break cryptographic methods and the cost of deliberately breaking SHA1 has been astronomically high. But the cost has come down.

That Google was the first to publicly demonstrate this is not surprising given they can throw server farms with a million machines at a task if they like. With faster computation speeds the technique no longer takes Google-sized server farms.

You can even say it is not really a Google-limited thing any more given that people can build desktop machines with over 14,000 GPU cores in them, as discussed in the Parallel GPU web page for Radian. It is true that 74 teraFLOPS on the desktop is genuinely godlike power to apply. Manifold is absolutely in the vanguard of promoting the use of massively parallel GPGPU to get supercomputer power on the desktop for cheap, and that's not just marketing talk exploiting fears but genuine, real-deal engineering. GPGPU really is that revolutionary. Nobody at Manifold is going to argue that big computations will always remain out of reach for ordinary people.

But even with the Google announcement and even with the great leap forward of GPGPU there still is no practical threat, as yet, to the use of SHA1 to assure installation files do not have viruses. There are two reasons why:

1. We don't know the technical details, but it seems Google hasn't broken SHA1 in the general form of generating an SHA1 collision between two files of the same size. They apparently will publish code that can generate an SHA1 collision between two files of different sizes. If you have file A of 82,385,390 bytes with a given SHA1 hash the Google attack will teach you how to generate a file B of different size that has the same SHA1 hash. Generating a file B that is the same size as file A but also has the same SHA1 hash is more difficult. So an easy way to reduce the impact of the Google attack is to simply publish both the file size and the SHA1 hash. If hackers hang their hat on the inattentiveness of users to file size and hash code they don't need to mess with SHA cracking at all. Which brings us to the next point...

2. Even with GPGPU advances it makes zero sense for hackers to invest the money and effort into such a machine for the express purpose of computing SHA1 collisions when there are so many ways that are a million times easier to inject Trojans and malware into the computers of gullible users.

Hackers are professional criminals or talented amateurs but they are not ideologues who might take a difficult, impractical way instead of a much easier path. They don't waste their time on absurdly labor intensive maneuvers when there are strategies which are, literally, millions of times easier and more profitable.

For hackers it is just nuts and totally lacking in common sense to advance a malware strategy of computing SHA1 collisions for installation file downloads that change every few weeks and to try to use such collisions to launch a Trojan into systems when just about any elementary phishing strategy will be, literally, about a million times more effective and profitable.

In fact, phishing is so easy and effective that the biggest problem hackers have with it is the overload, the total flood, of gullible victims it produces for them. How is it that pimply faced teenagers in Romania accumulate botnets with hundreds of thousands of computers? Because phishing is that effective in a world of people who mindlessly click on stuff.

Heck, there is even less need for mindless people anymore to click on stuff since the new frontier in hacking is using mindless devices inhabiting the Internet of things, ranging from web cameras to routers to refrigerators and effectively all of them, untold tens of millions of them, all still using the default login and password assigned when they were manufactured.

For those reasons, there's no practical threat from using SHA1 now and that threat could be kept to zero by publishing the file sizes as well as the SHA1 hash.

Manifold won't do that because it is simply easier and way more trendy to publish a bigger hash, such as SHA256, than to mess about with publishing file size as well as hash code. Using a bigger hash is easy, effortless and has competitive advantages. Perfect!

The move to SHA256 or any other bigger hash will be less convenient for anyone who actually wants to check the hash, since the numbers are bigger. But hey, that's progress, and nothing to complain about given the significant threat to the universe Google has selflessly revealed. :-)

By the way, if anybody wants to check, here are the SHA256 hashes for the current installation packages:

manifold-9.0.159-x64.msi - SHA256: e79858ff 2a157f4b ac7a7b7d 7c9d48d8 b877847c 310b9cb5 94e3c3fa 2f5cdaa6

manifold-9.0.159.msi - SHA256: 1d6579c2 b72faa99 7f402cc5 1f9280de 730c4f4a 4cc5d259 bf747e79 b8d4e071

manifold-9.0.159-x64.zip - SHA256: d2eae415 aa7e0921 0d72d95c 2d9b7a98 e4829878 dca6cf5a 0e476916 20f25b48

manifold-8.0.29-x64.zip - SHA256: 4d6c1cf0 17692891 3dc131a9 5c867c8e c9b11c5b 95a55711 424cac88 5980932b

manifold-8.0.29.zip - SHA256: 5a5c7103 152de848 49687af3 31318ac7 1c30810f e6725f81 5e154100 2d865642

Use the built-in certutil utility (built into Windows 10, anyway...) to compute a SHA256 checksum in Windows:

In the command window:

C:\>certutil -hashfile manifold-9.0.159.msi SHA256

SHA256 hash of file manifold-9.0.159.msi:

1d 65 79 c2 b7 2f aa 99 7f 40 2c c5 1f 92 80 de 73 0c 4f 4a 4c c5 d2 59 bf 74 7e 79 b8 d4 e0 71

CertUtil: -hashfile command completed successfully.

Manifold User Community Use Agreement Copyright (C) 2007-2021 Manifold Software Limited. All rights reserved.