3 ms·

Was the code in question included in stable releases? If not, I might agree that assigning CVEs are not helpful. But if the code was included in one or more s

Was the code in question included in stable releases? If not, I might agree that assigning CVEs are not helpful. But if the code was included in one or more stable release then I think it should probably have CVEs assigned. Depending on how serious or real the problems were.

ktosobcy 3y ago
AFAIR it was im stable release BUTin a test code thats's behind a flag (disabled by default) so... it's a bit "shrodinger"
px43 3y ago
I have personally reported bugs in the past that got closed as WONTFIX because they required some obscure configuration that the developer didn't believe would exist in the real world, but the way I found them was by breaking into actual real world servers owned by a client that I couldn't talk about due to an NDA. This happens a lot, and getting blown off constantly is a big reason why a lot of researchers just don't report bugs they find. I don't know much about these nginx bugs, but it seems like they were found in real live production systems, not by researchers trying to bump their CVE credits. Also it seems like quite a few people in the world are using nginx for HTTP/3 and quic, so trying to say "it doesn't count because it's not on by default" seems like a bit of a stretch. https://trac.nginx.org/nginx/ticket/2585 https://trac.nginx.org/nginx/ticket/2585 https://trac.nginx.org/nginx/ticket/2586 https://trac.nginx.org/nginx/ticket/2586
- kuschku 3y ago
  These bugs only occurred if you compiled nginx yourself with custom flags during build. Should you be able to file CVEs against code posted in GitHub comments? StackOverflow Answers? Experimental branches on a maintainer's personal fork of the project?
  - jeltz 3y ago
    No, but code behind compile flags in a stable release seems like something we should file CVEs against.
  - dns_snek 3y ago
    The vulnerability also affected official version of Nginx Plus R30, released in August last year[1] and its release notes strongly suggest that the feature is no longer experimental. The steps required to use HTTP/3 in the open source version are also outlined in the official documentation, and you can find numerous guides for using Nginx with HTTP/3, demonstrating that the feature has reached some level of public adoption. This is in no way comparable to random snippets of code you find online, or in some experimental branch of a code repository that's not intended for public consumption. Filing a CVE for software that early adopters are likely to be using in production is completely justified, I'd certainly want to know about it. [1] https://www.nginx.com/blog/nginx-plus-r30-released/ https://www.nginx.com/blog/nginx-plus-r30-released/ > Native support for QUIC+HTTP/3 – NGINX Plus now has official support for HTTP/3. [...] > The QUIC+HTTP/3 support in NGINX Plus R30 is available as a single binary – unlike the experimental HTTP/3 support introduced in NGINX Plus R29, which had a separate binary for nginx quic. [...] > Full HTTP/3 support is added. NGINX 1.25.0 mainline version introduced support for HTTP/3, and this support has been merged into NGINX Plus R30. The NGINX Plus R30 implementation has the following changes when compared to the experimental packages delivered in NGINX Plus R29 [...]
    - kuschku 3y ago
      And this is the cause of the conflict. Nginx, the open source project, was safe. No CVE should be assigned to it. NGINX PLUS, a separate and independent corporate product, was vulnerable. A CVE should be assigned specifically to it. The issue is that the maintainers of the open source nginx project were paid by the company behind NGINX PLUS, and the company demanded the CVE be assigned to the open source part.
      - dns_snek 3y ago
        Nginx, the open source project, wasn't "safe". It was merged, released, came with documentation, and it had public use. I think that's all that matters. How else do you propose that users are informed about vulnerabilities in their installation? That's what CVEs are for.
        3y ago
- juped 3y ago
  There is no valid reason for "won't fix" to be a bug status, even if you aren't going to fix the bug. There's a status for that: "open".
  - codetrotter 3y ago
    Open is for tickets that are intended to be fixed. Having nine gazillion open tickets is helpful for no one. Devs will have to wade through open tickets that are not meant to be worked on time over again. Tickets that should be worked on will be lost in the sea of irrelevant tickets. People affected by the issue will see the open ticket and think it means that it’s going to be fixed.
    - juped 3y ago
      Yes, we've all had or heard horror stories of managers like you who flip out over open and closed ticket metrics. That doesn't make it good practice.
  - HankB99 3y ago
    That ("open") seems reasonable for a bug in the current release or a previous release that is still in wide use. Is there ever a situation where a bug exists so far back in the history of the project that it doesn't make sense to fix? I'm asking this as an honest question and not a challenge. I can expect that some users still use what I'd consider to be legacy S/W but I wonder how far that goes back. If the developer(s) designate a version as EOL does it make sense to keep the bug open? And OTOH, it conveys information if the developer marks a bug as "won't fix" rather than leaving the expectation that it might be addressed, someday.
    - juped 3y ago
      If the bug only exists in old versions that sounds like a great case for marking it "fixed"! (Or possibly a cousin like "moot because this subsystem was deleted".)
jasode 3y ago
>Was the code in question included in stable releases? If not, I might agree that assigning CVEs are not helpful. F5 employee says code the was marked as "experimental" but the issue is that customers were running it in production: https://news.ycombinator.com/item?id=39378523 https://news.ycombinator.com/item?id=39378523 https://news.ycombinator.com/item?id=39379984 https://news.ycombinator.com/item?id=39379984 It's worth going through that entire thread and Ctrl+F search userid "MZMegaZone" to get F5's rationale for assigning a CVE. Why are some customers running experimental code in production?!? I can only assume they do it to solve a problem and take early advantage of a new feature that doesn't exist in the stable release.
- kuschku 3y ago
  Apparently F5 shipped it in production in their proprietary version, while it was not compiled into the free version. So technically the CVE should be filed against NGINX Plus, not nginx ;)
