>after having received a lukewarm and laconic response from the HackerOne triage team.
A slight digression but lol, this is my experience with all of the bug bounty platforms. Reporting issues which are actually complicated or require an in depth understanding of technology are brickwalled, because reports of difficult problems are written for .. people who understand difficult problems and difficult technology. The runarounds are not worth the time for people who try to solve difficult problems because they have better things to do.
At least cloudflare has a competent security team that can step in and say "yeah, we can look into this because we actually understand our whole technology". It's sad that to get through to a human on these platforms you have to effectively write two reports: one for the triagers who don't understand the technology at all, and one for the competent people who actually know what they're doing.
Had the same experience last time I attempted to report an issue on Hacker One. Triage did not seem to actually understand the issue and insisted on needing a PoC they could run themselves that demonstrated the maximum impact for some reason, even though any developer familiar with the actual code at hand could see the problem in about ten seconds. Ended up writing to some old security email I found for the company to look at the report and they took care of it one day later, so good ending I guess.
This was about an issue in a C++ RPC framework not validating object references are of the correct type during deserialization from network messages, so the actual impact is kind of unbounded.
Here's an idea, from a parallel universe: Cloudflare should have been forced, by law, to engage a third party neutral auditor/pentester, and fix or mitigate each finding, before being authorised to expose the CIRCL lib in public.
After that, any CVE opened by a member of the public, and subsequently confirmed by a third party neutral auditor/pentester, would result in 1) fines to Cloudflare, 2) award to the CVE opener, and 3) give grounds to Cloudflare to sue their initial auditor.
What do you mean, practices from safety-critical industries applied to security? Unpossible! (end /s)
For that you need regulation that enforces it. On a global scale it is pretty difficult, since it's a country-by-country thing... If you say e.g. for customers in the US, then US Congress needs to pass legislation on that. Trend is however to install backdoors everywhere, so good luck with that.
What? We're talking about a free open source library (that I happen to use). Nobody who writes and publishes software for free should be subject to any such regulations. That's why the licenses all contain some "provided as is, no warranty" clause.
Otherwise, nobody would ever write non-commercial cryptographic libraries any longer. Why take the risk? (And good luck with finding bugs in commercial, closed source cryptographic libraries and getting them fixed...)
User-supplied EC point validation is one of the most basic yet crucial steps in a sound implementation. I wonder why no one (and no tests) at CloudFlare caught these carelessnesses pre-signoff and pre-release.
The article's deep dive into the math does it a disservice IMO, by making this seem like an arcane and complex issue. This is an EC Cryptography 101 level mistake.
Reading the actual CIRCL library source and README on GitHub: https://github.com/cloudflare/circl makes me see it as just fundamentally unserious, though; there's a big "lol don't use this!" disclaimer and no elaboration about considerations applied to each implementation to avoid common pitfalls, mention of third or first-party audit reports, or really anything I'd expect to see from a cryptography library.
Does the “don’t implement your own cryptography” advice apply to multi-billion companies, or it’s just for regular, garden variety developers?
Some of the issues like validating input seem like should have been noticed. But of course one would need to understand how it works to notice it. And certainly, in a company like CF someone would know how this is supposed to work…
Surely the devs would have at least opened wikipedia to read
> In order to avoid small subgroup attacks,[6] all points are verified to lie in an N-torsion subgroup of the elliptic curve, where N is specified as a 246-bit prime dividing the order of the group.
Side note: what a nice background gradient those guys put into that website! It goes from dark sky blue to dry desert soil at the bottom. Nice artistic touch.
20 comments
[ 3.8 ms ] story [ 42.8 ms ] threadA slight digression but lol, this is my experience with all of the bug bounty platforms. Reporting issues which are actually complicated or require an in depth understanding of technology are brickwalled, because reports of difficult problems are written for .. people who understand difficult problems and difficult technology. The runarounds are not worth the time for people who try to solve difficult problems because they have better things to do.
At least cloudflare has a competent security team that can step in and say "yeah, we can look into this because we actually understand our whole technology". It's sad that to get through to a human on these platforms you have to effectively write two reports: one for the triagers who don't understand the technology at all, and one for the competent people who actually know what they're doing.
This was about an issue in a C++ RPC framework not validating object references are of the correct type during deserialization from network messages, so the actual impact is kind of unbounded.
After that, any CVE opened by a member of the public, and subsequently confirmed by a third party neutral auditor/pentester, would result in 1) fines to Cloudflare, 2) award to the CVE opener, and 3) give grounds to Cloudflare to sue their initial auditor.
But that's just a mental experiment.
For that you need regulation that enforces it. On a global scale it is pretty difficult, since it's a country-by-country thing... If you say e.g. for customers in the US, then US Congress needs to pass legislation on that. Trend is however to install backdoors everywhere, so good luck with that.
Otherwise, nobody would ever write non-commercial cryptographic libraries any longer. Why take the risk? (And good luck with finding bugs in commercial, closed source cryptographic libraries and getting them fixed...)
Code is speech. Speech is protected (at least in the US).
Reading the actual CIRCL library source and README on GitHub: https://github.com/cloudflare/circl makes me see it as just fundamentally unserious, though; there's a big "lol don't use this!" disclaimer and no elaboration about considerations applied to each implementation to avoid common pitfalls, mention of third or first-party audit reports, or really anything I'd expect to see from a cryptography library.
Some of the issues like validating input seem like should have been noticed. But of course one would need to understand how it works to notice it. And certainly, in a company like CF someone would know how this is supposed to work…
Surely the devs would have at least opened wikipedia to read
https://en.wikipedia.org/wiki/FourQ
> In order to avoid small subgroup attacks,[6] all points are verified to lie in an N-torsion subgroup of the elliptic curve, where N is specified as a 246-bit prime dividing the order of the group.
Funny if that's true.
The only use listed at https://en.wikipedia.org/wiki/FourQ is "FourQ is implemented in the cryptographic library CIRCL, published by Cloudflare."