6 ms·

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 i

by 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
    This is a pretty dangerous take. The reality is that the vast majority of security vulnerabilities in software are not actively exploited, beause no one knows about them. Unless you have proof of active exploitation, you are much more likely to hurt users by publicly disclosing a 0-day than by responsibly disclosing it to the developer and giving them a reasonable amount of time to come out with a patch. Even if the developers are acting badly. Making a vulnerability public is putting a target on every user, not on the developer.
    - wisemang 2y ago
      Your take is the dangerous one. I don’t disagree that > the vast majority of security vulnerabilities in software are not actively exploited However I’d say your explanation that it’s > because no one knows about them is not necessarily the reason why. If the vendor or developer isn’t fixing things, going public is the correct option. (I agree some lead time / attempt at coordinated disclosure is preferable here.)
      - tsimionescu 2y ago
        > (I agree some lead time / attempt at coordinated disclosure is preferable here.) Then I think we are in agreement overall. I took your initial comment to mean that as soon as you discover a vulnerability, you should make it public. If we agree that the process should always be to disclose it to the project, wait some amount of time, and only then make it public - then I think we are actually on the exact same page. Now, for the specific amount of time: ideally, you'd wait until the project has a patch available, if they are collaborating and prioritizing things appropriately. However, if they are dragging their feet and/or not even acknowledging that a fix is needed, then I also agree that you should set a fixed time as a last ditch attempt to get them to fix it (say, "2 weeks from today"), and then make it public as a 0-day.
        wisemang 2y ago
        Indeed, we’re in agreement. Though I’d suggest a fixed disclosure timeframe at time of reporting. Maybe with an option to extend in cases where the fix is more complex than anticipated.
- 0xsee4 2y ago
  In total it was about 45 days or so from the initial conversation. I waited for a patched version to be released, because the next important milestone after that would be finished backports to older versions still in use, which is clearly going to take a long time as it is not being prioritized, so I wanted to inform users. Initially I had said 90 days from the initial report, but it seemed like they were expanding the work to fill that time. I asked a number of times for them to make a security advisory and got no answer. Some discussions on the repo showed they were considering this as a theoretical issue. Now it's CVE-2024-51774, which got assigned within 48 hours of disclosing.
  - perching_aix 2y ago
    > Some discussions on the repo showed they were considering this as a theoretical issue. That's hilarious. It's all theoretical until it's getting exploited in the wild...
    - hsbauauvhabzb 2y ago
      Any proof that actually happened or you just wearing a tin foil hat? Crypto enforcement en masse matter, intercepting highly specific targets using BitTorrent does not.
      - tga_d 2y ago
        I feel as though there is a generational gap developing between people who do and do not remember how prolific Firesheep used to be.
      - perching_aix 2y ago
        I think a better question is: why are you looking for evidence (not proof!) on me for something you are supposing?
      - Jerrrrrrry 2y ago
        Lol wait til you get personally targeted by a 0'day in extremely popular software for that sentiment to make you look stupid both ways.
kgeist 2y ago
Temporary solutions can become more dangerous with time. Years ago, in one of our projects, someone wrote a small helper class, HTTPClient, to talk to one of our internal subsystems. The subsystem in the dev environment used self-signed certificates, so one of the devs just disabled SSL validation. Whether SSL errors were ignored or not was specified in a config. Later, someone messed up while editing the configs, and SSL validation got disabled in the live environment, too. No one noticed, because nobody writes tests to check if SSL validation is enabled. But that's only part of the story, this HTTPClient class was still only used to communicate with our internal subsystem on our own network. The real problem came later when the next generation of developers saw this HTTPClient class and thought, "Hey, what a nifty little helper!", and soon they were using it to talk to pretty much everything, including financial systems. I was shocked when I discovered it. An inconsequential temporary workaround had turned into a huge security hole.
xelamonster 2y ago
This is interesting, I haven't ever used the Qt framework but I'm surprised that it would even have an SSL implementation, sounds a bit out of scope for a GUI toolkit. I think I'd prefer to do all my networking separately and provide the fetched data to Qt. Edit (just noticed this was the author): I'm curious what torrent client do you prefer? I like Deluge but mostly go to it because it's familiar.
- ripdog 2y ago
  Qt isn't just a GUI toolkit - it's an everything toolkit. It's somewhat intended to be used (potentially) alone with C++ to allow the creation of a wide variety of apps. It includes modules like Bluetooth, Network, Multimedia, OAuth, Threading and XML. See a full list: https://doc.qt.io/qt-6/index.html https://doc.qt.io/qt-6/index.html
  - pjmlp 2y ago
    In the spirit of the C++ compiler frameworks that were quite common during the 1990's before C++98, and then we got quite a thin standard library instead, and a mess of how to manage third parties that is still being sorted out.
deleted 2y ago
[deleted]
- immibis 2y ago
  [dead]
tagyro 2y ago
(most?) programming languages have a way to handle these scenarios, something like `#warning | TODO | FIXME` ... I understand temporary, but 14 years seems a bit ...too long

