Misc. bug: Virus detected

[DrVonSinistro]

Name and Version

llama-b4297-bin-win-cuda-cu12.4-x64.zip

Operating systems

Windows

Which llama.cpp modules do you know to be affected?

Other (Please specify in the next section)

Problem description & steps to reproduce

Windows Defender detected a Trojan:Script/Wacatac.B!ml in llama-b4297-bin-win-cuda-cu12.4-x64.zip

First Bad Commit

No response

Relevant log output

No response

[thebiss]

I tested the current file moments ago, and it did not get any hits on VirusTotal: https://www.virustotal.com/gui/url/5ee16d7fd5079993e4c7484f1efaa44dbb0ad09eecc1247462544a39ad18a178

[DrVonSinistro]

I tested the current file moments ago, and it did not get any hits on VirusTotal: https://www.virustotal.com/gui/url/5ee16d7fd5079993e4c7484f1efaa44dbb0ad09eecc1247462544a39ad18a178

it was b4297 which disappeared. I think it should be important to check this out so that there's no bad actors pushing binaries with extra features.

[slaren]

I can still see b4297 in https://github.com/ggerganov/llama.cpp/releases/tag/b4297. All the builds are automatically generated, it is just a false positive. Seems to be a very common issue with Windows Defender.

[DrVonSinistro]

I can still see b4297 in https://github.com/ggerganov/llama.cpp/releases/tag/b4297. All the builds are automatically generated, it is just a false positive. Seems to be a very common issue with Windows Defender.

Sure enough it still say that this file has a trojan. But not any previous or following versions.

** EDIT ** I read online that this virus def seems to be a catch all for Defender when its "AI" scan isn't sure. Still, I wonder why this version and none of the others.

[ngxson]

https://superuser.com/questions/1829864/trojanwin32-wacatac-bml-found-in-c-extend-deleted

This is very often a false positive. In fact I can compile VB exes on my PC and Windows Defender will immediately try to delete/quarantine it with this detection. I have submitted such files to Microsoft and without exception got notification it was indeed a false positive.

Detection of such files is based on a very loose set of rules. A rule set could for example the combination of 2 hits from a set of 3 rules: (1) a generic type filename (SQOTT.exe for example), (2) absence of a digital signature and (3) the executable code being packed.

[DrVonSinistro]

Alright that settles it.

[Rotatingxenomorph]

I just got this on windows 11. Microsoft helpfully deletes/moves the file into some kind of quarantine hell so I will just wait for the next release.

[DrVonSinistro]

I'm closing this

[Rotatingxenomorph]

Can you reopen this because every new version is doing the same thing.

[slaren]

You should report this to Microsoft instead, there is not much we can do about it.

[DrVonSinistro]

Re-opened this by request

[Rotatingxenomorph]

b4321 worked ok. Maybe the file with the hash that was triggering Defender has changed now but it was the same for a few releases.

[DrVonSinistro]

Maybe enough people clicked on «send file for analysis» and its been added to whitelist. But ignoring false positive is bad practice, we should do as much as possible to avoid it.

[slaren]

But ignoring false positive is bad practice, we should do as much as possible to avoid it.

How would we do that?

[SvenSchoene]

This file: https://github.com/ggerganov/llama.cpp/releases/download/b4329/llama-b4329-bin-win-openblas-x64.zip

Triggered this with Bitdefender for me:

The file C:\Users\Sven\Downloads\Nicht bestätigt 136962.crdownload is infected with Gen:Variant.Tedy.651348. The threat has been successfully blocked, your device is safe

And:

The file C:\Users\Sven\Downloads\Nicht bestätigt 136962.crdownload=>llama-perplexity.exe is infected with Gen:Variant.Tedy.651348 and was moved to quarantine. It is recommended that you run a System Scan to make sure your system is clean.

It may very well be a false-positive. But I still felt it was sensible to post this here, just in case.

[DrVonSinistro]

I tried your file with Windows Defender and it asked to send the files to the mothership but otherwise they are accepted for me.

[MoonRide303]

Same problem for llama-b4338-bin-win-cuda-cu12.4-x64.zip - it gets automatically removed by built-in AV on Windows 11 (23H2 + all the updates) after the download.

No threats detected when scanning locally made binaries from b4338 tag using MSVC 2022, CUDA 12.6, and cmake commands as below:

cmake -B build-gpu -DGGML_CUDA=ON -DGGML_CUDA_F16=ON -DBUILD_SHARED_LIBS=ON
cmake --build build-gpu --config Release -j 6

[DrVonSinistro]

this time, its not just Windows Defender.

b4387 ->
llama-b4387-bin-win-cuda-cu12.4-x64.zip

VirusTotal reports this:

[DadamaldaDad]

I also got a false-positive from Windows Defender.

[DrVonSinistro]

I also got a false-positive from Windows Defender.

