I’ve modified the test scripts slightly, to allow arbitrary triggering agents (such as a mail server) to report back the quality of their DNS queries. You may very well be surprised what NS’s your mail servers are configured to use. More often than you’d think, people just don’t know.
So, last week, I had the pleasure of being stabbed, scanned, physically simulated, and synthetically defocused. Clearly, I must have been at SIGGRAPH 2008, the world’s biggest computer graphics conference. While it usually conflicts with Black Hat, this year I actually got to stop by, though a bit of a cold kept me from enjoying as much of it as I’d have liked. Still, I did get to walk the exhibition floor, and the papers (and videos) are all online, so I do get to write this (blissfully DNS and security unrelated) report.
SIGGRAPH brings in tech demos from around the world every year, and this year was no exception. Various forms of haptic simulation (remember force feedback?) were on display. Thus far, the best haptic simulation I’d experienced was a robot arm that could “feel” like it was actually 3 pounds or 30 pounds. This year had a couple of really awesome entrants. By far the best was Butterfly Haptics’ Maglev system, which somehow managed to create a small vertical “puck” inside a bowl that would react, instantaneously, to arbitrary magnetic forces and barriers. They actually had two of these puck-bowls side by side, hooked up to an OpenGL physics simulation. The two pucks, in your hand, became rigid platforms in something of a polygon playground. Anything you bumped into, you could feel, anything you lifted, would have weight. Believe it or not, it actually worked, far better than it had any right to. Most impressively, if you pushed your in-world platforms against eachother, you directly felt the force from each hand on the other, as if there was a real-world rod connecting the two. Lighten up a bit on the right hand, and the left wouldn’t get pushed quite so hard. Everything else was impressive but this was the first haptic simulation I’ve ever seen that tricked my senses into perceiving a physical relationship in the real world. Cool!
Also fun: This hack with ultrasonic transmitters by Takayuki Iwamoto et al, which was actually able to create free-standing regions of turbulence in air via ultrasonic interference. It really just feels like a bit of vibrating wind (just?), but it’s one step closer to that holy grail of display technology, Princess Leia.
Best cheap trick award goes to the Superimposing Dynamic Range (YouTube) guys. There’s just an absurd amount of work going into High Dynamic Range image capture and display, which can handle the full range of light intensities the human eye is able to process. People have also been having lots of fun projecting images, using a camera to see what was projected, and then altering the projection based on that. These guys went ahead and, instead of mixing a projector with a camera, they mixed it with a printer. Paper is very reflective, but printer toner is very much not, so they created a shared display out of a laser printout and its actively displayed image. I saw the effects on an X-Ray — pretty convincing, I have to say. Don’t expect animation anytime soon though 🙂 (Side note: I did ask them about e-paper. They tried it — said it was OK, but not that much contrast.)
Always cool: Seeing your favorite talks productized. One of my favorite talks in previous years was out of Stanford — Synthetic Aperture Confocal Imaging. Unifying the output of dozens of cheap little Quickcams, these guys actually pulled together everything from Matrix-style bullet time to the ability to refocus images — to the point of being able to see “around” occluding objects. So of course Point Grey Research, makers of all sorts of awesome camera equipment, had to put together a 5×5 array of cameras and hook ’em up over PCI express. Oh, and implement the Synthetic Aperture refocusing code, in realtime, demo’d at their booth, controlled with a Wii controller. Completely awesome.
Of course, some of the coolest stuff at SIGGRAPH is reserved for full conference attendees, in the papers section. One nice thing they do at SIGGRAPH however is ask everyone to create five minute videos of their research. This makes a lot of sense when what everyone’s researching is, almost by definition, visually compelling. So, every year, I make my way to Ke-Sen Huang’s collection of SIGGRAPH papers and take a look at the latest coming out of SIGGRAPH. Now, I have my own biases: I’ve never been much of a 3D modeler, but I started out doing a decent amount of work in Photoshop. So I’ve got a real thing for image based rendering, or graphics technologies that process pixels rather than triangles. Luckily, SIGGRAPH had a lot for me this year.
What was once possible via 32,769 packets, is still possible via between 134,217,728 and 4,294,967,296 packets. Yep. We’ve been saying that for a while now. So has PowerDNS. So has DJBDNS. There’s nothing specific to BIND here, though I think most people understand that.
What’s going on here is a simple question: Which would you rather build secondary layers of defense against? Thousands of packet? Or billions of packets?
Look. We were looking at an attack before the patch that took ten seconds and was relatively invisible. Four billion packets are many things, but subtle is not one of them.
So there’s a reason you’re not hearing anyone saying, “don’t patch.” And there’s a reason we’ve been telling everyone this is just a stopgap — that we’re still in trouble with DNS, just less. But in business, we choose our risks every single day. That’s why it’s called risk management, not risk elimination.
And for the most part, people seem to get it. Even the story I was somewhat worried about when I’d heard about it — John Markoff’s piece in the New York Times — is a remarkably fair treatment of the issue. Back in March, we needed to come up with a solution to this problem, that could viably protect as many people as possible in a short period of time. DNSSEC has been in progress for nine years. Asking people to deploy it over the course of a month would not have been a pragmatic approach.
DNSSec may be the long term fix. It certainly was not the short term fix.
Fake Dan Kaminsky is the best thing evar. Mad bonus points for the Root Server Gas Pump. I can’t even wrap my mind around how many shots I owe my crew right about now.
Very nice summary of the “How” part of my talk here.
I do think “Why does DNS matter this much?” is a more important question. It’s 2008 — why can I still not email securely between companies? It’s a little sad that such a simple and basic bug can:
1) Break past most username/password prompts on websites, no matter how the site is built. 2) Break the Certificate Authority system used by SSL, because Domain Validation sends an email and email is insecure. 3) Expose the traffic of SSL VPNs, because heh, who needs to check certificates anyway 4) Force malicious automatic updates to be accepted 5) Cause millions of lines of totally unfuzzed network code to be exposed to attack 6) Leak TCP and UDP connectivity behind the firewall, to any website, in an attack we thought we already fixed twice now 7) Expose the traffic of tools that aren’t even pretending to be secure, because “it’s behind the firewall” or “protected by a split-tunneling IPsec VPN”.
It’s just DNS cache poisoning. Why does it get to do this much damage?
The whole “hostile vs. safe” network myth needs to die. Every network is hostile — the DNS bug just made true something that should already have been assumed, but wasn’t. And we need to get faster and better at fixing the infrastructure. Using things until the moment of catastrophic failure — be they bridges, DNS, or MD5 — is a problem, and we can do better.
FX of Phenoelit made an important point a while back — everything you can do with this DNS attack, you can do with SNMPv3. If you haven’t patched your routers — and that includes your internal routers, since Java’s giving UDP access out and you can thus issue SNMP queries with it (not their fault, the entire web security model collapses when DNS is broken and this is just yet another break) — you should probably do that too.
Wow, this is pretty cool 🙂 Post in comments if I should throw on the HD version.
Red — Unpatched Yellow — Patched, but the NAT is screwing things up Green — OK
(Update: HD Version, thanks to Clarified Networks!)
Slides. Summary:
• DNS servers had a core bug, that allows arbitrary cache poisoning
– The bug works even when the host is behind a firewall
– There are enough variants of the bug that we needed a stopgap before working on something more complete
• Industry rallied pretty ridiculously to do something about this, with hundreds of milllions protected
• DNS clients are at risk, in certain circumstances
• We are entering (or, perhaps, holding back a little longer) a third age of security research, where all networked apps are “fair game”
– Autoupdate in particular is a mess, broken by design (except for Microsoft)
• SSL is not the panacea it would seem to be
– In fact, SSL certs are themselves dependent on DNS
• DNS bugs ended up creating something of a “skeleton key” across almost all major websites, despite independent implementations
• Internal networks are not at all safe, both from the effects of Java, and from the fact that internal routing could be influenced by external activity
Five more days until three more conferences.
Three?
Yep — SIGGRAPH finally deigned to not conflict with Black Hat this year, which means I get to stage a return trip to LA and see pretty pictures. I probably won’t end up with a conference pass, but Emerging Technologies is worth the entire trip. So much awesome stuff to play with!
So, everyone’s making lists of stuff they want to see. Here’s some stuff I haven’t heard people talking about:
Concurrency Attacks in Web Applications — Scott Stender Anyone ever notice how none of the scripting languges have decent threading support — not Perl, not Python, not PHP, not anything? No? It’s because maintaining concurrent access to shared resources is really, really hard — one of the hardest problems in computer science. Theoretically, the problem shouldn’t affect the web, because HTTP is “stateless”.
Well, what’s the first thing every Web Application Framework adds? State. And is concurrent access required to this state?
Apple fixed their server. There are scenarios in which the clients are vulnerable, but it’s servers we need to worry about right now, and Apple did right by fixing their server.
Some people would like to have the IP address of www.doxpara.com, so that if their DNS server is compromised, they can still find out if it’s vulnerable (the theory being, if it’s compromised, it won’t actually go to Doxpara).
Here’s the problem: I’m watching you look up Doxpara’s names. That’s how I can see what ports you’re using! If you don’t use DNS to find Doxpara, I can’t watch you finding Doxpara, and thus I can’t tell you if you’re always using the same ports.
Also, people want to have the ability to ask for a particular name server to be tested. My problem here is that I probably don’t have access to your name server, except through you — so I need your web browser to poke your name server to look up a name from me. Then, and only then, can I tell you if there’s a problem.
Finally. some people think that if their name server only accepts requests from Internet IP’s, it’s safe. No. As alluded to in the last paragraph, I may not have access to your nameserver, but your browser does, and I do have access to your browser.
So, in conclusion: Patch, and verify the patch is working (NATs continue to be a headache). If it’s not working, forward to something that is. OpenDNS has capacity to spare.