[MZMegaZone]

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.

[detectivecastle]

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__]

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]

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)?

[ryukoposting]

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]

it's most likely the last straw rather than the sole reason.

[arter4]

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.

[MZMegaZone]

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]

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]

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.

[gwd]

FWIW, in my project the main reason we don't issue security advisories for "unsupported" code ("experimenal" or "tech preview") is to reduce the burden for our downstreams: many of our immediate downstreams are expected by their users to apply every single security patch, regardless of whether they even use the affected functionality. For cloud providers doing this across a massive fleet, this is a fair amount of work that's worth avoiding if we can.

On the other hand, since the definition of "supported" is specifically designed to help downstreams, if it were known that some bit of code was widely used in production, we'd be open to declaring it "security supported", regardless of whether we thought it was "finished" or not.

[gav]

Recently I had to support a client who had a "no CVEs in a production deploy, ever" policy.

The stack included Linux, Java, Chromium, and MySQL. It took multiple person-years of playing whack-a-mole with dependencies to get it into production because we'd have to have conversations like:

  Client: there's a CVE in the this module 
  Us: that's not exploitable because it's behind a configuration option that we haven't enabled
  Client: somebody could turn it on
  Us: even if they somehow did and nobody noticed, they would have to stand up a server inside your VPC and connect to that
  Client: well what if they did that?
  Us: then they'd already have root and you are hosed 
  Client: but the CVE
  Us: 

So I definitely appreciate any vendor that tries to minimize CVEs.

[arp242]

> The question I ask is "Why not assign a CVE?"

There's tons of reasons why you wouldn't, but the core reason for this fork probably isn't really about the CVEs as such. It's either the final straw in a long line of disagreements, or the entire thing was handled was so badly that he no longer wants to work with these people. Or most likely: a combination of both.

I once quit after a small disagreement because the owner cut off my explanation on why I built something the way I did with "I don't care, just do what I say". This was after he ignored the discussion on how to design it, and ignored requests for feedback when I was building it. And look, I don't mind to re-doing it even if I don't agree it's better better, but I did put quite a lot of thought and effort in to it and thought it worked very well. If you don't even want to spend 3 minutes listening to the reasons on why it's like that then kindly go fuck yourself.

It's not the disagreement as such that matters, it's the lack of basic respect.

[braiamp]

What does policy says about reporting security issues with experimental/not-enabled-by-default/unstable code?

[arter4]

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.

[JackSlateur]

  The question I ask is "Why not assign a CVE?"

Exactly: why not ? Glory to the Linux Kernel which is on its way to assign CVE for everything :)

[MZMegaZone]

That's a whole different discussion - which isn't as dramatic as it is being made out to be.

Other hats I wear (outside of my day job) include being on every (literally, every) CVE.org Working Group and being the newly elected CNA Liaison to the CVE Board. This has been a subject of discussion and things are a bit overblown right now, IMHO. Some of the initial communications were perhaps not as clear as they could have been. But it isn't going to be every kernel bug being a CVE - not every bug is a vuln.

I'm also one of the co-chairs for the upcoming VulnCon in Raleigh, NC. Just a plug. ;-)

[Reelix]

EVERYTHING.

Found a missing comma in the documentation of a function? Yup - That's a CVE ;p

[nmjohn]

Why did he not want CVE's assigned?

[MZMegaZone]

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]

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]

if it's not compiled in by default, then you aren't shipping the code! Somebody is downloading it and compiling it themselves!

[anon-sre-srm]

Incorrect. Features available to users still require a minimum, standard level of support. This is like the deceptive misnomer of staging and test environments provided to internal users used no differently than production in all but name.

[GoblinSlayer]

Nobody does it like that though, what vendor declares unsupported is unsupported.

[mort96]

That .. is the definition of shipping the code, the code is being shipped to the people downloading and compiling it for themselves

[kelnos]

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]

BRB, filing CVE's against literally any project with example code in their documentation...

[anon-sre-srm]

Yes. It's no different from any optional feature. Actual beta features should only be shipped in beta software .

[Twirrim]

You and I have very different notions of "shipped". It's open source code, it's being made publicly available. That's shipped, as I see it.

[aaronbwebber]

This is an insane standard and attempting to adhere to it would mean that the CVE database, which is already mostly full of useless, irrelevant garbage, is now just the bug tracker for _every single open source project in the world_.

[droopyEyelids]

(not explicitly asking you, MZMegaZone) Does anyone understand why a disagreement about this would be worth the extra work in forking the project?

I'm not very familiar with the implications, so it seems like a relatively fine hair to split- as though the trouble of dealing with these as CSV would be less than the extra work of forking.

[kelnos]

It probably wasn't. There's likely something else going on. Either Dounin had already decided to fork for other reasons, and the timing was coincidental, or there were a lot of reasons building up, and this was the final straw.

Or he's just a very strange man, and for some reason this pair of CVEs was oddly that important to him.