8 ms·
Yep. Maxim did not want CVEs assigned.
by MZMegaZone 3y ago
Yep. Maxim did not want CVEs assigned.
- tptacek 3y agoMegaZone as in Usenet MegaZone?
- MZMegaZone 3y agoNo, a MegaZone. Haven't you heard, we come in six packs now. ;-) Yeah, very, very likely one and the same. Since 1989.
- tptacek 3y agoWow, that's a throwback. I was an ISP person back in the Portmaster era. You're at F5 now, I guess! Can you say more about the CVE thing? That seems like the opposite of what Maxim Dounin was saying.
- MZMegaZone 3y agoYeah, 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.
- mholt 3y ago> 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. Even if third parties can file CVEs, do you think it hits different when the parent organization decides to do so against the developer's wishes? Why do he and F5 view the bugs differently? It sounds like the fork decision was motivated less by the actual CVEs and more about how the decision was negotiated (or not at all). (PS. Thanks for participating in the discussion.)
- kayfox 3y agoPersonally, I think its more honest if the parent org does not try to contest a CVE being assigned to a legitimate issue. If a CNA gets a report of a vulnerability in code, even if its an uncommon configuration, they should be assigning a CVE to it and disclosing it. The entire point of the CVE program is to identify with a precise identifier, the CVE, each vulnerability that was shipped in code that is generally available. Based on my observation of various NGINX forums and mailing lists, the HTTP/3 feature, while experimental, is seeing adoption by the leading edge of web applications, so I don't think it could be argued that its not being slowly rolled into production in places.
- dgacmu 3y agoOh my god, the Internet is such a small place. Good to hear you're doing well - we interacted a bit when I was running an ISP in the 90s as well. (Dave Andersen, then at ArosNet -- we ran a lot of PM2.5e and then PM3s). And appreciate the clarification about the CVE disagreement.
- MZMegaZone 3y agoThose 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. And the customers were, by and large, great.
- kelnos 3y agoOof. Presumably Dounin had other gripes about the company that had been building up? This seems like a pretty weird catalyst for a fork. Feels more like this was the last straw among many. I get that CVEs have been politicized and weaponized by a bunch of people, but it seems weird to object that strenuously to something like this.
- rlaager 3y agoI don't know much about this situation, but from what I've read, you were clearly in the right. It doesn't matter if the feature is in optional/experimental code. If it's there and has a vulnerability, give it a CVE. The customers/users can choose how much they care about it from there. > 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 recently did exactly that when a vendor refused to obtain a CVE themselves. In my case, I was doing it as part of an effort to educate the vendor on how CVEs worked.
- conartist6 3y agoYou bring up NGINX+, a commercial product with a CVE reporting policy, but just from reading the docs on it it doesn't support QUIC or HTTP/3. So I guess I can see why the maintainer would be mad about a commercial policy applying to noncommercial work in the absence of any real threat.
- MZMegaZone 3y agohttps://www.nginx.com/blog/quic-http3-support-openssl-nginx/ https://www.nginx.com/blog/quic-http3-support-openssl-nginx/ I know there are other mentions - it's been in the commercial product since R30, hence the CVE.
- dingnuts 3y ago[flagged]
- declaredapple 3y ago> Nothing suspicious about that at ALL no sir nothing to see here. Yes, very suspicious that he didn't want to issue CVEs for checks notes Two DOS attacks that only apply to users that explicitly enabled experimental QUIC support (by default it's disabled)
- ddxv 3y agoWhy wouldn't he want CVEs assigned?
- tangus 3y ago>The most recent "security advisory" was released despite the fact that the particular bug in the experimental HTTP/3 code is expected to be fixed as a normal bug as per the existing security policy, and all the developers, including me, agree on this. >And, while the particular action isn't exactly very bad, the approach in general is quite problematic.
- mort96 3y agoWhat does any of that have to do with assigning a CVE?
- deleted 3y ago[deleted]
- mholt 3y agoI haven't read the content of the patches to understand the impact of the bugs, but from my own experience [0] I can suggest a few reasons: - CVEs are gold to researchers and organizations like citations are to academics. In this case, the CVEs were filed based on "policy" but it's unclear if they are just adding noise to the DB. - The severity of the bug is not as severe as greater powers-that-be would like to think (again, they see it as doing due diligence; developers who know the ins and outs might see it as an overreaction). - Bug is in an experimental feature. I'm not saying one way is right or not in this case, just pointing out my experience has generally been that CVEs are kind of broken in general... [0]: https://github.com/caddyserver/caddy/issues/4775 https://github.com/caddyserver/caddy/issues/4775
- TedDoesntTalk 3y agoTo summarize: the more CVEs a "security researcher" can say he created on his resume, the more impressive he thinks he looks. Therefore, the incentive to file CVEs for any stupid little problem is very high. This creates a lot of noise for developers who are forced to address sometimes nonsense that are filed as "high" or "critical".
- nailer 3y ago> Maxim did not want CVEs assigned. ... to this specific bug in an experimental feature. Originally I read your comment as Maxim doesn't want to use CVEs at all.
- lolinder 3y agoIt would be worth flagging in this comment that you represent F5. I didn't realize that until I found your other comment below.