Toward a more approachable Rust
Toward a more approachable Rust
Posted Feb 23, 2017 14:49 UTC (Thu) by tshow (subscriber, #6411)In reply to: Toward a more approachable Rust by peter-b
Parent article: Toward a more approachable Rust
C definitely wasn't built with security in mind, and there are definitely problems with it, but "C codebases" are also the majority of the attack surface out there.
Posted Feb 23, 2017 15:34 UTC (Thu)
by pizza (subscriber, #46)
[Link] (7 responses)
Are you sure about that? I mean, we're in a bit of a C echo chamber here, but large-scale data breaches are almost never due to anything C-related (ie a buffer overflow) -- instead things like not changing default/hardcoded passwords, network sniffing of insecure connections, SQL insertion, cookie hijacking (and other XSS-type stuffs), and so forth -- and of course let's not forget the "disgruntled employee" who just copies everyhing onto a USB stick and walks out the door...
Posted Feb 23, 2017 17:54 UTC (Thu)
by tshow (subscriber, #6411)
[Link]
Posted Feb 24, 2017 8:26 UTC (Fri)
by peter-b (subscriber, #66996)
[Link] (2 responses)
"Almost never"
https://blog.cloudflare.com/incident-report-on-memory-lea...
Posted Feb 24, 2017 12:35 UTC (Fri)
by pizza (subscriber, #46)
[Link] (1 responses)
C buffer overflows weren't responsible for 1 billion Yahoo accounts having their credentials compromised. They weren't responsible for the multiple point-of-sale compromises that were responsible for my credit cards being revoked three times in a single calendar year (including one actual fraud attempt) Buffer overflows weren't responsible for the Federal OMB's compromise of literally millions of highly sensitive personnel files. They aren't responsible for the Classified info leaked by Snowden or Manning. More down to earth, Buffer overflows weren't responsible for the Murai botnet with upwards of half a million webcams compromised by a fixed backdoor that yielded total access. Buffer overflows have nothing to dow with folks [re]using weak passwords on every online acount. Buffer overflows don't matter at all to [spear] phishing that deliberately targets folks with keys to the kingdom, or systems with "special managment exceptions" because executives can't be bothered to abide by the same security procedures as their underlings.
...And so on.
Sure, at an individual level those overflows can (and do) suck, and we should absolutely fix them. But let's not delude ourselves into thinking that getting rid of C sill have _any_ effect on piss-poor system design and the utter fallibility of the person sitting between the keyboard and the chair.
Posted Feb 24, 2017 12:43 UTC (Fri)
by pizza (subscriber, #46)
[Link]
Posted Feb 25, 2017 5:17 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Posted Feb 25, 2017 12:40 UTC (Sat)
by pizza (subscriber, #46)
[Link] (1 responses)
But on a more serious note -- Due to the nature of how the Cloudfare CDN caching/proxying/rewriting works, this bug seems to be more of an information leak of random data rather than something that can be realistically harnessed/targeted to extract specific, targeted information, as it is heavily dependent on:
1) The exact page contents of what you're requesting (Granted, if you can control the contents of the page being cached, you could conceivably construct pages to maximixe this)
It's not like heartbleed where you could just hammer a single, specific, targeted server again and again and adjust the parameters until you saw something interesting.
...Am I wrong in my interpretation?
Granted, with sufficient time, data capture, and a considerable amount of analysis, one could probably map the random extra stuff one was seeing to at least specific domains, which might enable some targets of opportunity -- eg a specific user session (cookie hijacking), perhaps a random user's credentials if you're really lucky, and possibly even a MITMing of an entire domain if you're able to extract its private TLS key in drips and drabs.
It's lousy, but it's not "our entire user database has been downloaded without anyone knowing" lousy.
Posted Feb 25, 2017 16:43 UTC (Sat)
by excors (subscriber, #95769)
[Link]
That part seems trivial: sign up as a Cloudflare customer and publish a page that triggers the parser bug.
> The other page requests that were served before yours and their contents, size, timing, and whatnot. Given the scale of the Cloudfare CDN, this is the sticking point..
If you want to target users of a specific site, I guess you could perhaps write a page like:
<script>
and host it via Cloudflare, and make users run that script (e.g. distribute it through an ad network).
If the user is already logged into the target site, the first request will send their credentials (cookies etc) over HTTPS, which will hopefully end up unencrypted in the Cloudflare cache server's memory. (The XHR security model assumes GETs don't trigger side effects, and it won't allow the attacker to read the cross-origin response, so that request would normally be safe). The second request will trigger the parser bug, Cloudflare will append random memory content to the response, and (since it's a same-origin request) the attacker can read that response.
Since the two requests are being made by the same user there's a reasonable chance they'll end up going through the same cache server, and since the requests are nearly simultaneous there's a reasonable chance the leaked data will come from the corresponding first request instead of being mixed up with other users' requests. Repeat a few million times until success.
Toward a more approachable Rust
Toward a more approachable Rust
Toward a more approachable Rust
Toward a more approachable Rust
Toward a more approachable Rust
Toward a more approachable Rust
Toward a more approachable Rust
2) The other page requests that were served before yours and their contents, size, timing, and whatnot. Given the scale of the Cloudfare CDN, this is the sticking point..
Toward a more approachable Rust
var xhr1 = new XMLHttpRequest();
xhr1.open("GET", "https://very-secure-site-using-cloudflare.example/");
xhr1.withCredentials = true;
xhr1.send();
var xhr2 = new XMLHttpRequest();
xhr2.open("GET", "page-that-triggers-the-parser-bug.html");
xhr2.onload = function() { /* send the content back to the attacker */ }
xhr2.send();
</script>