by 0xsee4 2y ago

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
  This is a pretty dangerous take. The reality is that the vast majority of security vulnerabilities in software are not actively exploited, beause no one knows about them. Unless you have proof of active exploitation, you are much more likely to hurt users by publicly disclosing a 0-day than by responsibly disclosing it to the developer and giving them a reasonable amount of time to come out with a patch. Even if the developers are acting badly. Making a vulnerability public is putting a target on every user, not on the developer.
  - wisemang 2y ago
    Your take is the dangerous one. I don’t disagree that > the vast majority of security vulnerabilities in software are not actively exploited However I’d say your explanation that it’s > because no one knows about them is not necessarily the reason why. If the vendor or developer isn’t fixing things, going public is the correct option. (I agree some lead time / attempt at coordinated disclosure is preferable here.)
    - tsimionescu 2y ago
      > (I agree some lead time / attempt at coordinated disclosure is preferable here.) Then I think we are in agreement overall. I took your initial comment to mean that as soon as you discover a vulnerability, you should make it public. If we agree that the process should always be to disclose it to the project, wait some amount of time, and only then make it public - then I think we are actually on the exact same page. Now, for the specific amount of time: ideally, you'd wait until the project has a patch available, if they are collaborating and prioritizing things appropriately. However, if they are dragging their feet and/or not even acknowledging that a fix is needed, then I also agree that you should set a fixed time as a last ditch attempt to get them to fix it (say, "2 weeks from today"), and then make it public as a 0-day.
      - wisemang 2y ago
        Indeed, we’re in agreement. Though I’d suggest a fixed disclosure timeframe at time of reporting. Maybe with an option to extend in cases where the fix is more complex than anticipated.
0xsee4 2y ago
In total it was about 45 days or so from the initial conversation. I waited for a patched version to be released, because the next important milestone after that would be finished backports to older versions still in use, which is clearly going to take a long time as it is not being prioritized, so I wanted to inform users. Initially I had said 90 days from the initial report, but it seemed like they were expanding the work to fill that time. I asked a number of times for them to make a security advisory and got no answer. Some discussions on the repo showed they were considering this as a theoretical issue. Now it's CVE-2024-51774, which got assigned within 48 hours of disclosing.
- perching_aix 2y ago
  > Some discussions on the repo showed they were considering this as a theoretical issue. That's hilarious. It's all theoretical until it's getting exploited in the wild...
  - hsbauauvhabzb 2y ago
    Any proof that actually happened or you just wearing a tin foil hat? Crypto enforcement en masse matter, intercepting highly specific targets using BitTorrent does not.
    - tga_d 2y ago
      I feel as though there is a generational gap developing between people who do and do not remember how prolific Firesheep used to be.
    - perching_aix 2y ago
      I think a better question is: why are you looking for evidence (not proof!) on me for something you are supposing?
    - Jerrrrrrry 2y ago
      Lol wait til you get personally targeted by a 0'day in extremely popular software for that sentiment to make you look stupid both ways.

kgeist 2y ago

Temporary solutions can become more dangerous with time. Years ago, in one of our projects, someone wrote a small helper class, HTTPClient, to talk to one of our internal subsystems. The subsystem in the dev environment used self-signed certificates, so one of the devs just disabled SSL validation. Whether SSL errors were ignored or not was specified in a config. Later, someone messed up while editing the configs, and SSL validation got disabled in the live environment, too. No one noticed, because nobody writes tests to check if SSL validation is enabled. But that's only part of the story, this HTTPClient class was still only used to communicate with our internal subsystem on our own network. The real problem came later when the next generation of developers saw this HTTPClient class and thought, "Hey, what a nifty little helper!", and soon they were using it to talk to pretty much everything, including financial systems. I was shocked when I discovered it. An inconsequential temporary workaround had turned into a huge security hole.

xelamonster 2y ago

This is interesting, I haven't ever used the Qt framework but I'm surprised that it would even have an SSL implementation, sounds a bit out of scope for a GUI toolkit. I think I'd prefer to do all my networking separately and provide the fetched data to Qt. Edit (just noticed this was the author): I'm curious what torrent client do you prefer? I like Deluge but mostly go to it because it's familiar.

ripdog 2y ago
Qt isn't just a GUI toolkit - it's an everything toolkit. It's somewhat intended to be used (potentially) alone with C++ to allow the creation of a wide variety of apps. It includes modules like Bluetooth, Network, Multimedia, OAuth, Threading and XML. See a full list: https://doc.qt.io/qt-6/index.html https://doc.qt.io/qt-6/index.html
- pjmlp 2y ago
  In the spirit of the C++ compiler frameworks that were quite common during the 1990's before C++98, and then we got quite a thin standard library instead, and a mess of how to manage third parties that is still being sorted out.

deleted 2y ago

[deleted]

immibis 2y ago
[dead]

tagyro 2y ago

(most?) programming languages have a way to handle these scenarios, something like `#warning | TODO | FIXME` ... I understand temporary, but 14 years seems a bit ...too long