VirusTotal flagged pluginval_Linux.zip as malicious

[kmturley]

https://www.virustotal.com/gui/file/c01c49d8063965c4c2dea8324468336768f5c9139e0b1caebde14c2400b55352?nocache=1

Security vendors' analysis:

• GData: Linux.Trojan.Agent.EZMRFC
• Google: Detected
• Ikarus: Exploit.GetShell

[drowaudio]

Presumably this is in some Linux dependency? Any idea which package?

[kmturley]

There is more detail on this page:
https://www.virustotal.com/gui/file/c01c49d8063965c4c2dea8324468336768f5c9139e0b1caebde14c2400b55352/behavior

Not 100% sure how to interpret it thought!

[drowaudio]

I think all its doing is setting the process name?

[kmturley]

Gemini LLM summary of the VirusTotal page:

Based on the VirusTotal report and the file's characteristics, this file appears to be a False Positive (a legitimate file incorrectly identified as malicious).

Security vendors often use "heuristics" (behavioral analysis) rather than just exact virus signatures. Pluginval does several things that look suspicious to an automated system but are normal for a testing tool:

"Detect Debug Environment": To test plugins, Pluginval essentially acts like a "debugger," intentionally stressing the code to find crashes. Malware often checks for debuggers to hide itself; Pluginval checks for them to do its job.

"Sets Process Name": It may rename processes to manage the plugins it is testing.

Low Detection Rate (2/66): Only 2 out of 66 vendors flagged it. If this were a true virus, you would typically see detections from major vendors (like Microsoft, Google, Kaspersky, Symantec) and a much higher score.

Gemini LLM summary of this GitHub repo code:

Process Renaming
the "Sets process name" behavior is a major red flag for antivirus heuristics. Malware often renames itself to look like a system process (e.g., bash, syslogd).

Code to Locate: Search the codebase for prctl (specifically PR_SET_NAME) or pthread_setname_np.

Why it flags: If pluginval renames its worker process to the name of the plugin being tested (e.g., changing from pluginval to MyAudioPlugin), antivirus heuristics might see this as "Masquerading" (MITRE ATT&CK T1036).

Improvement:

Modify: Instead of replacing the process name entirely, try appending to it, e.g., pluginval: MyAudioPlugin.

Disable: Make process renaming optional or disable it in release builds if it's purely for cosmetic debug purposes.

Condition: Ensure the new name doesn't mimic sensitive system processes.

Crash Handling & Signals
The "Trojan" and "Exploit" flags often come from how an application handles crashes. pluginval needs to catch plugin crashes to avoid terminating the whole test suite.

Code to Locate: Look for the CrashHandler class or usages of signal(), sigaction(), or ptrace().

Why it flags:

Signal Interception: Catching signals like SIGSEGV (Segmentation Fault) or SIGABRT is legitimate for a tester but is also how malware hides its own instability or analyzes the environment.

Ptrace: If pluginval uses ptrace(PTRACE_TRACEME, ...) to act as a debugger for the child process, this is a "known bad" signature for many AVs because it prevents real debuggers (like the AV's analysis sandbox) from attaching.

Improvement:

If using ptrace for crash catching, switch to using standard core dumps or a less invasive signal handler if possible.

Ensure the signal handler is "async-signal-safe" (which PR #144 seemed to address, but it's worth reviewing if it introduced complex logic that looks like exploit code).

Real-Time Safety Checks (Memory Hooks)
The recent "rtcheck" (Real-time safety checking) updates (PR #156) might be relevant.

Code to Locate: Look for overrides of global malloc, free, or symbols like __interceptor_malloc.

Why it flags: Tools that verify real-time safety often "hook" memory allocation functions to detect when a plugin allocates memory on the audio thread. This technique (function hooking/interception) is identical to how user-mode rootkits and banking trojans steal data.

Improvement:

If these hooks are active in the default build, consider moving them to a separate "debug" library that is only loaded when specifically requested (e.g., via LD_PRELOAD or a specific flag), rather than compiling them directly into the main binary.

I think it is safe to close this, but feel free to keep open if you want!

[drowaudio]

Yes, I think it's benign. Thanks though.