10 ms·

RCE Vulnerability in QBittorrent

376 points by udev4096 2y ago

alecco 2y ago
In qBittorrent, the DownloadManager class has ignored every SSL certificate validation error that has ever happened, on every platform, for 14 years and 6 months since April 6 2010 with commit 9824d86. This looks quite serious.
- SushiHippie 2y ago
  Noteworthy that this wasn't a bug, but a "feature": void downloadThread::ignoreSslErrors(QNetworkReply* reply,QList<QSslError> errors) { // Ignore all SSL errors reply->ignoreSslErrors(errors); } https://github.com/qbittorrent/qBittorrent/commit/9824d86a3cbecc9fd91f0462956ca575ef742110#diff-76a082d0ec1a72c138ddf25cb4da8146a925d25bedf993dedf57bb044e5ac19cR219 https://github.com/qbittorrent/qBittorrent/commit/9824d86a3c...
  - perching_aix 2y ago
    Is the motivation behind this known?
    - SushiHippie 2y ago
      As the commit message was "Fix HTTPS protocol support in torrent/rss downloader" I suppose it was a quick fix to make things work, and as things worked no one ever took a look at it until now. EDIT: The author of the PR[0] (who is one of the top qBittorrent contributors according to GitHub[1]) that fixed this also came to this conclusion: > I presume that it was a quick'n'dirty way to get SSL going which persisted to this day. It's also possible that back in the day Qt4 (?) didn't support autoloading ca root certificates from the OS's store. [0]: https://github.com/qbittorrent/qBittorrent/pull/21364 https://github.com/qbittorrent/qBittorrent/pull/21364 [1]: https://github.com/qbittorrent/qBittorrent/graphs/contributors https://github.com/qbittorrent/qBittorrent/graphs/contributo...
      - 0xsee4 2y ago
        To be fair, this function ignoreSslErrors is not from the authors of qBittorrent, it comes from QT framework. The idea behind the function is that you provide it a small whitelist of errors you wish to ignore, for example in a Dev build you may well want to ignore self-signed errors for your Dev environment. The trouble is, you can call it with no arguments and this means you will ignore every error. This may have been misunderstood by the qBittorrent maintainers, maybe not. Much more likely is that someone knew they had implemented this temporary solution while they implemented OpenSSL in a project which previously never had SSL support - a major change with a lot of work involved - and every programmer knows that there is nothing more permanent than a temporary solution. Especially in this case. I can understand how such code would make it into the repo(I think you do too), and it's very easy for us to say we would then have immediately amended it in the next version to properly verify certs. Having been in contact with the maintainers, I have to say I was disappointed in how seriously they took the issue. I don't want to say any more than that. Source: author of the article
        bdelay 2y ago
        How much notification did you give the developers before you disclosed? Did you enforce a timeline?
        metadat 2y ago
        Warning shots across the bow in private are the polite and responsible way, but malicious actors don't typically extend such courtesies to their victims. As such, compared to the alternative (bad actors having even more time to leverage and amplify the information asymmetry), a timely public disclosure is preferable, even with some unfortunate and unavoidable fallout. Typically security researchers are reasonable and want to do the right thing with regard to responsible disclosure. On average, the "bigger party" inherently has more resources to respond compared to the reporter. This remains true even in open source software.
        tsimionescu 2y ago
    - beeboobaa3 2y ago
      A guess that's probably correct: Many torrent sites (where the client can download .torrent files from when given an URL) their infra sucks. This includes expired certificates. Users don't want to deal with that shit. Developers don't want to deal with users complaining. It's not really considered a risk because lots of those torrent sites (used to) just use HTTP to begin with, so who cares, right?
- deleted 2y ago
  [deleted]
atomicnumber3 2y ago
I've used deluge for longer than I've used almost any other program, I think. I've been pretty happy with their track record (from the perspective of... I've never seen a private tracker ban specific versions of deluge or anything to that effect. Which they've done for many other clients when big vulns drop for them.)
- iamtedd 2y ago
  They failed to produce a build for Windows[1] for years after the official release of v2. They still don't have an official build for MacOS. They say to "check sticky topics on the forum"[2]. Saying that builds exist for those platforms on the homepage still seems a bit disingenuous. 1. https://dev.deluge-torrent.org/ticket/3201 https://dev.deluge-torrent.org/ticket/3201 2. https://deluge.readthedocs.io/en/latest/intro/01-install.html#alternative-installs https://deluge.readthedocs.io/en/latest/intro/01-install.htm...
- bartvk 2y ago
  Deluge has a years-long bug where it ignores proxy settings: https://dev.deluge-torrent.org/ticket/2149#comment:43 https://dev.deluge-torrent.org/ticket/2149#comment:43
password4321 2y ago
It would be incredible to learn how many have actually been affected by this issue in that past ~15 years... how important is SSL validation to those able to blend in with the crowd even on the sketchy-ish side of the internet? So much "just works" because no one is paying attention. Of course now that the spotlight is on the issue it's all downhill from here for anyone who doesn't [auto-]update.
- userbinator 2y ago
  It would be incredible to learn how many have actually been affected by this issue in that past ~15 years IMHO close to 0 --- and for those who were affected, it would've likely been a targeted attack.
