Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cloudflare Reverse Proxies Are Dumping Uninitialized Memory

bugs.chromium.org

Post reply on HN
Print view View original

531–540 of 1001 posts

Re: Cloudflare Reverse Proxies Are Dumping Uninitialized Memory

#531

Post by Aeolun »

DINKDINK wrote: post #334
SomeCallMeTim wrote: post #80

Earlier quoted context omitted.

My password manager has > 500 entries. Changing all the passwords....isn't going to happen any time soon. If it only took 60 seconds per site, it would still take eight hours to change them all. Might change a few key passwords, though. Couldn't hurt. I only have a couple of bank/financial passwords at this point. And my various hosting service access passwords. Anything else is not worth the hassle -- and mostly wou…

Your argument essentially revolves around "what are the chances I'll be compromised!?" rather than focusing on "What's the potentially affect of getting compromised" Most people with data or access rights which have several orders of magnitude of value relative to 8 hours worth of labor. The decision to wear a seatbelt isn't driven by the probability of needing it, the decision is drive by the magnitude of exposure t…

In the case of seat belts that's probably because the cost of your life is infinity.

The same isn't quite true for my blogger account.

Re: Cloudflare Reverse Proxies Are Dumping Uninitialized Memory

#532

Post by tptacek »

ec109685 wrote: post #505
taviso wrote: post #289

Earlier quoted context omitted.

You have no idea.

Any chance you can describe why these cached pages missed the purge that cloudflare initiated? Seems like cloudflare should have brought an outside expert to try to exploit this issue before the disclosure was made.

For vulnerabilities with immediate exploit exposure, where people are currently being victimized by the flaw, Project Zero has a 7-day embargo.

The short waiting period balances the vendor's interest in coordinating the smoothest fix to the problem with the public's interest in knowing its exposure and maximizing it's options for reacting to the exposure.

The fixed waiting period keeps the process sane. Every vendor you'll ever disclose a serious vulnerability to will try to delay disclosure, usually repeatedly. If you set a precedent of making arbitrary exceptions, you'll never be able to stare anyone down.

Again: as the reporters, you're trying to balance the vendor's interests with those of the public. Your credibility in these situations is pretty important, not just for this vulnerability, but for the next ones. With P0, we all know there will be a long series of "next ones" to be concerned about.

Re: Cloudflare Reverse Proxies Are Dumping Uninitialized Memory

#533

Post by rdl »

jstanley wrote: post #521
garblegarble wrote: post #243

Earlier quoted context omitted.

>I'm currently scrambling for remediation ideas. "Change everything" isn't tractable. It's not easy to deal with but it is the best remediation available to you, given the exceptionally broad scope and months-long period where data was apparently leaking (the cloudflare blog post lists 2016-09-22 as the first date when leaks were possible)

Change my name? Change my address? Change my date of birth? My mother's maiden name? My passport number? It's simply not possible to change all of the sensitive information that might have been leaked.

I think I've settled on "change admin passwords, change any m2m auth credentials which don't require user intervention (API keys in apps, etc. should be rolled regularly anyway)"

Forcing individual end users to change their passwords is probably a net-negative. I might prioritize it if I have OTHER security improvements to roll out soon, though (2FA, upgrading auth infrastructure, other potential compromise, etc.).

I don't think anything else is really viable.

Bitcoin addresses/keys which transited Cloudflare probably should be updated, though, on the extremely off chance.

Re: Cloudflare Reverse Proxies Are Dumping Uninitialized Memory

#534

Post by fletchowns »

emmelaich wrote: post #428
Twirrim wrote: post #372

Earlier quoted context omitted.

That's one phenomenal leap of logic there. Why would you think that?

Merely that both my and the drivers app screwed up at the same time, and have a good chance of hitting the same Uber end-point. Apps that consume APIs would be more sensitive to unexpected junk than browsers.

But there are so many other much more likely reasons why something like that would have happened, it is quite a leap to think that it is somehow related to this issue.

Re: Cloudflare Reverse Proxies Are Dumping Uninitialized Memory

#535

Post by niftich »

Blackthorn wrote: post #527

This is probably gonna get buried at this point, but one thing I'm surprised about is this seems like yet another parser bug. Why are we still using hand-written parsers? Even if you're Very Smart, you'll probably get it wrong. We have parser generators for a lot of things. Even for mostly unparseable garbage like wild-type HTML we have pretty good libraries for handling it. Fresh hand-written parsers are just bombs…