If it is accessible for you, compiling it yourself works very well and Windows Defender is very happy with the output.

[sinand99]

I also get virus warnings from latest cuda releases on Windows 11.

[worthy7]

Hi team, chrome won't even let me have the file

[Rotatingxenomorph]

At this point it's probably better to stop releasing these cuda builds because we can't use them.

[DrVonSinistro]

I will not use these for sure. False positive or not. I'd like to know how is it possible for us to git pull the source code, build the project and them compile without doing any modification whatsoever to any files and get a full set of binaries that the anti-virus says are fine while binaries we download since last 30 days are almost always triggering AV. This does not compute.

[Rotatingxenomorph]

I will not use these for sure. False positive or not. I'd like to know how is it possible for us to git pull the source code, build the project and them compile without doing any modification whatsoever to any files and get a full set of binaries that the anti-virus says are fine while binaries we download since last 30 days are almost always triggering AV. This does not compute.

llama-b4433-bin-win-cuda-cu12.4-x64 has passed windows defender. I need to set up compilation again anyway though.

[jesvijonathan]

latest still has the issue

[phil-scott-78]

this has been ongoing for a while; I went ahead and submitted it to the Microsoft Security Intelligence team for review. This is obviously a false positive, so the only solution is getting Defender to resolve this. This is certainly not an issue with this repository beyond the fact some combination of bits is triggering it.

[phil-scott-78]

their automated process flagged it. that's good news as it'll be, typically, moved forward towards being identified as a false positive

[tjohnman]

I got a Windows Defender positive on llama-b4644-bin-win-cuda-cu12.4-x64.zip on Windows 11.
VirusTotal report: https://www.virustotal.com/gui/file/7bef88053b1428c549aaa5a802307767a11183b6670839620c407d5556322276/detection

[phil-scott-78]

Ok, starting to see some progress. As of defender virus definitions 1.421.1785.0 it seems I can pull down the windows builds just fine. The submission on MS site is showing all good, but there are no notes yet from analysts.

End of the day I've seen this virus pop up when I've been compiling a simple app in Visual Studio. It might come back, might not. But for now, seems to be good.

[DrVonSinistro]

I wonder why we don't get a Defender alert if we compile but we do with the binaries someone else compiled using the very same source code.

[Rotatingxenomorph]

I wonder why we don't get a Defender alert if we compile but we do with the binaries someone else compiled using the very same source code.

I suspect it would need to be the exact same compiler for the file hashes to be the same.

[phil-scott-78]

I wonder why we don't get a Defender alert if we compile but we do with the binaries someone else compiled using the very same source code.

if you look at the results in the pic I posted, you'll notice the issue is with the actual zip, not any of the files within the zip. I honestly wouldn't be shocked if this was "fixed" if the archive command was switched to like something that changes the zip format a smidge by adding -x=7 to the 7z call to change the compression level.

[SomeOddCodeGuy]

For reference, I am on Windows 10.

I downloaded and scanned the above referenced llama-b4297-bin-win-cuda-cu12.4-x64.zip from December 10 with both BitDefender and Malwarebytes, and both returned clean results.

Further, I started looking into the Wacatac.B!ml detection result a bit on Google, and it turns out that the specific attack this is referencing hijacks CUDA to do malicious things; however, I can see various search results going back all the way to 2022 of other projects triggering this, including people whose own self-written games got hit for it on their own machines.

Below is the PR of the first build that got hit by someone's AV and reported here:

https://github.com/ggerganov/llama.cpp/pull/10751/files

I started scanning the builds before it because I was curious if any other builds before December 10 would also get flagged, as it makes no actual sense for THAT specific build to be the starting point. You'd think it would be a CUDA related change that would do it. This PR has absolutely nothing to do with any code I'd think would trigger a CUDA related virus warning, false or otherwise.

Just to verify, I then chose another item from the above messages that users said got picked up by defender as having a virus:
llama-b4387-bin-win-cuda-cu12.4-x64.zip. Again, clean bills of health from BitDefender and MalwareBytes.

Finally, I scanned my entire download folder, which had both zips, using Windows Defender on Windows 10, which also came back clean.

So I'm definitely inclined to believe that Windows 11's Defender, as well as some (but not all) of the AVs utilized by that online scanner folks are linking above, are misinterpreting the contents of release zip as being malicious since llamacpp also does CUDA work... but not 100% of the time.

[Rotatingxenomorph]

I wonder why we don't get a Defender alert if we compile but we do with the binaries someone else compiled using the very same source code.

if you look at the results in the pic I posted, you'll notice the issue is with the actual zip, not any of the files within the zip. I honestly wouldn't be shocked if this was "fixed" if the archive command was switched to like something that changes the zip format a smidge by adding -x=7 to the 7z call to change the compression level.

Theoretically that could also be interpreted as whatever tool that created the archive is compromised.