- dgfitz 2y ago
  I had the exact same thought. Actually having the data seems almost impossible, it sure would be fun to see.
- 0x457 2y ago
  Probably zero? That thing was reposible for downloading python from python.org. It's possible to exploit, but would need to be pretty targeted and would require already some access to the target[1]. [1]: Because only other way to exploit it would be noticed by everyone else. Like python.org domain would need to be hijacked or something similar.
  - mcmcmc 2y ago
    You don’t need to hijack the whole domain to poison DNS for a given client
    - 0x457 2y ago
      Yes, that's what I meant by other way requires _some_ access to the target.
  - crtasm 2y ago
    It makes a MITM attack possible, that doesn't require access to the target or the website it's contacting. I'd still guess zero times though.
logical_person 2y ago
it's shocking how low-quality these issues are in a client that is otherwise 1000x more performant than the other options listed in the article
- coppsilgold 2y ago
  Deluge performs just as well as qBittorrent. libtorrent-rasterbar (libtorrent.org) is what is performant.
  - deleted 2y ago
    [deleted]
  - magxnta 2y ago
    I found the deluge (web?) ui becoming unusable after adding tens (or hundreds?) of thousands of torrents. Not sure about the details, but a decade ago I used to seed all files below 100MB on many private trackers for seed bonus points, and yea, deluge ui (might have been the web ui, not sure) became very slow. :D
    - dawnerd 2y ago
      Same, deluge and qbittorrent would start to have issues with very large or lots of torrents. Ended up with transmission with the trguiNG UI and its handled everything. It's not perfect and often slow but it hasn't crashed.
    - treyd 2y ago
      I ran into slowdowns in the remote control after just a few hundred. I switched to transmission shortly after. I had a great time using Deluge for probably like 6-7 years but Transmission is more performant has more tooling support.
  - 1oooqooq 2y ago
    moved to transmission
thomas34298 2y ago
>BUGFIX: Don't ignore SSL errors (sledgehammer999) >https://www.qbittorrent.org/news https://www.qbittorrent.org/news There should be a security notice IMO.
rgovostes 2y ago
Any time someone asks about certificate validation errors on StackOverflow, half of the answers show how to disable validation rather than fix the issue. The API calls should be explicit, e.g., youWillBeFiredForFacilitatingManInTheMiddleAttacks().
- lucb1e 2y ago
  Or it should be easier to supply an expected certificate Nearly all the time, the tool doesn't accept the certificate format or it wants a chain instead of just the root because the other side doesn't supply a chain or the CA bundle doesn't match the CA you used or it doesn't use the CA system at all or the fingerprint format is the wrong hash or it wants a file instead of just a command-line fingerprint or there isn't an "at least do TOFU" flag so for testing you resort to "okay then just accept everything"... it's very rarely smooth sailing from the point of "okay I'm ssh'd into the server, now what do I run here to give this tool something it can use to verify the connection" Makes me think of how hard PGP is considered to be. Perhaps key distribution in any asynchronous cryptographic system is simply hard
  - shermantanktop 2y ago
    Key distribution and revocation is pretty much the hard problem, at least in pragmatic terms. The details of cryptographic operations in code get a lot of scrutiny, and even then there are issues. But key management combines crypto complexity with distributed system complexity, and mixes that with human propensity for operational error.
  - chx 2y ago
    > Makes me think of how hard PGP is considered to be https://www.usenix.org/system/files/1401_08-12_mickens.pdf https://www.usenix.org/system/files/1401_08-12_mickens.pdf
  - IshKebab 2y ago
    Yeah the fact that on Linux the certificate bundle can be in literally 10 different locations depending on the distro is pretty embarrassing too.
immibis 2y ago
(if you have MITM)
e-dant 2y ago
[flagged]
- lionkor 2y ago
  Nothing in Rust prevents you from turning off SSL validation
  - IshKebab 2y ago
    That's not quite true. The name is at least better and tries to warn you of the danger: https://docs.rs/reqwest/latest/reqwest/struct.ClientBuilder.html#method.danger_accept_invalid_certs https://docs.rs/reqwest/latest/reqwest/struct.ClientBuilder.... https://docs.rs/rustls/latest/rustls/#rustls-takes-care-of-server-certificate-verification https://docs.rs/rustls/latest/rustls/#rustls-takes-care-of-s...
    - lionkor 2y ago
      that's a library, not the standard library, and not a language feature
      - IshKebab 2y ago
        So? Qt is a library too. And it is a cultural feature of the language. Rust libraries and code tends to highly value correctness. Find my a Python or C library that tries to prevent you from disabling certificate validation like that. I'll wait.
