[ Security issue ] Viruses detected after compile

[RealMadvicius]

[ Security issue ] Viruses detected after compile

[eli-schwartz]

I don't know since when the malicious code was pushed because last time I compiled LMMS on Windows was years ago. But it means that all linux distro shipping the lib lilv are at risk as of now.

Since it's all built on your machine from source code, that means it is easily vetted to determine whether that's a false positive... antivirus software is notorious for false positives if you don't pay someone money to sign your program...

[RealMadvicius]

The thing here is that it could potentialy fall under an eventual false positive if it was just one antivirus or two, but here we have 10 antiviruses detecting something, so there is definitely something fishy that needs attention.

[drobilla]

Virus scanners do pattern recognition in binaries, and they share databases. They are not security scanners, and one actually should expect a false positive in one tool to show up in several others. Not seeing that would be quite strange.

I can look into the idea that someone has snuck malware past me into lilv, but this is wildly unlikely for a whole host of reasons. Please tone down the fear mongering unless you have something more substantial to base it on. All of this code passes through me personally (the overwhelming majority being written by me alone, contributions significant enough to be relevant here are very rare), and I'm a known person in this particular niche and have been for a long time. As alluded to above, virus scanner companies have a vested interest in casting as wide a net as possible, and have many questionable practices based on that where they directly benefit financially from the issues (like this one) that causes. Meanwhile, I certainly have no interest in destroying my reputation (and that of LV2 or free audio software in general) by doing something so silly as to put malware into lilv.

[eli-schwartz]

In particular, if it is claiming that meson-private\tmpu5lnsej4\output.exe is a virus, that is probably a compiled executable generated from a C one-liner as part of Meson's builtin support checks. It is... very easy to ascertain whether the input file in question would have a virus in it. The file meson-logs/meson-log.txt would show the source code (also likely still present in testfile.c in the same directory) and the command line for e.g. MSVC's cl.exe used to compile it.

You can upload that log file for me to take a look at, or check through it yourself.

[drobilla]

Yeah, I'd like to see that too. What pattern is being tripped by such a tiny thing might be interesting. Could be something so silly as the standard setup for a common(ish) system call... there's not much else there, really.

[RealMadvicius]

I just used the basic command given in the LMMS build on windows to retrieve//install package from VCPKG:

.\vcpkg.exe --triplet x64-windows install fftw3 libsamplerate libsndfile lilv lv2 sdl2 fluidsynth

Also I'm not trying to spread fear mongering nor point finger at anyone. But when someone just follow what should be a simple command to retrieve dependencies and get virus alert then proceed to get further feedback from more tools to check before posting concerns to be cleared by people who have knowledge about the concerned project, there is nothing wrong trying to clarify what is going on.

[eli-schwartz]

Well, if we know which bit of code exactly is tripping up the virus scanner, that might help figure out if there is something that can be done to fix it. ;)

So, that log file could be a good first step.

[RealMadvicius]

I'll look for it but when I had checked inside last time I ran the command I didn't see anything special.
Also the issue can be reproduced by just installing the latest MSVC and latest QT then just running the VCPKG command I have shown, so if we get more people testing we could figure out faster aswell ;)

[eli-schwartz]

then proceed to get further feedback from more tools to check before posting concerns to be cleared by people who have knowledge about the concerned project

And for the record, I'm the "people who have knowledge about the concerned project" when it comes to Meson. Since one of the two flagged files is produced by Meson, not by lilv, I figured it would be a good idea to offer what input I can. :)

Also the issue can be reproduced by just installing the latest MSVC and latest QT then just running the VCPKG command I have shown, so if we get more people testing we could figure out faster aswell ;)

Alas, I am not a Windows user and cannot check anything on that platform.

[RealMadvicius]

For the DLL no idea as of now, the only hint I have is that for the debug build of lilv there is no issue, it happens just for the release build.
Also this is the part in the log about meson that seems to have triggered the antivirus:

Checking if "printf supports the 'ls' directive" runs: YES
Running compile:
Working directory: E:\Programming\Projects\vcpkg\buildtrees\glib\x64-windows-rel\meson-private\tmpu5lnsej4
Command line: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.33.31629/bin/Hostx64/x64/cl.exe -INCREMENTAL:NO -IE:/Programming/Projects/vcpkg/installed/x64-windows/include E:\Programming\Projects\vcpkg\buildtrees\glib\x64-windows-rel\meson-private\tmpu5lnsej4\testfile.c /FeE:\Programming\Projects\vcpkg\buildtrees\glib\x64-windows-rel\meson-private\tmpu5lnsej4\output.exe /nologo /showIncludes /utf-8 /MD -nologo -DWIN32 -D_WINDOWS -W3 -utf-8 -MP -MD -O2 -Oi -Gy -DNDEBUG -Z7 /nologo /showIncludes /utf-8 /Od /Oi- /link -machine:x64 -DEBUG -OPT:REF -OPT:ICF /LIBPATH:E:/Programming/Projects/vcpkg/installed/x64-windows/lib

Code:

#include <stdio.h>
#include <string.h>
static char buf[10000];
int main ()
{
int result = 0;
buf[0] = '\0';
if (sprintf (buf, "%Lf %d", 1.75L, 33, 44, 55) < 0
|| strcmp (buf, "1.750000 33") != 0)
result |= 1;
buf[0] = '\0';
if (sprintf (buf, "%Le %d", 1.75L, 33, 44, 55) < 0
|| strcmp (buf, "1.750000e+00 33") != 0)
result |= 2;
buf[0] = '\0';
if (sprintf (buf, "%Lg %d", 1.75L, 33, 44, 55) < 0
|| strcmp (buf, "1.75 33") != 0)
result |= 4;
return result;
}

