7 ms·

We (F5) published two CVEs today against NGINX+ & NGINX OSS. Maxim was against us assigning CVEs to these issues. F5 is a CNA and follows CVE program rules an

We (F5) published two CVEs today against NGINX+ & NGINX OSS. Maxim was against us assigning CVEs to these issues. F5 is a CNA and follows CVE program rules and guidelines, and we will err on the side of security and caution. We felt there was a risk to customers/users and it warranted a CVE, he did not.

tky 3y ago
This seems like a much larger story than the fork, given the install base of nginx. For clarity are you referring to CVE-2024-24989 and -24990 (HTTP/3)?
- MZMegaZone 3y ago
  Yes, those are the two CVEs I was referring to. All I know is he objected to our decision to assign CVEs, was not happy that we did, and the timing does not appear coincidental.
  - mike_d 3y ago
    QUIC in Nginx is experimental and not enabled by default. I tend to agree with him here that a WIP codebase will have bugs that might have security implications, but they aren't CVE worthy.
    - MZMegaZone 3y ago
      We know a number of customers/users have the code in production, experimental or not. And that was part of decision process. The security advisories we published do state the feature is experimental. When in doubt, err on the side of doing the right thing for the users. I find that's the best approach. I don't consider CVE a bad thing - it shouldn't be treated like a scarlet letter to be avoided. It is a unique identifier that makes it easy to talk about a specific issue and get the word out to customers/users so they can protect themselves. And that's a good thing. The question I ask is "Why not assign a CVE?" You have to have a solid reason why not to do it, because of default is to assign and disclose. I don't think having the CVEs should reflect poorly on NGINX or Maxim. I'm sorry he feels the way he does, but I hold no ill will toward him and wish him success, seriously.
      - braiamp 3y ago
        What does policy says about reporting security issues with experimental/not-enabled-by-default/unstable code?
        arter4 3y ago
        As an outsider to this whole thing (having discovered this issue in this thread, like pretty much anyone), the CVE rules simply say that you cannot assign a CVE to vulnerabilities in a product that is not publicly available or licensable. Experimental, but publicly available features are still in scope. This makes sense IMHO: experimental features may be buggy, but they may work in your limited use case. So you may be inclined to use them...except you don't know they expose you in a critical way.
        MZMegaZone 3y ago
        Exactly - this very question came up. And pretty much everyone looked at me as I'm the one who sits on every CVE.org working group (BTW, the CVE rules are currently being revised and in comment period for said revision) and I explained exactly that - just because it is experimental doesn't mean it is out of scope. Also, something that keeps getting lost here, the CVE is NOT just against NGINX OSS, but also NGINX+, the commercial product. And the packaging, release, and messaging on that is a bit different. That had to be part of the decision process too. Since it is the same code the CVE applies to both. This was not a rash decision or one made without a lot of discussion and consideration of multiple factors. But one of our guiding principles that we literally ask ourselves during these things is "What is the right thing to do?" Meaning, what is the right thing for the users, first and foremost. That's part of the job, IMHO. Some vendors never disclose anything, but that's not how we operate. I've written a few articles on F5's DevCentral site about this - "Why We CVE" and "CVE: Who, What, Where, and When" are particularly on topic for this, I think.
        GoblinSlayer 3y ago
        All features have limited use case, but experimental features may be buggy in all use cases, which is exactly what happened here. CVE is uninformative there, defects are implied, might as well create a CVE for every commit "something happened, don't forget to repedloy".
- ryukoposting 3y ago
  This is confusing. The CVE doesn't describe the attack vector with any meaningful degree of clarity, except to emphasize how you'd have to have a known unstable and non-default component enabled. As far as CVEs go, it definitely lacks substance, but it's not some catastrophic violation of best practices. It hardly reflects poorly on Maxim or anything he's done for Nginx. This seems like an extreme move, and it makes me wonder if there's something we're missing.
  - PH95VuimJjqBqy 3y ago
    it's most likely the last straw rather than the sole reason.
    - arter4 3y ago
      Maybe, but he only mentioned disagreements on security policies. Doesn't sound very convincing as a last straw, especially from a marketing standpoint when trying to gain more traction for his fork.
