We got around 150 submissions for 30ish panel slots over three days, so we're good there. Schedule should be out soon.
The CVE program has grown and changed a lot the past few years, and the rules are undergoing a major revision right now (comment period currently) taking in a lot of the feedback. And the rate of CNAs joining has been picking up rapidly as global interest in the program has increased.
No one thinks it is perfect, but that's why a lot of us are active in the working groups and trying to keep moving things forward.
License and passport have no first name and MegaZone for a last name.
My SSN Card has 'Mr MegaZone' - when I changed it, back in 2000, the SSA said their computers just could not handle a blank first name. They wanted to put in something like NFN MegaZone, FNU MegaZone, etc. (No First Name, First Name Unknown) I suggested 'Mr' because it tickled me to make the government call me Mister MegaZone. ;-)
Airline tickets are something where I use Mr MegaZone. I have Global Entry/PreCheck, and even though my IDs have no first name, the ticketing systems do NOT like that. So my PreCheck stuff is under Mr MegaZone. I made the mistake if booking once under MZ MegaZone, and even though all my PreCheck info was on there, it didn't work and I got stuck in the normal security line. Lesson learned.
My passport does break other systems sometimes - I go on cruises with my wife and they, of course, base things on your passport. So I usually end up as FNU MegaZone, which leads to hilarity as crew members try to pronounce 'FNU' as a name. Usually once I'm onboard I can get into the system and edit things, but such is life.
Long answer: Most DBs key on lastname, so MegaZone is my last name, officially, and I have no first name. Then I leave the first name blank if it'll let me, but more often I need to put something in there - so these days I use 'MZ' as that's what I have people call me. I used to use 'Mr', and I still need to use that on some government forms so everything will match up.
OK - I need to make very clear that I'm speaking for myself and NOT F5, OK? OK.
Ask yourself why this matters? What is the big deal about having a CVE assigned? A CVE is just a unique identifier for a vulnerability so that everyone can refer to the same thing. It helps get word out to users who might be impacted, and we know there are sites using this feature in production - experimental or not. This wasn't dictating what could or could not go into the code - my understanding was the vuln wasn't even in his code, but from another contributor. So, honestly, how does issuing the CVEs impact his work, at all?
That's what I, personally, don't understand. At a functional level, this really has no impact on his work or him personally. This is just documentation of an existing issue and a fix which had to be made, and was being made, CVE or no CVE. And this is worth a fork?
What you're suggesting is the best thing to do is to allow one developer to dictate what should or should not be disclosed to the user base, based on their personal feelings and not an analysis of the impact of that vulnerability on said user base? And if they're inflexible in their view and no compromise can be reached then that's OK?
Sometimes there's just no good compromise to be reached and you end up with one person on one side, and a lot of other people on the other, and if that one person just refuses to budge then it is what it is. Rational people can agree to disagree. In my career there have been many times when I have disagreed with a decision, and I could either make peace with it or I could polish my resume. To me it seems a drastic step to take over something as frankly innocuous as assigning a CVE to an acknowledged vulnerability. Clearly he felt differently, and strongly, on the matter. Maybe he is just very strongly anti-CVE in general, or maybe he'd been feeling the itch to control his own destiny and this was just the spur it took to make the move.
His reasons are his own, and maybe he'll share more in time. I'm comfortable with my personal stance in the matter and the recommendations I made; they conform with my personal and professional morals and ethics. I'm sorry it came to this, but I would not change my recommendation in hindsight as I still feel we did the right thing.
Only time will tell what the results of that are. I think the world is big enough that it doesn't have to be a zero sum game.
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.
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. ;-)
Those were great times. I learned a hell of a lot working at Livingston, because we had to. We were basically a startup selling to ISPs right as the Internet exploded and we grew like crazy. Suddenly we're doing ISDN BRI/PRI, OSPF, BGP, PCM modems, releasing chassis products (PM-4)... Real fun times, always something new happening. I even ended up our corporate webmaster since I'd been playing with web tech for a few years and thought it'd be a good idea if we had a site. Quite a way to jumpstart a career.
You're all also missing the fact that the vuln is also in the NGINX+ commercial product, not just OSS. Which has a different release model.
Being the same code it'd be darn strange to have the CVE for one and not the other. We did ask ourselves that question and quickly concluded it made no sense.
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.
Internally at F5 (where I work as a Principal Security Engineer in the F5 SIRT and was one of the people responsible for making the call on assigning the CVEs).
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.
Yeah, I've been with F5 since 2010 - gotta love those old PortMasters though, Livingston was good times, until Lucent took over. I was there 95-98.
I don't know what else there is to say really. The QUIC/HTTP/3 vuln was found in NGINX OSS, which is also the basis for the commercial NGINX+ product. We looked at the issue and decided that, by our disclosure policies, we needed to assign a CVE and make a disclosure. And I was firmly in that camp - my personal motto is "Our customers cannot make informed decisions about their networks if we do not inform them." I fight for the users.
Anyway, Maxim did not seem to agree with that position. There wasn't much debate about it - the policy was pretty clear and we said we're issuing a CVE. And this is the result as near I can tell.
Honestly, anyone could have gone to a CNA and demanded a CVE and he would not have been able to stop it. That's how it works.
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.
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.
The CVE program has grown and changed a lot the past few years, and the rules are undergoing a major revision right now (comment period currently) taking in a lot of the feedback. And the rate of CNAs joining has been picking up rapidly as global interest in the program has increased.
No one thinks it is perfect, but that's why a lot of us are active in the working groups and trying to keep moving things forward.