jeltz 3y ago
It was included in stable releases but behind a compile time feature flag. Personally I think it was a very weird hill to die on. Weird to take CVEs so personally.

ktosobcy 3y ago

AFAIR it was im stable release BUTin a test code thats's behind a flag (disabled by default) so... it's a bit "shrodinger"

px43 3y ago

I have personally reported bugs in the past that got closed as WONTFIX because they required some obscure configuration that the developer didn't believe would exist in the real world, but the way I found them was by breaking into actual real world servers owned by a client that I couldn't talk about due to an NDA. This happens a lot, and getting blown off constantly is a big reason why a lot of researchers just don't report bugs they find. I don't know much about these nginx bugs, but it seems like they were found in real live production systems, not by researchers trying to bump their CVE credits. Also it seems like quite a few people in the world are using nginx for HTTP/3 and quic, so trying to say "it doesn't count because it's not on by default" seems like a bit of a stretch. https://trac.nginx.org/nginx/ticket/2585 https://trac.nginx.org/nginx/ticket/2585 https://trac.nginx.org/nginx/ticket/2586 https://trac.nginx.org/nginx/ticket/2586

kuschku 3y ago
These bugs only occurred if you compiled nginx yourself with custom flags during build. Should you be able to file CVEs against code posted in GitHub comments? StackOverflow Answers? Experimental branches on a maintainer's personal fork of the project?
- jeltz 3y ago
  No, but code behind compile flags in a stable release seems like something we should file CVEs against.
- dns_snek 3y ago
  The vulnerability also affected official version of Nginx Plus R30, released in August last year[1] and its release notes strongly suggest that the feature is no longer experimental. The steps required to use HTTP/3 in the open source version are also outlined in the official documentation, and you can find numerous guides for using Nginx with HTTP/3, demonstrating that the feature has reached some level of public adoption. This is in no way comparable to random snippets of code you find online, or in some experimental branch of a code repository that's not intended for public consumption. Filing a CVE for software that early adopters are likely to be using in production is completely justified, I'd certainly want to know about it. [1] https://www.nginx.com/blog/nginx-plus-r30-released/ https://www.nginx.com/blog/nginx-plus-r30-released/ > Native support for QUIC+HTTP/3 – NGINX Plus now has official support for HTTP/3. [...] > The QUIC+HTTP/3 support in NGINX Plus R30 is available as a single binary – unlike the experimental HTTP/3 support introduced in NGINX Plus R29, which had a separate binary for nginx quic. [...] > Full HTTP/3 support is added. NGINX 1.25.0 mainline version introduced support for HTTP/3, and this support has been merged into NGINX Plus R30. The NGINX Plus R30 implementation has the following changes when compared to the experimental packages delivered in NGINX Plus R29 [...]
  - kuschku 3y ago
    And this is the cause of the conflict. Nginx, the open source project, was safe. No CVE should be assigned to it. NGINX PLUS, a separate and independent corporate product, was vulnerable. A CVE should be assigned specifically to it. The issue is that the maintainers of the open source nginx project were paid by the company behind NGINX PLUS, and the company demanded the CVE be assigned to the open source part.
    - dns_snek 3y ago
      Nginx, the open source project, wasn't "safe". It was merged, released, came with documentation, and it had public use. I think that's all that matters. How else do you propose that users are informed about vulnerabilities in their installation? That's what CVEs are for.
      - 3y ago
juped 3y ago
There is no valid reason for "won't fix" to be a bug status, even if you aren't going to fix the bug. There's a status for that: "open".
- codetrotter 3y ago
  Open is for tickets that are intended to be fixed. Having nine gazillion open tickets is helpful for no one. Devs will have to wade through open tickets that are not meant to be worked on time over again. Tickets that should be worked on will be lost in the sea of irrelevant tickets. People affected by the issue will see the open ticket and think it means that it’s going to be fixed.
  - juped 3y ago
    Yes, we've all had or heard horror stories of managers like you who flip out over open and closed ticket metrics. That doesn't make it good practice.
- HankB99 3y ago
  That ("open") seems reasonable for a bug in the current release or a previous release that is still in wide use. Is there ever a situation where a bug exists so far back in the history of the project that it doesn't make sense to fix? I'm asking this as an honest question and not a challenge. I can expect that some users still use what I'd consider to be legacy S/W but I wonder how far that goes back. If the developer(s) designate a version as EOL does it make sense to keep the bug open? And OTOH, it conveys information if the developer marks a bug as "won't fix" rather than leaving the expectation that it might be addressed, someday.
  - juped 3y ago
    If the bug only exists in old versions that sounds like a great case for marking it "fixed"! (Or possibly a cousin like "moot because this subsystem was deleted".)

jasode 3y ago

>Was the code in question included in stable releases? If not, I might agree that assigning CVEs are not helpful. F5 employee says code the was marked as "experimental" but the issue is that customers were running it in production: https://news.ycombinator.com/item?id=39378523 https://news.ycombinator.com/item?id=39378523 https://news.ycombinator.com/item?id=39379984 https://news.ycombinator.com/item?id=39379984 It's worth going through that entire thread and Ctrl+F search userid "MZMegaZone" to get F5's rationale for assigning a CVE. Why are some customers running experimental code in production?!? I can only assume they do it to solve a problem and take early advantage of a new feature that doesn't exist in the stable release.

kuschku 3y ago
Apparently F5 shipped it in production in their proprietary version, while it was not compiled into the free version. So technically the CVE should be filed against NGINX Plus, not nginx ;)

jeltz 3y ago

It was included in stable releases but behind a compile time feature flag. Personally I think it was a very weird hill to die on. Weird to take CVEs so personally.