• Tartas1995@discuss.tchncs.de
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    9 months ago

    Have you looked into the CVE? Apparently it is a non issue. You could use it to dos a service that have an experimental feature enabled, which is disabled by default, on a non stable Version. I understand the dev. CVE should be for serious issues. And they alerted their users over an email list

    It can be used for dos, as it is crashing workers, but they will be restarted anyway.

    • ysjet@lemmy.world
      link
      fedilink
      English
      arrow-up
      0
      ·
      edit-2
      9 months ago

      There is an astounding number of lies in your post, good lord.

      1. It is an issue. A DoS is a fairly serious vulnerability, and very much is a vulnerability.
      2. Experimental features are explicitly defined to require their vulnerabilities to be assigned CVEs.
      3. It is not just available on the stable version, but both commercially and via the open source version.
      4. CVEs are not just for serious issues, they are for vulnerabilities. All vulnerabilities. It is a number that allows you to reference an vulnerability, nothing more, nothing less.
      5. Mentioning a CVE on the mailing list is the absolute least they should be doing.
      6. ‘workers can just be restarted anyway’ shows a deep misunderstanding of what a worker does. Any pending or active transactions that worker had now hangs, meaning that the service is still being denied. Trying to recover automatically from a DoS does not mean the DoS is not happening- it just means that the DoS is slower to get rolling, or intermittently seems to work mid-DoS.
      • Tartas1995@discuss.tchncs.de
        link
        fedilink
        arrow-up
        0
        arrow-down
        1
        ·
        edit-2
        9 months ago

        There is an astounding number of lies/misrepresentations in your post, good lord.

        1. I never said it isn’t an issue. Dos is the issue. It is a vulnerability.
        2. No. CVE are not required. Like never. There is no legal requirements. The c in CVE stands for common btw… You know what is not common, Experimental features on non stable releases.
        3. The stables are not affected. To quote from https://www.nginx.com/blog/updating-nginx-for-the-vulnerabilities-in-the-http-3-module/ about cve-2024-24989, “NGINX Open source mainline version 1.25.4. (The latest NGINX Open source stable version 1.24.0 is not affected.)” And about CVE-2024-24990, “NGINX Open source mainline version 1.25.4. (The latest NGINX Open source stable version 1.24.0 is not affected.)”
        4. Yes and no. Remember the c in cve?
        5. How is it a lie to say that they informed people through a mail list, when they did that? Remember you said I was lying? Also didn’t you say they wanted to keep it quiet to fix in secret, while they inform the public? Isn’t that a lie? (Also, you call it a cve in this point, well the dev didn’t think of it as one and he alerted the users. So they satisfied your “least” requirement for a cve while not thinking of it as a cve.)
        6. My statement is once again not a lie. But let’s talk about your stuck transaction. Your transaction isn’t “stuck” if you use transactions in your database, but besides that you used an experimental feature on a non stable release on a publicly facing service and the “stuck” transaction is your issue? You are fucking without a condom, my friend. And That experimental feature might just crash randomly, due to memory leaks or what not, and your transaction is stuck too.

        Where were my lies? I mean I showed you yours.