The last linux binaries ( yt-dlp_linux ) are contacting tor exit nodes and attempting to shutdown syslog starting from release 2024.10.22 according to virustotal.
There is nothing about stopping/killing rsyslog in thst virustotal output. `kill -s HUP` sends SIGHUP to a process (read rsyslogd(8) to know how it interprets HUP).
It seems like virustotal also records unrelated processes running on that host, logrotation is a normal thing.
The only thing VirusTotal would tell you about, is already known patterns of virus/malware. If there is a novel/different way of doing something, and/or it hasn't been noticed by the AVs they're collaborating with, you'll end up with everything green.
I think he might be talking about the "relations" tab. You can see the "Contacted IP addresses" section that claims to be "contacted IPs by the file uploaded to virus total". If you click the IP some will have detections and flagged as bad or criminal.
Though haven't looked at how yt-dlp works, I'd guess yt-dlp might attempt to use tor network in case some IP or network is blocked and can't reach a server.
This is not "shutting down" rsyslog. The kill command sends a SIGHUP to rsyslog, which causes it to reopen its log files - what you are seeing is a normal logrotation, not an attempt to terminate the process.
I suspect virustotal did the check in a container with a logrotation job still running, and it happened to run right in the moment when yt-dlp was being tested.
It seems VirusTotal spins up a virtual machine/container to run the program, and monitors what happens inside that environment. And it further seems that during that time syslog (or something else, probably the distribution) reloaded itself. And some other process tried to connect to the TOR IPs.
And since we're all amateurs here who don't understand what VirusTotal is doing, some of us think "ZOMG yt-dlp compromised?!?".
If you look at the process tree, the process that reloaded rsyslog wasn't spawned from the yt-dlp_linux process.
FWIW, It appears one of the people who saw this post asked in a comment in an issue on GitHub [1]:
> @seproDev unrelated, but what you think about https://news.ycombinator.com/item?id=42040600
.. and one of the main maintainers (ranked #14th by #commits, but a recently active maintainer) replied the following:
> False positive in virus total. Calling yt-dlp without any arguments makes no web requests.
> To expand a bit more. Our releases are built with github runners and they report back the sha hash during build. https://github.com/yt-dlp/yt-dlp/actions/runs/11656153929 for the release from yesterday
> You can see the commit that was built, what we merged in the last couple days, and the hash of the resulting files to check against the files in the release section.
> Those network requests are likely just other processes on the machine. I remember windows executable would regularly show microsoft servers in the "connections made" list due to windows update and telemetry still running.
Edit: I'd caution against spamming the maintainers though (not caution you specifically), the possibility of that happening is what swayed me to not post the link originally.
VirusTotal seems to be generating more false positives lately. Seems like they’re adding some poorly written heuristics. We’ve seen problems with false reports of things being infected like our own products.
It's not crying wolf to ask the question (yes, leading questions can be used that way, but they are clearly asking here, not trying to imply), they presented the thing that concerned them to get eyes on it and find out if it was a problem, that seems reasonable.
This is a news aggregator, not a help desk. It's perfectly fair to characterize submitting such entry as "crying wolf", even when it's formulated as a question. When I browse my RSS feed from HN, I expect the items to have at least some minimal substance.
3f6ab524d899f39ef46004a9db1f09ac8983aa5bd96243c417edf7c0c00627d7 yt-dlp_linux 2024.11.04 dcca6afb6ac9770d4d3425c35e415f4a8fc69b626c60f12ca899bfc05f6a72fc yt-dlp_linux 2024.10.22