Your comment doesn't apply for this particular case, because the submission goes into great detail that the parser in question was written with Ragel, a parser generator. The code written by them in Ragel contained a bug, which lay uncaught and dormant for years, and manifested only when calling/wrapping code was altered.

Re: Cloudflare Reverse Proxies Are Dumping Uninitialized Memory

#536

Post by wbl »

caf wrote: post #441
infinity0 wrote: post #415

Earlier quoted context omitted.

Parsers don't usually need to hold onto what they're parsing for a very long time, so unless they were running this parallel on a machine with 4k cores, I'd imagine it would be much more likely that a buffer overrun hits the middle of an already-freed allocation rather than going into an active one. In terms of "wasting" memory, perhaps the kernel could detect that you are writing 0s to a COW 0 page and still not act…

In terms of "wasting" memory, perhaps the kernel could detect that you are writing 0s to a COW 0 page and still not actually tie the page to physical RAM. Writing to your COW zero page causes a page fault. Now, in theory you could disassemble the executing instruction and if it's some kind of zero write, just bump the instruction pointer and go back to userspace - but then the very next instruction in your loop that…

How about this idea: free() zeros or unmaps all memory it allocated. This shouldn't fault. The OS zeros pages when mapping them into the process space (which it should do anyway). I think that solves the problem.

Re: Cloudflare Reverse Proxies Are Dumping Uninitialized Memory

#537

Post by meowface »

tptacek wrote: post #532
ec109685 wrote: post #505

Earlier quoted context omitted.

Any chance you can describe why these cached pages missed the purge that cloudflare initiated? Seems like cloudflare should have brought an outside expert to try to exploit this issue before the disclosure was made.

For vulnerabilities with immediate exploit exposure, where people are currently being victimized by the flaw, Project Zero has a 7-day embargo. The short waiting period balances the vendor's interest in coordinating the smoothest fix to the problem with the public's interest in knowing its exposure and maximizing it's options for reacting to the exposure. The fixed waiting period keeps the process sane. Every vendor…

I definitely understand the embargo, but this is one of those situations where the vuln was already fixed and it's likely very few malicious actors (possibly 0, but of course who knows) were aware of its existence.

I feel like adding even just another day or two would've allowed them to purge more of these search results. I think that would greatly outweigh the increased risk of letting it remain undisclosed for slightly longer.

Re: Cloudflare Reverse Proxies Are Dumping Uninitialized Memory

#538

Post by meowface »

jrcii wrote: post #380
Kalium wrote: post #321

Earlier quoted context omitted.

CF's infosec team is very, very good at their jobs.

Obviously not, right?

Application security team? Probably needs work.

But their overall response to this was still good, and very quick given the scale of the issue.

Re: Cloudflare Reverse Proxies Are Dumping Uninitialized Memory

#539

Post by spydum »

patio11 wrote: post #455
tptacek wrote: post #4

Oh, my god. Read the whole event log. If you were behind Cloudflare and it was proxying sensitive data (the contents of HTTP POSTs, &c), they've potentially been spraying it into caches all across the Internet; it was so bad that Tavis found it by accident just looking through Google search results. The crazy thing here is that the Project Zero people were joking last night about a disclosure that was going to keep e…

If anyone here is HIPAA-regulated or you have a customer who is, and you used Cloudflare during those dates, it is Big Red Button time. You've almost certainly got a reportable breach; depending on how tightly you're able to scope it maybe it won't be company-ending.

Isn't it worse than that? Even if you are not a CF user, if your apps make calls to a third party site protected by CF, you could be at risk (stolen credentials, API keys), and could be attacked using those now.

Re: Cloudflare Reverse Proxies Are Dumping Uninitialized Memory

#540

Post by Kalium »

rdl wrote: post #533
jstanley wrote: post #521

Earlier quoted context omitted.

Change my name? Change my address? Change my date of birth? My mother's maiden name? My passport number? It's simply not possible to change all of the sensitive information that might have been leaked.

I think I've settled on "change admin passwords, change any m2m auth credentials which don't require user intervention (API keys in apps, etc. should be rolled regularly anyway)" Forcing individual end users to change their passwords is probably a net-negative. I might prioritize it if I have OTHER security improvements to roll out soon, though (2FA, upgrading auth infrastructure, other potential compromise, etc.). I…

Yeah. I'm changing all the passwords I can get my employer to go for and upgrading auth infrastructure for the rest.
Post reply on HN