Is yt-dlp/yt-dlp compromised? | Hacker News Reader

Is yt-dlp/yt-dlp compromised?

github.com

78 pointsforensicnoob37 comments

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.

3f6ab524d899f39ef46004a9db1f09ac8983aa5bd96243c417edf7c0c00627d7 yt-dlp_linux 2024.11.04 dcca6afb6ac9770d4d3425c35e415f4a8fc69b626c60f12ca899bfc05f6a72fc yt-dlp_linux 2024.10.22

When did it do that? yt-dlp uses .onion addresses for some of the sites.

That's not described in the documentation. Does it do that automatically or does it ask for a user action first?

VirusTotal said it is ok?

https://www.virustotal.com/gui/file/3f6ab524d899f39ef46004a9...

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.

PoC Rust program that takes the contents of .npmrc and uploads it to a random IP (DONT RUN THIS! It'll steal your npm authentication token): https://gist.github.com/victorb/adf0ac8b7ada8d5a4982462e24e8...

"No security vendors flagged this file as malicious" = https://www.virustotal.com/gui/file/b99b86a5ce3aa24b39ec53dd...

But clearly, it is malicious :)

I don't understand, the op claims the alert came from Virustotal.

Look at other tabs https://www.virustotal.com/gui/file/3f6ab524d899f39ef46004a9... at the bottom you can see the commands that looks like the program trying to delete down syslogs. Look also in the relations tab that shows some tor nodes.

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.

I don't see anything trying to delete syslogs. There's a line for reloading new configuration (kill -HUP ...) - is that what you meant?

You mean this `systemctl kill -s HUP rsyslog.service` ? This just tells syslog to reload itself

Why would yt-dlp tell syslog to reload?

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.

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.

https://www.virustotal.com/gui/file/dcca6afb6ac9770d4d3425c3...

Says it contacted 45.66.35.11 and you can see its a tor relay https://metrics.torproject.org/rs.html#details/7EA6EAD6FD830...

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.

Its not just a tor relay, it is one of the directory servers: https://metrics.torproject.org/rs.html#search/flag:authority

Did you open an issues on their GitHub page?

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.

[1] https://github.com/yt-dlp/yt-dlp/issues/11451#issuecomment-2...

Can you link to the issue?

Sure: https://github.com/yt-dlp/yt-dlp/issues/11451#issuecomment-2...

I edited my reply too.

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.

Ah yeah that makes sense. I just wanted to confirm it because I couldn't really find anything when I was searching.

Source?

Can you produce some evidence, even a screenshot? It would be helpful.

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.

Is it using Tor to download content?

(The second part of your comment was just normal log rotation as it turns out)

If all you have is results from VirusTotal, this is a nothingburger. Dig into what those calls actually are before you cry wolf.

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.

That would make it our job to teach OP critical thinking.

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.

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.

Wouldn't it make more sense to create an issue on their GitHub repo about this?

agreed , not sure why they think that ycombinator cares more than their official github repo page

If you believe their GitHub org/accounts to be compromised, it kind of makes sense to verify if that's true or not outside of GitHub. With that said, wouldn't hurt with a GitHub issue regardless.

What does this mean for `pip` wheel? I only see source files in the wheel.

I use this daily, and let it use browser cookies. So I hope it's not.

(This green-account poster and post were auto-flagged as spam, but I've spent a [vouch] on them. Be aware that the reply comments they are writing in this thread are also hidden by default).

What's [vouch]?

See https://news.ycombinator.com/newsfaq.html

> If you see a [dead] post that shouldn't be dead, you can vouch for it. Click on its timestamp to go to its page, then click 'vouch' at the top. When enough users do this, the post is restored. There's a small karma threshold before vouch links appear.

https://github.com/minimaxir/hacker-news-undocumented?tab=re...

Reply on news.ycombinator.com