nmjohn 3y ago
Why did he not want CVE's assigned?
- MZMegaZone 3y ago
  I think you'd have to ask Maxim. My take is he felt experimental features should not get CVEs, which isn't how the program works. But that's just my take - I'm the primary representative for F5 to the CVE program and on the F5 SIRT, we handle our vuln disclosures.
  - Twirrim 3y ago
    I'm inclined to agree with your decision to create and publish CVEs for these, honestly. You were shipping code with a now-known vulnerability in it, even if it wasn't compiled in by default.
    - aaronbwebber 3y ago
      if it's not compiled in by default, then you aren't shipping the code! Somebody is downloading it and compiling it themselves!
      - kelnos 3y ago
        If the feature is in the code that's downloaded, regardless of whether or not the build process enables it by default, the code is definitely being shipped.
        ramses0 3y ago
        BRB, filing CVE's against literally any project with example code in their documentation...
        spicykraken 3y ago
        I've actually seen CVEs like that before, I agree that's bonkers but I have seen it...
bogota 3y ago
[flagged]
- tommica 3y ago
  Could you expand on your reasoning here? I'm genuinely curious what makes you react in this way? To me it seems like a very simple disagreement with policies, and because the implications of the decision that was made and the impact it has to the agreed relationships.
- oefrha 3y ago
  If you have more information, share it (I don’t think you do, as all you could say was “I’m sure”.). People actually involved sharing their side is a unique advantage of HN. Empty ad hominem attacks are not allowed here, and you have no right to tell anyone to “get out of here”.
detectivecastle 3y ago
I worked there before and after the acquisition. F5 Security was woefully incompetent. We spent 3 months trying to get approval for a web hook from Gitlab -> Slack, including endless documents (Threat Model Assessment), and meetings - god, the meetings - at one point on a call with 35 people. So I feel Maxim’s pain trying to deal with that team at F5. On the other hand nginx core developers (the Russians) were arrogant to the point of considering anyone else as inferior and unworthy of their attention or respect, unless they contributed to nginx oss. They managed that project secretively and rewrote most “outside” contributions. They also ignored security issues - one internal developer spotted security issues with NGINX Unit (a failed oss project 20 years out of date before it started) and was told to fix the issues quietly and not to mention “security” anywhere in the issue messages or commit history. So I can imagine exactly how these meetings would have gone, I’m sure it was the last straw!
- starlord__ 3y ago
  I can agree to this. I worked there too, and it took 2 months to get a simple approval for a similar project, despite preparing extensive TMA documents, etc

tky 3y ago

This seems like a much larger story than the fork, given the install base of nginx. For clarity are you referring to CVE-2024-24989 and -24990 (HTTP/3)?

MZMegaZone 3y ago
Yes, those are the two CVEs I was referring to. All I know is he objected to our decision to assign CVEs, was not happy that we did, and the timing does not appear coincidental.
- mike_d 3y ago
  QUIC in Nginx is experimental and not enabled by default. I tend to agree with him here that a WIP codebase will have bugs that might have security implications, but they aren't CVE worthy.
  - MZMegaZone 3y ago
    We know a number of customers/users have the code in production, experimental or not. And that was part of decision process. The security advisories we published do state the feature is experimental. When in doubt, err on the side of doing the right thing for the users. I find that's the best approach. I don't consider CVE a bad thing - it shouldn't be treated like a scarlet letter to be avoided. It is a unique identifier that makes it easy to talk about a specific issue and get the word out to customers/users so they can protect themselves. And that's a good thing. The question I ask is "Why not assign a CVE?" You have to have a solid reason why not to do it, because of default is to assign and disclose. I don't think having the CVEs should reflect poorly on NGINX or Maxim. I'm sorry he feels the way he does, but I hold no ill will toward him and wish him success, seriously.
    - braiamp 3y ago
      What does policy says about reporting security issues with experimental/not-enabled-by-default/unstable code?
      - arter4 3y ago
        As an outsider to this whole thing (having discovered this issue in this thread, like pretty much anyone), the CVE rules simply say that you cannot assign a CVE to vulnerabilities in a product that is not publicly available or licensable. Experimental, but publicly available features are still in scope. This makes sense IMHO: experimental features may be buggy, but they may work in your limited use case. So you may be inclined to use them...except you don't know they expose you in a critical way.
        MZMegaZone 3y ago
        Exactly - this very question came up. And pretty much everyone looked at me as I'm the one who sits on every CVE.org working group (BTW, the CVE rules are currently being revised and in comment period for said revision) and I explained exactly that - just because it is experimental doesn't mean it is out of scope. Also, something that keeps getting lost here, the CVE is NOT just against NGINX OSS, but also NGINX+, the commercial product. And the packaging, release, and messaging on that is a bit different. That had to be part of the decision process too. Since it is the same code the CVE applies to both. This was not a rash decision or one made without a lot of discussion and consideration of multiple factors. But one of our guiding principles that we literally ask ourselves during these things is "What is the right thing to do?" Meaning, what is the right thing for the users, first and foremost. That's part of the job, IMHO. Some vendors never disclose anything, but that's not how we operate. I've written a few articles on F5's DevCentral site about this - "Why We CVE" and "CVE: Who, What, Where, and When" are particularly on topic for this, I think.
        GoblinSlayer 3y ago
        All features have limited use case, but experimental features may be buggy in all use cases, which is exactly what happened here. CVE is uninformative there, defects are implied, might as well create a CVE for every commit "something happened, don't forget to repedloy".