duskwuff 2y ago
This seems a little overblown, especially towards the later points. > 1. Malicious Executable loader with stealth functionality TL;DR the client downloads Python from python.org over HTTPS. This isn't great (especially since it's hard-coded to 3.12.4), but there's no obvious exploit path which doesn't involve both MITM and user interaction. > 2. Browser Hijacking + Executable Download (Software Upgrade Context) TL;DR the client downloads an RSS file over HTTPS and will conditionally prompt the user to open a URL found in that file. This is even lower risk than #1; even if you can MITM the user and get them to click "update", all you get to do with that is show the user a web page. > 3. RSS Feeds (Arbitrary URL injection) The researcher seems confused by the expected behavior of an RSS client. > 4. Decompression library attack surface (0-click) If you can find an exploit in zlib, there are much worse things you can do with that than attacking a torrent client. Decompressing input is assumed to be safe by default.
- consp 2y ago
  > If you can find an exploit in zlib, there are much worse things you can do with that than attacking a torrent client. Decompressing input is assumed to be safe by default. Any (e.g. http) server supporting stream compression comes to mind.
  - duskwuff 2y ago
    Or, on the client side, any software that uses libpng to render PNG images (since that's using deflate on the inside). There's probably even more direct exploits against qbittorrent than MITMing the GeoIP database download.
- sdefresne 2y ago
  Those are minor if certificates errors are not ignored. Since the original issue is that the ssl errors are ignored, then all those https downloads are downgraded to http downloads in practice (no need to mitm to attack). Or to say it another way, due to ignoring ssl errors, all those https urls were giving a wrong sense of security as reviewers would think them secure when they were not (due to lack of validation of ssl).
EVa5I7bHFq9mnYK 2y ago
Thank you. Uninstalled.
- cbg0 2y ago
  If you knew how much of a common thing this is you'd probably just uninstall everything.
  - EVa5I7bHFq9mnYK 2y ago
    Thank you, BRB.
    - ykonstant 2y ago
      and that was the last time anyone say EVa5I7bHFq9mnYK online
      - EasyMark 2y ago
        R.I.P. bruv. I wonder why people always overreact to stuff like this. qBittorrent is a great piece of software and I pay homage to the developers.
- EasyMark 2y ago
  You might as uninstall everything on your computer. Rust isn't immune to stuff like this either, this is a logic/security mistake error.
fulafel 2y ago
What's considered the most secure Bittorrent app?
- niceguy4 2y ago
  qBittorrent after the most recent update...
  - johnisgood 2y ago
    Why not Transmission?
    - EasyMark 2y ago
      transmission is great if you're just getting linux images, but it's much easier to configure qbittorrent for stuff like VPN lockout and such
      - ndsipa_pomu 2y ago
        It's pretty easy to combine docker containers for torrenting and a VPN so that the torrenting doesn't get any network access until the VPN successfully connects. However, I use qbittorrent myself (containerised of course).
      - johnisgood 2y ago
        Why for Linux images only? I use it with everything. You do not even need to use the GUI, there is transmission-cli. There is transmission-daemon as well, controlled by transmission-remote (or Transmission's web interface), meaning that you can use it on a seedbox.
- 0points 2y ago
  The one in a restricted container.
  - steelframe 2y ago
sneak 2y ago
Even with a proper certificate check, downloading and running a remote executable is by definition an RCE vulnerability. Syncthing does this too (though presumably with a certificate check). Automatic unattended autoupdate is logically indistinguishable from a RAT/trojan.
- gertop 2y ago
  > Even with a proper certificate check, downloading and running a remote executable is by definition an RCE vulnerability. It literally is not.
- bmacho 2y ago
  > Automatic unattended autoupdate is logically indistinguishable from a RAT/trojan. What about: the same people do the automatic unattended autoupdate that you downloaded the original program from, or not?
  - TeMPOraL 2y ago
    Does it matter? Do you consider them a trusted party indefinitely? Think at scale of years, and think of e.g. Microsoft of Adobe when pondering this question.
    - ripdog 2y ago
      Then just turn it off. qBT isn't windows, it doesn't demand autoupdate. That said, you really shouldn't be running outdated torrent clients, like any network-connected programs. Case in point - the topic of this thread.
  - sneak 2y ago
    Absolutely not. GitHub is usually used as a CDN for updates distributed in binary form; it is run by Microsoft. If I download source and build and run it, and it downloads binaries from Microsoft and runs those, that isn’t remotely “the same people”.
    - 2y ago
0x38B 2y ago
For compiling and running the latest version, https://github.com/userdocs/qbittorrent-nox-static https://github.com/userdocs/qbittorrent-nox-static is a nice helper script to build a static binary using Docker - I wanted to run 5.0.0 using libtorrent 1.2, and found the script by far the easiest way.
- TechDebtDevin 2y ago
  *inserts backdoor*
  - agartner 2y ago
    There are attestations that the binaries were built via CI: https://userdocs.github.io/qbittorrent-nox-static/artifact-attestations/ https://userdocs.github.io/qbittorrent-nox-static/artifact-a... Here's a verification of the latest build: gh attestation verify x86_64-qbittorrent-nox -o userdocs Loaded digest sha256:af9ceace3fea1418ebd98cd7a8a7b6e06c3d8d768f4d9c9ce0d3e9a3256f40d9 for file://x86_64-qbittorrent-nox Loaded 1 attestation from GitHub API Verification succeeded! sha256:af9ceace3fea1418ebd98cd7a8a7b6e06c3d8d768f4d9c9ce0d3e9a3256f40d9 was attested by: REPO PREDICATE_TYPE WORKFLOW userdocs/qbittorrent-nox-static https://slsa.dev/provenance/v1 .github/workflows/matrix_multi_build_and_release_qbt_workflow_files.yml@refs/heads/master
kasabali 2y ago
> If you click or hit enter on the auto-selected ‘Yes’ option, qBittorrent will then *download, execute the .exe* No shit. Yet another case of "security" people making a mountain out of a molehill for making a name for themselves. Linus was right :p
peanut-walrus 2y ago
Not to downplay this vulnerability, but I feel like relying on (valid tls cert+domain name) combination as the only line of defense for code paths which allow remote code exec is a recipe for disaster. At a minimum, if your application is downloading and executing some artifact from the internet, it should always be fixed to a particular version of the artifact and it should verify the hash of the downloaded artifact before executing.
- hypeatei 2y ago
  I think that would be challenging due to the nature of a potential man-in-the-middle attack here. An attacker could view and change contents of the request therefore making the hash check useless (other than for integrity) Automatic updates and/or checks to a domain from a desktop app is a security angle that doesn't seem to be given as much attention overall. There are other scenarios like a hostile domain takeover (e.g. the original author stops renewing) which I haven't found a good solution to.
  - dinosaurdynasty 2y ago
    You can sign updates with an offline key (ideally like a hardware key), this is what APT based repositories do/allow
    - hypeatei 2y ago
      Sure, but how do you deal with expiration or revocation of that key? If someone is using an old version which doesn't know about the new key then you're back at square one right?
      - freedomben 2y ago
        Linux package managers like apt and dnf deal with this as well. When a key is getting old, you generate a new key with an updated expiration and push it out using the old key to verify it. If the old key expires before a new key is delivered, then you have a problem. This has happened to me a few times and it is a pain in the butt. You basically have to disable key checking in order to receive the new key, which breaks the security.
dgfitz 2y ago
Ask chat gpt: which open source codebases have active ssl vulnerabilities.
ptx 2y ago
Although it wasn't the cause of this particular vulnerability, this kind of application, which communicates with large numbers of potentially malicious nodes, seems like it would really benefit from memory safety, but all the current implementations seem to be written in C++. (The article does mention the potential for this kind of vulnerability in point 4.) Even Deluge, which is written in Python, relies on libtorrent which is written in C++. I don't suppose there is a modern fork of the old Java-based Azureus client? Many BitTorrent clients nowadays split the GUI from the daemon process handling the actual torrenting, so using Java for the daemon and connecting it to a native GUI could strike a good balance between security, performance and user experience.
- xelamonster 2y ago
  I'm going to ask a lazy question instead of figuring it out myself for the sake of discussion, feel free to ignore if I should just Google it: Where would one start in building an alternative to libtorrent? Have there been any attempts (or successes)? Any functional clients that use other implementations?
  - result2vino 2y ago
    libtorrent’s configuration documentation gives a glimpse into the massive hidden complexity of writing a good, performant, resilient client.
- 65a 2y ago
  There are several pure Go bittorrent libraries from a cursory search
  - ptx 2y ago
    Are there any GUI clients based on those libraries? Wikipedia's list[0] doesn't include any. But it does include, I see now, exactly what I was asking for – apparently there's an actively developed fork of Azureus called BiglyBT[1]. [0] https://en.wikipedia.org/wiki/Comparison_of_BitTorrent_clients#Interface_and_programming https://en.wikipedia.org/wiki/Comparison_of_BitTorrent_clien... [1] https://github.com/BiglySoftware/BiglyBT https://github.com/BiglySoftware/BiglyBT
rustcleaner 2y ago
This, folks, is why when I LARP as a QBittorrent-wielding copyright infringer, I LARP using Qubes OS! Qubes OS: Shut it, I'm LARPing (in minecraft)!
PenisBanana 2y ago
If you had seen the qbittorrent code . . . it's _awful_. Pages long un-commented functions, single spaced, appearing most like the prison notebooks of a wrongly-incarcerated psychotic. No testing of any return values at all (in the small part - a few packed pages - of the code that I looked at). There was some field and if it got a correct 3-char (instead of the usual correct 2-char) value, the program would crash or something a minute or so later (I forget). As I was paid to program C++ ~~once~~ twice about 20 years ago, and from a "why don't _you_ have a look at it" message from a maintainer (which was 100% fair-enough, I thought) I ran it in a debugger. I got to the wrong & correct value(s) being read in from the GUI . . . and started following it/them . . . and then . . . so now there a -1 being passed around, and now everything just carries on, for a while. Eventually the wrong valued-run would crash in some somewhat remote function with a wrongly-incarcerated psychotic's error message. one of the real qbittorrent programmers did, then, fix it next release. But any how ...

376 points by udev4096 2y ago

In qBittorrent, the DownloadManager class has ignored every SSL certificate validation error that has ever happened, on every platform, for 14 years and 6 months since April 6 2010 with commit 9824d86. This looks quite serious.

SushiHippie 2y ago
Noteworthy that this wasn't a bug, but a "feature": void downloadThread::ignoreSslErrors(QNetworkReply* reply,QList<QSslError> errors) { // Ignore all SSL errors reply->ignoreSslErrors(errors); } https://github.com/qbittorrent/qBittorrent/commit/9824d86a3cbecc9fd91f0462956ca575ef742110#diff-76a082d0ec1a72c138ddf25cb4da8146a925d25bedf993dedf57bb044e5ac19cR219 https://github.com/qbittorrent/qBittorrent/commit/9824d86a3c...
- perching_aix 2y ago
  Is the motivation behind this known?
  - SushiHippie 2y ago
    As the commit message was "Fix HTTPS protocol support in torrent/rss downloader" I suppose it was a quick fix to make things work, and as things worked no one ever took a look at it until now. EDIT: The author of the PR[0] (who is one of the top qBittorrent contributors according to GitHub[1]) that fixed this also came to this conclusion: > I presume that it was a quick'n'dirty way to get SSL going which persisted to this day. It's also possible that back in the day Qt4 (?) didn't support autoloading ca root certificates from the OS's store. [0]: https://github.com/qbittorrent/qBittorrent/pull/21364 https://github.com/qbittorrent/qBittorrent/pull/21364 [1]: https://github.com/qbittorrent/qBittorrent/graphs/contributors https://github.com/qbittorrent/qBittorrent/graphs/contributo...
    - 0xsee4 2y ago
      To be fair, this function ignoreSslErrors is not from the authors of qBittorrent, it comes from QT framework. The idea behind the function is that you provide it a small whitelist of errors you wish to ignore, for example in a Dev build you may well want to ignore self-signed errors for your Dev environment. The trouble is, you can call it with no arguments and this means you will ignore every error. This may have been misunderstood by the qBittorrent maintainers, maybe not. Much more likely is that someone knew they had implemented this temporary solution while they implemented OpenSSL in a project which previously never had SSL support - a major change with a lot of work involved - and every programmer knows that there is nothing more permanent than a temporary solution. Especially in this case. I can understand how such code would make it into the repo(I think you do too), and it's very easy for us to say we would then have immediately amended it in the next version to properly verify certs. Having been in contact with the maintainers, I have to say I was disappointed in how seriously they took the issue. I don't want to say any more than that. Source: author of the article
      - bdelay 2y ago
        How much notification did you give the developers before you disclosed? Did you enforce a timeline?
        metadat 2y ago
        Warning shots across the bow in private are the polite and responsible way, but malicious actors don't typically extend such courtesies to their victims. As such, compared to the alternative (bad actors having even more time to leverage and amplify the information asymmetry), a timely public disclosure is preferable, even with some unfortunate and unavoidable fallout. Typically security researchers are reasonable and want to do the right thing with regard to responsible disclosure. On average, the "bigger party" inherently has more resources to respond compared to the reporter. This remains true even in open source software.
        tsimionescu 2y ago
  - beeboobaa3 2y ago
    A guess that's probably correct: Many torrent sites (where the client can download .torrent files from when given an URL) their infra sucks. This includes expired certificates. Users don't want to deal with that shit. Developers don't want to deal with users complaining. It's not really considered a risk because lots of those torrent sites (used to) just use HTTP to begin with, so who cares, right?
deleted 2y ago
[deleted]

atomicnumber3 2y ago

I've used deluge for longer than I've used almost any other program, I think. I've been pretty happy with their track record (from the perspective of... I've never seen a private tracker ban specific versions of deluge or anything to that effect. Which they've done for many other clients when big vulns drop for them.)

iamtedd 2y ago
They failed to produce a build for Windows[1] for years after the official release of v2. They still don't have an official build for MacOS. They say to "check sticky topics on the forum"[2]. Saying that builds exist for those platforms on the homepage still seems a bit disingenuous. 1. https://dev.deluge-torrent.org/ticket/3201 https://dev.deluge-torrent.org/ticket/3201 2. https://deluge.readthedocs.io/en/latest/intro/01-install.html#alternative-installs https://deluge.readthedocs.io/en/latest/intro/01-install.htm...
bartvk 2y ago
Deluge has a years-long bug where it ignores proxy settings: https://dev.deluge-torrent.org/ticket/2149#comment:43 https://dev.deluge-torrent.org/ticket/2149#comment:43

password4321 2y ago

It would be incredible to learn how many have actually been affected by this issue in that past ~15 years... how important is SSL validation to those able to blend in with the crowd even on the sketchy-ish side of the internet? So much "just works" because no one is paying attention. Of course now that the spotlight is on the issue it's all downhill from here for anyone who doesn't [auto-]update.

userbinator 2y ago
It would be incredible to learn how many have actually been affected by this issue in that past ~15 years IMHO close to 0 --- and for those who were affected, it would've likely been a targeted attack.
dgfitz 2y ago
I had the exact same thought. Actually having the data seems almost impossible, it sure would be fun to see.
0x457 2y ago
Probably zero? That thing was reposible for downloading python from python.org. It's possible to exploit, but would need to be pretty targeted and would require already some access to the target[1]. [1]: Because only other way to exploit it would be noticed by everyone else. Like python.org domain would need to be hijacked or something similar.
- mcmcmc 2y ago
  You don’t need to hijack the whole domain to poison DNS for a given client
  - 0x457 2y ago
    Yes, that's what I meant by other way requires _some_ access to the target.
- crtasm 2y ago
  It makes a MITM attack possible, that doesn't require access to the target or the website it's contacting. I'd still guess zero times though.

logical_person 2y ago

it's shocking how low-quality these issues are in a client that is otherwise 1000x more performant than the other options listed in the article

coppsilgold 2y ago
Deluge performs just as well as qBittorrent. libtorrent-rasterbar (libtorrent.org) is what is performant.
- deleted 2y ago
  [deleted]
- magxnta 2y ago
  I found the deluge (web?) ui becoming unusable after adding tens (or hundreds?) of thousands of torrents. Not sure about the details, but a decade ago I used to seed all files below 100MB on many private trackers for seed bonus points, and yea, deluge ui (might have been the web ui, not sure) became very slow. :D
  - dawnerd 2y ago
    Same, deluge and qbittorrent would start to have issues with very large or lots of torrents. Ended up with transmission with the trguiNG UI and its handled everything. It's not perfect and often slow but it hasn't crashed.
  - treyd 2y ago
    I ran into slowdowns in the remote control after just a few hundred. I switched to transmission shortly after. I had a great time using Deluge for probably like 6-7 years but Transmission is more performant has more tooling support.
- 1oooqooq 2y ago
  moved to transmission

thomas34298 2y ago

>BUGFIX: Don't ignore SSL errors (sledgehammer999) >https://www.qbittorrent.org/news https://www.qbittorrent.org/news There should be a security notice IMO.

rgovostes 2y ago

Any time someone asks about certificate validation errors on StackOverflow, half of the answers show how to disable validation rather than fix the issue. The API calls should be explicit, e.g., youWillBeFiredForFacilitatingManInTheMiddleAttacks().

lucb1e 2y ago
Or it should be easier to supply an expected certificate Nearly all the time, the tool doesn't accept the certificate format or it wants a chain instead of just the root because the other side doesn't supply a chain or the CA bundle doesn't match the CA you used or it doesn't use the CA system at all or the fingerprint format is the wrong hash or it wants a file instead of just a command-line fingerprint or there isn't an "at least do TOFU" flag so for testing you resort to "okay then just accept everything"... it's very rarely smooth sailing from the point of "okay I'm ssh'd into the server, now what do I run here to give this tool something it can use to verify the connection" Makes me think of how hard PGP is considered to be. Perhaps key distribution in any asynchronous cryptographic system is simply hard
- shermantanktop 2y ago
  Key distribution and revocation is pretty much the hard problem, at least in pragmatic terms. The details of cryptographic operations in code get a lot of scrutiny, and even then there are issues. But key management combines crypto complexity with distributed system complexity, and mixes that with human propensity for operational error.
- chx 2y ago
  > Makes me think of how hard PGP is considered to be https://www.usenix.org/system/files/1401_08-12_mickens.pdf https://www.usenix.org/system/files/1401_08-12_mickens.pdf
- IshKebab 2y ago
  Yeah the fact that on Linux the certificate bundle can be in literally 10 different locations depending on the distro is pretty embarrassing too.

immibis 2y ago

(if you have MITM)

e-dant 2y ago

[flagged]

lionkor 2y ago
Nothing in Rust prevents you from turning off SSL validation
- IshKebab 2y ago
  That's not quite true. The name is at least better and tries to warn you of the danger: https://docs.rs/reqwest/latest/reqwest/struct.ClientBuilder.html#method.danger_accept_invalid_certs https://docs.rs/reqwest/latest/reqwest/struct.ClientBuilder.... https://docs.rs/rustls/latest/rustls/#rustls-takes-care-of-server-certificate-verification https://docs.rs/rustls/latest/rustls/#rustls-takes-care-of-s...
  - lionkor 2y ago
    that's a library, not the standard library, and not a language feature
    - IshKebab 2y ago
      So? Qt is a library too. And it is a cultural feature of the language. Rust libraries and code tends to highly value correctness. Find my a Python or C library that tries to prevent you from disabling certificate validation like that. I'll wait.

duskwuff 2y ago

This seems a little overblown, especially towards the later points. > 1. Malicious Executable loader with stealth functionality TL;DR the client downloads Python from python.org over HTTPS. This isn't great (especially since it's hard-coded to 3.12.4), but there's no obvious exploit path which doesn't involve both MITM and user interaction. > 2. Browser Hijacking + Executable Download (Software Upgrade Context) TL;DR the client downloads an RSS file over HTTPS and will conditionally prompt the user to open a URL found in that file. This is even lower risk than #1; even if you can MITM the user and get them to click "update", all you get to do with that is show the user a web page. > 3. RSS Feeds (Arbitrary URL injection) The researcher seems confused by the expected behavior of an RSS client. > 4. Decompression library attack surface (0-click) If you can find an exploit in zlib, there are much worse things you can do with that than attacking a torrent client. Decompressing input is assumed to be safe by default.

consp 2y ago
> If you can find an exploit in zlib, there are much worse things you can do with that than attacking a torrent client. Decompressing input is assumed to be safe by default. Any (e.g. http) server supporting stream compression comes to mind.
- duskwuff 2y ago
  Or, on the client side, any software that uses libpng to render PNG images (since that's using deflate on the inside). There's probably even more direct exploits against qbittorrent than MITMing the GeoIP database download.
sdefresne 2y ago
Those are minor if certificates errors are not ignored. Since the original issue is that the ssl errors are ignored, then all those https downloads are downgraded to http downloads in practice (no need to mitm to attack). Or to say it another way, due to ignoring ssl errors, all those https urls were giving a wrong sense of security as reviewers would think them secure when they were not (due to lack of validation of ssl).

EVa5I7bHFq9mnYK 2y ago

Thank you. Uninstalled.

cbg0 2y ago
If you knew how much of a common thing this is you'd probably just uninstall everything.
- EVa5I7bHFq9mnYK 2y ago
  Thank you, BRB.
  - ykonstant 2y ago
    and that was the last time anyone say EVa5I7bHFq9mnYK online
    - EasyMark 2y ago
      R.I.P. bruv. I wonder why people always overreact to stuff like this. qBittorrent is a great piece of software and I pay homage to the developers.
EasyMark 2y ago
You might as uninstall everything on your computer. Rust isn't immune to stuff like this either, this is a logic/security mistake error.

fulafel 2y ago

What's considered the most secure Bittorrent app?

niceguy4 2y ago
qBittorrent after the most recent update...
- johnisgood 2y ago
  Why not Transmission?
  - EasyMark 2y ago
    transmission is great if you're just getting linux images, but it's much easier to configure qbittorrent for stuff like VPN lockout and such
    - ndsipa_pomu 2y ago
      It's pretty easy to combine docker containers for torrenting and a VPN so that the torrenting doesn't get any network access until the VPN successfully connects. However, I use qbittorrent myself (containerised of course).
    - johnisgood 2y ago
      Why for Linux images only? I use it with everything. You do not even need to use the GUI, there is transmission-cli. There is transmission-daemon as well, controlled by transmission-remote (or Transmission's web interface), meaning that you can use it on a seedbox.
0points 2y ago
The one in a restricted container.
- steelframe 2y ago

sneak 2y ago

Even with a proper certificate check, downloading and running a remote executable is by definition an RCE vulnerability. Syncthing does this too (though presumably with a certificate check). Automatic unattended autoupdate is logically indistinguishable from a RAT/trojan.

gertop 2y ago
> Even with a proper certificate check, downloading and running a remote executable is by definition an RCE vulnerability. It literally is not.
bmacho 2y ago
> Automatic unattended autoupdate is logically indistinguishable from a RAT/trojan. What about: the same people do the automatic unattended autoupdate that you downloaded the original program from, or not?
- TeMPOraL 2y ago
  Does it matter? Do you consider them a trusted party indefinitely? Think at scale of years, and think of e.g. Microsoft of Adobe when pondering this question.
  - ripdog 2y ago
    Then just turn it off. qBT isn't windows, it doesn't demand autoupdate. That said, you really shouldn't be running outdated torrent clients, like any network-connected programs. Case in point - the topic of this thread.
- sneak 2y ago
  Absolutely not. GitHub is usually used as a CDN for updates distributed in binary form; it is run by Microsoft. If I download source and build and run it, and it downloads binaries from Microsoft and runs those, that isn’t remotely “the same people”.
  - 2y ago

0x38B 2y ago

For compiling and running the latest version, https://github.com/userdocs/qbittorrent-nox-static https://github.com/userdocs/qbittorrent-nox-static is a nice helper script to build a static binary using Docker - I wanted to run 5.0.0 using libtorrent 1.2, and found the script by far the easiest way.

TechDebtDevin 2y ago
*inserts backdoor*
- agartner 2y ago
  There are attestations that the binaries were built via CI: https://userdocs.github.io/qbittorrent-nox-static/artifact-attestations/ https://userdocs.github.io/qbittorrent-nox-static/artifact-a... Here's a verification of the latest build: gh attestation verify x86_64-qbittorrent-nox -o userdocs Loaded digest sha256:af9ceace3fea1418ebd98cd7a8a7b6e06c3d8d768f4d9c9ce0d3e9a3256f40d9 for file://x86_64-qbittorrent-nox Loaded 1 attestation from GitHub API Verification succeeded! sha256:af9ceace3fea1418ebd98cd7a8a7b6e06c3d8d768f4d9c9ce0d3e9a3256f40d9 was attested by: REPO PREDICATE_TYPE WORKFLOW userdocs/qbittorrent-nox-static https://slsa.dev/provenance/v1 .github/workflows/matrix_multi_build_and_release_qbt_workflow_files.yml@refs/heads/master

kasabali 2y ago

> If you click or hit enter on the auto-selected ‘Yes’ option, qBittorrent will then *download, execute the .exe* No shit. Yet another case of "security" people making a mountain out of a molehill for making a name for themselves. Linus was right :p

peanut-walrus 2y ago

Not to downplay this vulnerability, but I feel like relying on (valid tls cert+domain name) combination as the only line of defense for code paths which allow remote code exec is a recipe for disaster. At a minimum, if your application is downloading and executing some artifact from the internet, it should always be fixed to a particular version of the artifact and it should verify the hash of the downloaded artifact before executing.

hypeatei 2y ago
I think that would be challenging due to the nature of a potential man-in-the-middle attack here. An attacker could view and change contents of the request therefore making the hash check useless (other than for integrity) Automatic updates and/or checks to a domain from a desktop app is a security angle that doesn't seem to be given as much attention overall. There are other scenarios like a hostile domain takeover (e.g. the original author stops renewing) which I haven't found a good solution to.
- dinosaurdynasty 2y ago
  You can sign updates with an offline key (ideally like a hardware key), this is what APT based repositories do/allow
  - hypeatei 2y ago
    Sure, but how do you deal with expiration or revocation of that key? If someone is using an old version which doesn't know about the new key then you're back at square one right?
    - freedomben 2y ago
      Linux package managers like apt and dnf deal with this as well. When a key is getting old, you generate a new key with an updated expiration and push it out using the old key to verify it. If the old key expires before a new key is delivered, then you have a problem. This has happened to me a few times and it is a pain in the butt. You basically have to disable key checking in order to receive the new key, which breaks the security.

dgfitz 2y ago

Ask chat gpt: which open source codebases have active ssl vulnerabilities.

ptx 2y ago

Although it wasn't the cause of this particular vulnerability, this kind of application, which communicates with large numbers of potentially malicious nodes, seems like it would really benefit from memory safety, but all the current implementations seem to be written in C++. (The article does mention the potential for this kind of vulnerability in point 4.) Even Deluge, which is written in Python, relies on libtorrent which is written in C++. I don't suppose there is a modern fork of the old Java-based Azureus client? Many BitTorrent clients nowadays split the GUI from the daemon process handling the actual torrenting, so using Java for the daemon and connecting it to a native GUI could strike a good balance between security, performance and user experience.

xelamonster 2y ago
I'm going to ask a lazy question instead of figuring it out myself for the sake of discussion, feel free to ignore if I should just Google it: Where would one start in building an alternative to libtorrent? Have there been any attempts (or successes)? Any functional clients that use other implementations?
- result2vino 2y ago
  libtorrent’s configuration documentation gives a glimpse into the massive hidden complexity of writing a good, performant, resilient client.
65a 2y ago
There are several pure Go bittorrent libraries from a cursory search
- ptx 2y ago
  Are there any GUI clients based on those libraries? Wikipedia's list[0] doesn't include any. But it does include, I see now, exactly what I was asking for – apparently there's an actively developed fork of Azureus called BiglyBT[1]. [0] https://en.wikipedia.org/wiki/Comparison_of_BitTorrent_clients#Interface_and_programming https://en.wikipedia.org/wiki/Comparison_of_BitTorrent_clien... [1] https://github.com/BiglySoftware/BiglyBT https://github.com/BiglySoftware/BiglyBT

rustcleaner 2y ago

This, folks, is why when I LARP as a QBittorrent-wielding copyright infringer, I LARP using Qubes OS! Qubes OS: Shut it, I'm LARPing (in minecraft)!

PenisBanana 2y ago

If you had seen the qbittorrent code . . . it's _awful_. Pages long un-commented functions, single spaced, appearing most like the prison notebooks of a wrongly-incarcerated psychotic. No testing of any return values at all (in the small part - a few packed pages - of the code that I looked at). There was some field and if it got a correct 3-char (instead of the usual correct 2-char) value, the program would crash or something a minute or so later (I forget). As I was paid to program C++ ~~once~~ twice about 20 years ago, and from a "why don't _you_ have a look at it" message from a maintainer (which was 100% fair-enough, I thought) I ran it in a debugger. I got to the wrong & correct value(s) being read in from the GUI . . . and started following it/them . . . and then . . . so now there a -1 being passed around, and now everything just carries on, for a while. Eventually the wrong valued-run would crash in some somewhat remote function with a wrongly-incarcerated psychotic's error message. one of the real qbittorrent programmers did, then, fix it next release. But any how ...