Slashdot Mirror
Cloudflare Leaks Sensitive User Data Across the Web (theregister.co.uk)
ShaunC writes: In a bug that's been christened "Cloudbleed," Cloudflare disclosed today that some of their products accidentally exposed private user information from a number of websites. Similar to 2014's Heartbleed, Cloudflare's problem involved a buffer overrun that allowed uninitialized memory contents to leak into normal web traffic. Tavis Ormandy, of Google's Project Zero, discovered the flaw last week. Affected sites include Uber, Fitbit, and OK Cupid, as well as unnamed services for hotel booking and password management. Cloudflare says the bug has been fixed, and Google has purged affected pages from its search index and cache. Further reading: The Register, Ars Technica
If this unremarkable bug in a proprietary cloud platform didn't have a cutesy name, it wouldn't be reported in the news. It would have just been fucking fixed, because fixing it is the important part, not running bullshit news about it.
Ironically calloc would solve a lot of problems if only idiots would stop whining about how malloc is allegedly faster. It's ironic because Calloc begins with C.
And THAT is why I don't use online password management sites, bloody stupid idea anyway, talk about putting all your eggs into one basket.
There are three kinds of falsehood: the first is a 'fib,' the second is a downright lie, and the third is statistics.
Would not have helped. The problem with C is that pointers carry no information about the area of memory they're supposed to be point within. C programmers use pointers like indices, but an index alone isn't enough to address memory: You need the array too, and at least conceptually that comes with a size (but of course pure C doesn't stop you from exceeding array bounds.) What happened here is that the program had lots of buffers in contiguous memory, and by exceeding the one it was supposed to work with, it didn't end up serving uninitialized memory but other (initialized and used) buffers for other clients.
Would not have helped. It's a buffer overrun into other buffers that are in use, not uninitialized memory.
If you're a gambler, you could use malloc everywhere and initialize nothing and accept the fuckups that happen with uninitialized memory, or you can be a responsible coder and use memset everywhere, but wait, since "responsible" and "coder" are contradictory, why use malloc and memset when you can use calloc which explicitly allocates from zero filled memory, so you can maintain your reputation as a badass rockstar who doesn't give a shit about initializing anything, ever!
Calloc! The drop in replacement for malloc that makes your code safer while also making it look like no fucks were given!
Calloc! The drop in replacement for malloc that makes your code safer while also making it look like no fucks were given!
What a pile of shit.
Leave C to the adults, mkay?
CLI paste? paste.pr0.tips!
Except they wrote it in Ragel, which generates C code or asm
So, in theory, any language used like that could have generated bad / vulnerable end-code.
Good luck with that, when you write buggy code in your higher level language and your higher level language compiles to C.
and ASM
Would the ASM have been bug-free?
Would any other language, with ANY amount of safe-guards been physically incapable of producing an off-by-one in it's output code?
No.
This is quite literally "Ragel took a definition, and then compiled it to bad machine code". Whether that was via an intermediary language or not, that's possible with ANY compiler for ANY language. If Java had a bug in it that resulted in incorrect machine code being generated for the "safe" Java code it was asked to execute, the same would have happened.
Bad, buggy compiler. The fact that it used an intermediate language which you disagree with is neither here nor there (and Ragel could output asm direct, so it wasn't "C-specific"). No different to a JVM-compiler bug.
It's hilarious because cloudflare is a pretty strong advocate of Go
No. Read the article.
For the avoidance of doubt: the bug is not in Ragel itself. It is in Cloudflare's use of Ragel. This is our bug and not the fault of Ragel.
They then explain that the root of the bug was a mistake in their flow-control which triggered an inappropriate pointer-increment.
I am genuinely curious about the actual advantages of the CloudFlare CDN.
Some time ago, I tried their most basic package and didn't notice any improvement. In fact, that site had some slow-page-loading issues which their CDN didn't reduce; additionally, some unknown-until-that-moment errors started appearing. Note that the whole point of that offer was convincing me to buy the proper version, so I assume that it was good enough. This was a quite short experience and that's why I don't have a clear opinion about them.
What I definitively find very curious is the relevant number of sites using CloudFlare. Another curious bit is that CloudFlare never fails, at least this is what the error messages say. I mean the ones which are shown when a site using CloudFlare is down, clearly stating that everything is that site's fault because the CloudFlare part is fine. I have never seen one of these error messages saying that the site is fine and CloudFlare is down.
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
Are you denying that calloc can be used everywhere malloc can be used?
On the C Abstract Machine, it can. In the real world (and especially in needlessly linux-specific code), calloc can be^Wappear so much faster. If you allocate a buffer and rely on access being fast right away, calloc might come around and bite you in the ass because of the COW semantics that linux' calloc seems to have.
So using calloc instead of malloc could in theory break some pseudo realtime things.
That said, the inverse is not true, i.e. you cannot necessarily replace your every calloc with a malloc+memset. I'll leave it as an exercise to you to find out why. Shouldn't take all too long, given that you appear highly competent at C.
Are you denying calloc has the beneficial side effect of returning a pointer to zero filled memory?
Side effect? You can not be serious. Yes, it gives you a pointer. No, the memory isn't necessarily zero-filled, or exists in the first place until you first hit it.
Or are you simply a stupid fucking snowflake who objects to crude humor?
Of course I object to crude humor, but what does that have to do with anything? I'm objecting to idiots, which often makes me reply on /. Like here.
If you're a gambler, you could use malloc everywhere and initialize nothing and accept the fuckups that happen with uninitialized memory, or you can be a responsible coder and use memset everywhere, but wait, since "responsible" and "coder" are contradictory, why use malloc and memset when you can use calloc which explicitly allocates from zero filled memory, so you can maintain your reputation as a badass rockstar who doesn't give a shit about initializing anything, ever!
Calloc! The drop in replacement for malloc that makes your code safer while also making it look like no fucks were given!
Sometimes, initializing memory -- just for the sake of initialization -- creates or hides errors. This includes, but is not limited to, allocated memory. For example, Valgrind will not be able to detect reads of uninitialized data if all data always is set to 0. Valgrind is an extremely powerful tool which can track down really obscure bugs, so it's wise to play ball with Valgrind.
Another example may be to initialize a local variable to some default value, blocking the compiler from emitting a proper warning.
But I run my own cloud, so, no it doesn't. Stop lying.
Change is certain; progress is not obligatory.
It's hilarious because cloudflare is a pretty strong advocate of Go
I can't believe they didn't use Rust or Malbolge or Visual Basic.
Just cruising through this digital world at 33 1/3 rpm...
Part of what I do for a living, and have done for many years, is evaluate these kinds of vulnerabilities. This could have been really, really bad, a major story. Certainly it would be a big deal if all of the following were true:
If the issue existed for a long time.
If the bad guys knew about it before it was fixed.
If it affected sites that had something vaguely resembling valid html.
If it could have leaked tls/ssl keys.
In the security field, we have a mostly objective scoring system called CVSS which gives a numeric score to how bad the risk is. This scores high enough that it needed to be fixed right away - and it was fixed right away, probably before any bad guys knew about it.
Given the details of the issue, and how it was handled by first Google and then Cloudflare, I don't think it's the biggest story of the year. Cloudflare fixed it within hours and got cached copies of affected pages removed from search engine caches. All evidence indicates this was done before any bad guys were aware of the issue. I'm not too concerned. That's my professional opinion. My opinion would be different if it were left unfixed for six years after it was publicly known, then half fixed for six more years (looking at you, Microsoft).