ryukoposting 3y ago
This is confusing. The CVE doesn't describe the attack vector with any meaningful degree of clarity, except to emphasize how you'd have to have a known unstable and non-default component enabled. As far as CVEs go, it definitely lacks substance, but it's not some catastrophic violation of best practices. It hardly reflects poorly on Maxim or anything he's done for Nginx. This seems like an extreme move, and it makes me wonder if there's something we're missing.
- PH95VuimJjqBqy 3y ago
  it's most likely the last straw rather than the sole reason.
  - arter4 3y ago
    Maybe, but he only mentioned disagreements on security policies. Doesn't sound very convincing as a last straw, especially from a marketing standpoint when trying to gain more traction for his fork.

nmjohn 3y ago

Why did he not want CVE's assigned?

MZMegaZone 3y ago
I think you'd have to ask Maxim. My take is he felt experimental features should not get CVEs, which isn't how the program works. But that's just my take - I'm the primary representative for F5 to the CVE program and on the F5 SIRT, we handle our vuln disclosures.
- Twirrim 3y ago
  I'm inclined to agree with your decision to create and publish CVEs for these, honestly. You were shipping code with a now-known vulnerability in it, even if it wasn't compiled in by default.
  - aaronbwebber 3y ago
    if it's not compiled in by default, then you aren't shipping the code! Somebody is downloading it and compiling it themselves!
    - kelnos 3y ago
      If the feature is in the code that's downloaded, regardless of whether or not the build process enables it by default, the code is definitely being shipped.
      - ramses0 3y ago
        BRB, filing CVE's against literally any project with example code in their documentation...
        spicykraken 3y ago
        I've actually seen CVEs like that before, I agree that's bonkers but I have seen it...

bogota 3y ago

[flagged]

tommica 3y ago
Could you expand on your reasoning here? I'm genuinely curious what makes you react in this way? To me it seems like a very simple disagreement with policies, and because the implications of the decision that was made and the impact it has to the agreed relationships.
oefrha 3y ago
If you have more information, share it (I don’t think you do, as all you could say was “I’m sure”.). People actually involved sharing their side is a unique advantage of HN. Empty ad hominem attacks are not allowed here, and you have no right to tell anyone to “get out of here”.

detectivecastle 3y ago

I worked there before and after the acquisition. F5 Security was woefully incompetent. We spent 3 months trying to get approval for a web hook from Gitlab -> Slack, including endless documents (Threat Model Assessment), and meetings - god, the meetings - at one point on a call with 35 people. So I feel Maxim’s pain trying to deal with that team at F5. On the other hand nginx core developers (the Russians) were arrogant to the point of considering anyone else as inferior and unworthy of their attention or respect, unless they contributed to nginx oss. They managed that project secretively and rewrote most “outside” contributions. They also ignored security issues - one internal developer spotted security issues with NGINX Unit (a failed oss project 20 years out of date before it started) and was told to fix the issues quietly and not to mention “security” anywhere in the issue messages or commit history. So I can imagine exactly how these meetings would have gone, I’m sure it was the last straw!

starlord__ 3y ago
I can agree to this. I worked there too, and it took 2 months to get a simple approval for a similar project, despite preparing extensive TMA documents, etc