Compiler stdout:
testfile.c
Note: including file: C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\ucrt\stdio.h
Note: including file: C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\ucrt\corecrt.h
Note: including file: C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.33.31629\include\vcruntime.h
Note: including file: C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.33.31629\include\sal.h
Note: including file: C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.33.31629\include\concurrencysal.h
Note: including file: C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.33.31629\include\vadefs.h
Note: including file: C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\ucrt\corecrt_wstdio.h
Note: including file: C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\ucrt\corecrt_stdio_config.h
Note: including file: C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\ucrt\string.h
Note: including file: C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\ucrt\corecrt_memory.h
Note: including file: C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\ucrt\corecrt_memcpy_s.h
Note: including file: C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\ucrt\errno.h
Note: including file: C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.33.31629\include\vcruntime_string.h
Note: including file: C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\ucrt\corecrt_wstring.h
E:\Programming\Projects\vcpkg\buildtrees\glib\x64-windows-rel\meson-private\tmpu5lnsej4\testfile.c(9): warning C4474: 'sprintf' : too many arguments passed for format string
E:\Programming\Projects\vcpkg\buildtrees\glib\x64-windows-rel\meson-private\tmpu5lnsej4\testfile.c(9): note: placeholders and their parameters expect 2 variadic arguments, but 4 were provided
E:\Programming\Projects\vcpkg\buildtrees\glib\x64-windows-rel\meson-private\tmpu5lnsej4\testfile.c(13): warning C4474: 'sprintf' : too many arguments passed for format string
E:\Programming\Projects\vcpkg\buildtrees\glib\x64-windows-rel\meson-private\tmpu5lnsej4\testfile.c(13): note: placeholders and their parameters expect 2 variadic arguments, but 4 were provided
E:\Programming\Projects\vcpkg\buildtrees\glib\x64-windows-rel\meson-private\tmpu5lnsej4\testfile.c(17): warning C4474: 'sprintf' : too many arguments passed for format string
E:\Programming\Projects\vcpkg\buildtrees\glib\x64-windows-rel\meson-private\tmpu5lnsej4\testfile.c(17): note: placeholders and their parameters expect 2 variadic arguments, but 4 were provided
E:\Programming\Projects\vcpkg\buildtrees\glib\x64-windows-rel\meson-private\tmpu5lnsej4\testfile.c(9): warning C4996: 'sprintf': This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
E:\Programming\Projects\vcpkg\buildtrees\glib\x64-windows-rel\meson-private\tmpu5lnsej4\testfile.c(13): warning C4996: 'sprintf': This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
E:\Programming\Projects\vcpkg\buildtrees\glib\x64-windows-rel\meson-private\tmpu5lnsej4\testfile.c(17): warning C4996: 'sprintf': This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.

Compiler stderr:
cl : Command line warning D9025 : overriding '/O2' with '/Od'
cl : Command line warning D9025 : overriding '/Oi' with '/Oi-'

Could not run: ['E:\Programming\Projects\vcpkg\buildtrees\glib\x64-windows-rel\meson-private\tmpu5lnsej4\output.exe'] (error: [WinError 5] Accès refusé)

[drobilla]

Also I'm not trying to spread fear mongering nor point finger at anyone. But when someone just follow what should be a simple command to retrieve dependencies and get virus alert then proceed to get further feedback from more tools to check before posting concerns to be cleared by people who have knowledge about the concerned project, there is nothing wrong trying to clarify what is going on.

Siiiiiigh. Fine:

I'm not saying I don't appreciate the feedback, I just asked you nicely to tone it down. Given the bolding, "[ Security issue ]", "I don't know since when the malicious code was pushed because [...]. But it means that all linux distro shipping the lib lilv are at risk as of now" I think that's quite reasonable. This is not a very nice thing to have to deal with in your inbox on an otherwise pleasant Sunday. Now you're being defensive and trying to shift the subject to "trying to clarify what is going on here", which... well, no. Asking for clarification would have at least one single question mark in it. You outright stated in a confident and objective-sounding tone, right out of the gate, that this project contains malicious code and that all Linux distributions are compromised by it.

I've told you I don't appreciate that. It's not a debate, and this is not a product/consumer relationship in which I'm obligated to be nice about it. As it happens, I have a universal policy about that with respect to ticket etiquette: I'm nice exactly once. You've spent your one nice token. Thank you for the investigation, truly - however, please be advised that any more defensiveness around this tangent, or any future tickets with an accusatory or entitled or fear-mongering tone, will be met with immediate deletion and, after that, banning if necessary. I really do not like being slandered in exchange for giving people countless thousands of hours of work for free (can you blame me?), and I am far too old and crusty to beat around the bush about it.

[drobilla]

I have no idea how to narrow down what's triggering these in the lilv source code itself (the above check code comes entirely from meson, it's not a custom check), but given that the above pasted check is flagged for some reason, I'm pretty confident in saying that it's not really worth the time anyway. Static code scanners for security and other issues should be taken very seriously with extreme scepticism that anything is actually a false positive, but virus scanners are a very different situation.

If someone else narrows it down, I can try to manipulate things to avoid it, but I'm not about to wade through a bunch of proprietary Windows virus scanners. Last I checked, the built-in one in Windows 10 even flags meson itself, so I doubt this sort of thing is that unusual, although I don't use Windows much so I don't really know.

For the record, since sometimes people get confused by the ubiquitous use of URIs in the LV2 ecosystem: lilv doesn't do any network access whatsoever. It also never writes to disk, with the exception of lilv_state_save for obvious reasons. It's certainly not a hardened library in any sense, but there's very little opportunity for malice here. Particularly since the whole domain is inherently about loading and executing arbitrary native code (plugins) anyway.

(The next major version of lilv will be pretty radically different internally, here's hoping it just goes away for free soon enough)