Security Now! - Episode 260
SERIES: Security Now!
DATE: August 5, 2010
TITLE: DNS Rebinding
SPEAKERS: Steve Gibson & Leo Laporte
SOURCE FILE: http://media.GRC.com/sn/SN-260.mp3
FILE ARCHIVE: http://www.GRC.com/securitynow.htm
DESCRIPTION: This week, after catching up on all of the post-Black Hat and DefCon conference news, Steve and Leo plow into the detailed depths of “DNS Rebinding.” Together they thoroughly explore this significant and fundamental weakness of the Internet's security.
LEO LAPORTE: This is Security Now! with Steve Gibson, Episode 260, recorded August 4, 2010: DNS Rebinding.
It's time for Security Now!, the show that covers all your security needs. And here he is, the king of Security Now!, man who's been doing it now for five years, Mr. Steve Gibson of GRC.com. Hi, Steve.
STEVE GIBSON: I guess security really is a need. You introduce the show saying “covers all your security needs.” And in fact I would argue that you probably can't really get very far these days, or not very safely, without having that need covered, so…
LEO: I think in some ways it's kind of a shame that you have to be a security expert, well, at least a mini security expert, in order to use the Internet and use your computer. And that's such a shame.
STEVE: Oh, Leo, I hate that we have to have this podcast. I mean, I love doing it. But, I mean, I'm so annoyed that, well, I'm so annoyed that this is necessary. And today's episode is an interesting indication of a different sort of reason that it's necessary. We're going to talk in detail, as I promised a couple weeks ago, about DNS rebinding, which came back up into the news, even though it's 15 or 16 years old, that is, the problem is. It came back in the news because there was going to be a presentation, as there was, at the recent Black Hat conference, where there was a new approach that allowed malicious remote websites to take over people's local routers. And it used the trick of DNS rebinding. So I thought it was worth looking, sort of revisiting it. I don't think we've ever really covered it in depth, which I wanted to do.
But what's interesting is that this is a problem that is not about anything being broken, not about a vulnerability, not about anything even being designed wrong. It's just that the system we've built was never, from its original concept, never built with security in mind. And there are ways to abuse technology that works the way it's supposed to, in ways that the original architects weren't defending against. It just wasn't in their mind. And, for example, this is so fundamental to the way DNS works that not even DNSSEC, the next evolution, not even signing the root node, and not even DNS security prevents problems with DNS rebinding.
STEVE: Yeah. So…
LEO: So this isn't the Dan Kaminsky flaw. This is a whole different thing.
STEVE: This is a kind of a “gotcha” with the kinds of stuff we're trying to do. And so it's a consequence of clever people saying, you know, if we did this a little differently, we could make something happen that people have been trying to prevent since Mozilla 2.0. Which is…
LEO: [Laughing] Wow.
Speaking of every single week, this is 260. And it's been a phenomenal amount of controversy over in GRC's newsgroups about when it is that we actually finish year five and start year six. And so I looked at the calendar. Actually I looked at our archive of prior podcasts. And what struck me as I was - we were talking about this a little bit before we began recording - is this podcast used to be about 20 minutes long.
STEVE: First one was 18 minutes long. And they stayed about that long for quite a while, and then began to grow in, I guess, covering more current events. I don't think, I mean…
LEO: We weren't doing news in the first few years, I think.
STEVE: I think that's exactly right. We weren't covering that so much. It was mostly just topical stuff.
LEO: Right. And we didn't do Q&As in the first few years.
STEVE: That's true.
LEO: So we were just saying, okay, here's how cryptography works, or here's - so in a way it was just the chunk, the kind of the end chunk of the show that we still do, but now we've added a lot of other things. I hope you all like it. I think, you know, remember, this is the second show we ever did on the TWiT network. I started doing this right after TWiT. And half the time I did it in Canada with you.
LEO: We did them on the set; you know?
STEVE: I won't ever forget standing on the set in Toronto, and you said, “Hey, Steve, would you be interested in doing a podcast about security?” I said, “A what cast?” Never heard the term. That was in March of…
LEO: 2005. Wow.
STEVE: …'05, I guess, yeah, yeah.
LEO: Yeah. And I think at the time, when we first started, I didn't know how long a podcast should be. And all of the shows have gotten longer. Not only because we're wordy sons of guns, all of us, but also in reaction to the fact that I always hated it that I only had six minutes with you on TV. It was always rushing. We never really covered the subject thoroughly. And audience support for longer shows. I've always been saying, and I'm still open to the idea, is this too long? And as long - I think what people want is it should be the length of their commute.
LEO: No shorter.
STEVE: If everyone would please drive exactly 90 minutes…
LEO: No shorter. No shorter. Longer is okay because you just stop, and you pick it up. But what you don't want to do is listen to a show, and you're still in the commute, and now you have to find another show. You want - it's my sense, and I'd love to get feedback from people. But that's my sense of it.
STEVE: It's like finishing a book when I'm in the middle of my stair-climbing workout, Leo. Nothing worse than that. It's like, okay, now what am I supposed to do?
LEO: Somebody in the chatroom is saying, can you tell the story of how you two met? We won't go into great detail. We've mentioned it before. But we met on The Screen Savers. We were covering something called “The Click of Death,” which was a problem that ZIP drives had. They'd go click-click-click, and then the drive was damaged in such a way that it would damage every single ZIP disk you'd put in there. So you would destroy your collection as you tried to find a disk that worked.
LEO: And Steve wrote a program, Trouble In Paradise; right? Was that it?
STEVE: Yup, TIP, Trouble In Paradise.
LEO: And we put you on the show, Kate Botello and I. So it was in 1998. It was the early days of The Screen Savers.
STEVE: Yeah. And you and I knew of each other, but we had never…
LEO: Oh, god, I'd read you religiously in your InfoWorld column. I was a huge fan of Steve Gibson. So, as has been the case my entire career, people like Jerry Pournelle, John C. Dvorak, you, you know, meet you, and it's like, oh, I'm meeting an idol. It was really, really exciting to meet you.
STEVE: Well, and my favorite memory was when Kate discovered ShieldsUP!; and it was, like, her turn to do a segment of the show. So you were sort of the sidecar for that particular phase. And she said, “Yeah, this is over at GRC.com.” And it didn't register with you immediately. And so she was starting this, like, “There's this really neat thing that checks your ports.” And you said, “Wait a minute. Steve Gibson? He's SpinRite, you know, he's the hard drive guy.” And she says, “And apparently security, now, too.”
STEVE: So, yeah, that was the beginning of that, which was fun.
LEO: Yeah. And I consider Steve one of my best friends.
LEO: And so we're celebrating five years of shows, but we've known each other for 12.
STEVE: Well, and speaking of five years, I did the math last week where I said, okay, 365.25 days per year because every fourth year is leap year, so we get an extra day, which we divide by four because it's every four years. You divide that by seven days per week because I think we're all agreed that each week has seven days. You never have a six-day week.
LEO: I think we're in agreement on that.
STEVE: Never have an eight-day week.
STEVE: That would really throw things off. So you divide that by seven days per week. And it does not give you 52 weeks in a year, it turns out. It gives you 52 point whatever it was, 197, or 179, I think. Now, if you then multiply that by five years, so exactly how many weeks there would be in five years, you get 260.8 something or other. So rounding that up you get 261, which would say that next week's episode, 261, would be ending year five. So we'll be beginning year six on 262. And lo and behold, our first episode that we recorded back in 2005 was on August 19th, Thursday, August 19th. And that will be Episode 262 is August 19th of August 2010.
LEO: We'll have a cake.
STEVE: So the math works, and I hope the controversy is finally resolved.
LEO: I love it when a plan comes together.
STEVE: But I do stand, I stand corrected that for many weeks I was saying 52 weeks a year, 52 weeks a year, and multiply that by five. It's like, no, because there are those little annoying leap years. And they add up, so.
LEO: Well, they only add up when you've been doing a show for five freaking years. That's why they add up. I mean, the first couple of years it didn't matter.
STEVE: We'll be leaving that behind soon.
LEO: We've got some great stuff to talk about. We're going to talk about, as Steve mentioned, DNS rebinding. We've got security news. We've got patches galore, of course.
STEVE: Oh, and we've got - Black Hat and DefCon were last weekend, and lots of follow-up from that, too.
LEO: Yeah. I'm dying to hear what you think about that.
STEVE: Not too much fallout, so that's the good news.
LEO: And, you know, I'm just getting news now that - we heard that India was having trouble with BlackBerry, that it wasn't secure, they were worried. It was banned in India. Now Dubai and the United Arab Emirates banning BlackBerries. And now we've just learned that the European Commission is abandoning its BlackBerries because - and going to iPhones because they don't deem the BlackBerry software safe enough. And they think that the U.S. actually has a backdoor into it.
STEVE: Well, yeah, we have BlackBerry discussion actually in our notes.
LEO: We will talk about that, too. Now, moving on to Security Now!, you have an update on this LNK thing. Thank goodness.
STEVE: Yes, well, big news, I mean, in terms of security updates. And I'm presuming that all of our listeners know this by now because this happened Monday. As we were hoping, and maybe on the border of praying, Microsoft responded with what they called an “emergency out-of-band” - that term still, it ought to be out-of-cycle, but what the heck - emergency out-of-band patch for this shell LNK vulnerability that we've talked about extensively, so I won't go into it in too much detail. Everyone I'm sure knows about it.
This was the big problem where Microsoft's only solution was to disable the displaying of all shortcut links. If you used their Fix it button, it would turn all of your shortcuts within your entire system into white featureless rectangles. This is also the thing where Secunia had come up with a temporary interim filter to solve the problem in a less UI-disturbing fashion. Microsoft released the patch on Monday. So I would imagine that people would have seen their little yellow shield appear.
In any event, if your system didn't get notified, or if you don't have Windows Update set up for automatic updates, absolutely you want to get this patch installed. You can, after that, safely unfix it from Microsoft's Fix it button. And if you installed the Secunia temporary interim fix, you can remove that using the Add/Remove Programs list in Control Panel. And this little nightmare is behind us. The use of it was going up exponentially. Many other uses were being found, aside from the first-seen attacks. So it's a good thing that this was resolved.
Now, the thing that still bugs me is that Microsoft didn't acknowledge any problem before Windows XP SP3. So in their list of systems affected, they're not even saying that Windows 2000 has a problem, or Windows XP SP2 has a problem. They both do. As far as we know, NT does. But so I'm annoyed that they're not saying these, like, everything has a problem, but these are the ones we're going to fix. They're just ignoring the fact that earlier systems have a problem, but they're not going to fix it.
LEO: Well, we know nobody uses earlier versions of Windows.
LEO: They've all upgraded.
STEVE: We'll be talking about IE6 in the U.K. here pretty quickly. Now, I saw one mention in the SANS security newsletter. Their dean of education, I think is his title, Johannes Ullrich, who runs the Internet Storm Center. He made - he just - there's one little line comment that SP2 is being silently supported by this fix.
LEO: Oh, interesting.
STEVE: Now, I've not verified it. I thought, well, okay, I care about that because I'm on SP2 still, with a system that once reacted badly to SP3, so I backed off on that. And I checked Windows Update. It didn't have any happiness for me. So I don't - I have to pursue this a little bit further. I will, and I'll see if I can find it. And if I can, I'll let people know. I ran across some people who were saying, hey, I'm still using Windows 2000 because it works just fine. So it's like, yeah, I understand that.
LEO: Except it doesn't, I mean, at this point.
STEVE: Except, yes, except this is a long-term threat. And the bad thing is even the Secunia fix won't fix Windows 2000. It will fix, in the way that they offer, XP SP2. So you can use it on XP, just not any earlier than XP, which is too bad because otherwise it might be all we have, if, in fact, Microsoft didn't fix SP2. I'm not surprised they, Microsoft, would have fixed SP2 silently, if in fact they did, because that would just, I mean, it makes sense because there are people who have known problems with SP3.
LEO: Yeah, I can understand saying, oh, look, we don't want to support software after a certain point. That's understandable. Software after a while gets out of date and so forth. But just to protect the Internet there's a certain responsibility you have. Even, to use another example, if a car is 20 years old, but you discover that the brakes fail, you still have a responsibility…
STEVE: Even if it's out of warranty…
LEO: …even if it's out of warranty to tell the owners, look, we've discovered a problem, and here's the fix. So just for - you don't have to fix bugs. But you have to fix security flaws. You have to. And I think you have to do it as long as those operating systems continue to be used, not just for the owners of the operating system, but for everybody else.
STEVE: I'd buy it. I mean, I could say, I mean, I could even see it being reasonable if Microsoft said, while these OSes are under our security umbrella, we're going to fix them for free. After that, you're going to have to pay for it. Now, of course that would cause all kinds of problems, too. But if it's a matter of buying it versus always having this really bad security problem known, I'd fork over, you know, five bucks to get the patch.
LEO: I can't imagine that the cost of, once you've got the fix for…
STEVE: They know what it is. They know what's wrong. They fixed it everywhere else.
LEO: I cannot imagine that it's so difficult to fix it for these other versions. I think it really comes down to we are trying to push people to upgrading. And some of it's to make money, of course. But some of it is just because we don't want to have to support these versions at all. We want them to be gone.
STEVE: Well, and to be fair to Microsoft also, we know that they have been doing a good job - now, this is me saying this - a good job in increasing the security of this Windows platform moving forward. We've got address space layout randomization. We've got the execution prevention where they're doing more work with protecting the stack. We've got UAE. I mean, there are many things that they've been doing that are enhancing the security moving forward. So it is in fact in people's own best interest, where they can, to move forward. And I'll be on Windows 7 at some point. I'll just jump over the dead carcass of Vista, happily, and go directly to Windows 7. So…
LEO: You'd be right to do so, I think.
STEVE: Oh, yeah, exactly. Again, I think that's a very good point. So one of the things I had my eye on the most was this concern, which we discussed in some detail last week, but we didn't have all the details because it was upstream of the formal presentation at Black Hat of this WPA2 hack or crack, which was supposed to - it generated a lot of press, and lots of people were wondering what the story is. Believe it or not, it's now being criticized within the security community as a publicity stunt.
STEVE: I mean, it was - it turns out it's exactly what I described before we knew any details last week. And even, like, people in the Wi-Fi Alliance, now, you can imagine that they have some bias of wanting not to believe that this was anything big. They're saying, this is not news. Everyone knows this about the way WPA…
LEO: Was it brute force? What was it?
STEVE: It was the idea that, if you were authenticated on a WPA or WPA2 - because it doesn't matter whether you use, for example, a radius server for producing per-client passwords, or you use a single password for the whole access point - if you're a client associated with a WPA-protected access point, then the groupwise temporal key, or temporary key, the groupwise temporary key which all clients of a single access point share, in order for them to do things like broadcast to each other, that allows you to essentially do an ARP spoofing, that's all this turned out to be was ARP spoofing, in order to intercept someone else's traffic.
The problem is that traffic is still encrypted with their private key. I was thinking maybe these guys had come up with something, and this is why I was, like, withholding judgment last week. Maybe they'd come up with some way of changing what's called the “pairwise temporary key,” or getting the other client to divulge it to the attacking client. They didn't. They just said, well, we can filter traffic. I mean, like, we can filter traffic that we can't decrypt. And so other security consultants, because I was wondering what the fallout from this was, they were just, like, saying, well, this was nothing. I mean, this is nothing new. This was a publicity stunt.
So there is a clever hack that can be used against a secured access point, which we actually did talk about years ago, where, if you convince another client that you're the destination for its traffic, it will send that traffic meant for you to the access point under its own encryption. The access point, seeing that it's meant for you, will then decrypt it into plaintext, reencrypt it under your key, and send it to you. So you've got the other person's traffic, the other client's traffic that you've received under your key, courtesy of the access point in the middle decrypting it and then reencrypting it.
But that requires something known as “inter-client communication,” which is explicitly and by policy normally disallowed on an access point. All access points have an option to - and it's normally defaulted - to prevent inter-client communication. In which case that particular problem, which has been known about for years, thus the reason that an access point will not forward traffic between clients, is normally enabled to prevent that. So again, all these guys could have done was to receive traffic that they have no visibility into, traffic directly from another client, because they'd done ARP spoofing, so the client is sending it to them instead of to the access point. But they don't ever get the other client's pairwise temporary key.
Which is why security consultants universally said, okay, so, what are you going to do? Yes, a denial of service attack. You could use this to cause another client to lose connectivity. That's as far as anyone can see, and now we understand everything that these guys were showing, that's the limit of what this could be used for is causing them to lose contact, another client to lose contact with the access point by redirecting their traffic to you or to somewhere else. And it's like, oh, okay, well, and that's only if you are already authenticated on that access point. So it's an insider deal. It's not somebody on the outside that can do anything because you first have to be authenticated to the access point to get the shared key.
LEO: Well, forget it, then.
STEVE: Which you then use for ARP spoofing. I know, it's nothing. I mean, yes.
LEO: You've already got access. So now you can get access.
LEO: Who cares?
STEVE: Well, you've got access, so you can annoy somebody else who also has access by causing them to, like, have to reassociate or relink to the access point. Okay, fine.
LEO: Big deal.
STEVE: So we're not worried. The other big piece of news was that a mistake that's been found in Apple's PDF rendering engine, when it's rendering Type 1C fonts in PDF files, because Apple has its own PDF renderer, doesn't use Adobe's Acrobat for PDFs. A mistake there has been used to create a vulnerability, or to exploit that vulnerability, to easily, I mean, with remarkable ease, jailbreak just about any iPhone or iPad. And Leo, you've got more experience with this than I have, so…
LEO: Yeah. We did it, it's funny, we did it on Sunday. Brian Brushwood on TWiT was brave enough to do it. I tried to do it on my iPad, and at the time there was a bug that prevented that. They fixed that, so I did it on Tuesday on my iPad. And while there may be some little issues, the jailbreak itself seems to work just fine and be harmless. However, as you're about to tell us, the fact that you can do this is a significant security problem.
STEVE: Exactly. So it's weird because the press was carrying this as, oh, look, now it's easy to jailbreak your phone. You'd literally go to jailbreakme.com.
LEO: That's like saying let's all go to hacker.com.
STEVE: Yeah, well, and it's interesting, too, because, I mean, I went there with Firefox, just jailbreakme.com. Go with Firefox, and you see what looks like a little entry screen on an iPhone app. And it would be like a “slide here to jailbreak your phone.”
LEO: That's exactly what it looks like on the phone.
STEVE: Yeah. And you can also check, I think somewhere else I was able to go, like for more information. And on my non-iPad or iPhone browser, that is, on Firefox, you get this long strip of website, or like webpage, that would normally be what you would see on your iPhone if you scrolled along with the iPhone, which explains what's going on. And it's got - it's open source and GPL this and that, and they use compression, and so they're giving credit where credit's due and so forth.
The problem, though, is, well, okay, first of all, so that's what happened. This was also disclosed at last week's conferences. And the concern that everyone has is that you can - essentially you are using this font-rendering bug which is now well known publicly to run arbitrary code which is sort of part of the font. So the code is bundled in with the font. And this mistake in Apple's rendering of the PDF causes the code to execute due to a heap or a buffer overflow. Which is to say, jailbreaking is only one thing this can be used for. This is not a jailbreaking vulnerability. This elevates this Safari to root privilege.
STEVE: It gives Mobile Safari the ability to run as root in your phone, breaks it out of the sandbox, and then lets it do anything it wants to, that is, anything the attacker wants it to do. So the good news is, there could hardly be anything that Apple is trying to fix faster than this.
LEO: You know what the funny irony is, that once you've jailbroken it, there is a fix in the Cydia store which you can now have access to for the PDF vulnerability. So you can - the way to fix, right now, until Apple does an update, is to jailbreak your phone. And as far as we can tell, jailbreakme.com is safe. I'm not, I mean…
LEO: I'm not vouching for it, but I know Saurik, I mean, these people are fine and honorable people, and it's legal to do so, as we know now.
STEVE: The DMCA, yes, Apple had been threatening people using the DMCA. And what, about a week or two ago the ruling came down that, no, jailbreaking of your own phone is something you're entitled to do. The DMCA will not protect you.
LEO: Apple says, not unreasonably, we will void your warranty.
STEVE: We're still mad at you.
LEO: Don't come crying to us.
STEVE: We're still mad at you.
LEO: But we can't stop you. And you should be aware this is a risk, security risk. But on the other hand, this is also the fix, which is kind of funny. Now, we don't know what other holes are created by this, either. So that's another matter entirely.
STEVE: So you jailbreak your phone. Then you can use an unauthorized app to fix the vulnerability.
LEO: Exactly, to fix it, yup.
STEVE: Yeah, okay.
LEO: Isn't that funny.
STEVE: They ought to just put that app in the store and let people fix it until they make it official.
LEO: Gee, what a thought.
STEVE: Well, also in Black Hat, which gave us all kinds of material this week, it was revealed that there's some nasty wallpaper which has been downloaded approaching a million times, at least many hundreds of thousands of times.
LEO: Wow. I didn't realize it was that much. Wow.
STEVE: Yes, it's approaching a million, Jackeey Wallpaper, from a Chinese site called IMNet. It turns out it's free wallpaper. It presents you with your choice of many copyrighted, stolen intellectual property items. And what was discovered was that it was, in the background, collecting phone numbers, SIM card numbers, text messages, subscriber IDs, and voicemail passwords.
LEO: Oh, boy.
STEVE: And mailing them back, sending them back to www.imnet.us, which is in Shenzhen, Guangdong, China. So this is a cautionary note, just in general, about not installing apps that you don't trust. Now, it's true that Android, as we know, is a much more open marketplace than the iPhone store.
LEO: Nobody's vetting it, as far as I can tell.
STEVE: Well, and my fundamental problem with the notion of vetting is that nothing prevents Apple from being fooled.
LEO: Right, as they have been. They have been.
STEVE: They have, exactly, Apple has been fooled. Unless they receive the source code and study it, they're not going to be able to tell, for example, what behavior an app could develop after a certain date.
LEO: This happens all the time. There are apps in the iPhone store to do things like enable Emojis. They pretend to be flashlight apps, but they enable Emojis. Or they do tethering. And Apple eventually learns of these, pulls them off. But that's exactly the point is that there's no real way to look at these and say, well, what is it really doing? And in fact there was a hack that allowed iTunes passwords to get leaked out through a malicious app on the Apple store. So just any time you put applications on an operating system, I don't care if it's a phone or a desktop, you run a risk.
STEVE: Yes. And I was going to also add that, as we know, people have heard me say this many times, even if they had the source code - and of course they don't. But I would challenge Apple's engineers, first of all, they're not going to be able to learn the source code of every app, how many gazillion there are that they're bragging about on the store. But, I mean, as I have often said, you can be staring at code, and you inherently buy into what the code says it's doing. And your eyes would scan right across something that someone malicious had cleverly had the code do that you could just never detect. You would not see it. So that would create a whole new cat-and-mouse game of “Apple's making me give them my source code. Well, I'm going to put something in it just to show them that I can.” Which we're not going to have to go to because Apple doesn't get the source.
But so, yes, Leo, I think your summary is exactly right. These phones have evolved into computers. And unfortunately, as we know, the thing that is the source of all of the vulnerabilities we talk about in the guise of full-blown PCs and Macs and UNIX and Linux machines is the connectivity. And phones are inherently connected. That's what they're for is their connectivity.
LEO: Which makes them more desirable, frankly, to hackers. I mean, I think ultimately this is going to be the frontline of security is these phones. There's ways for them to make tons of money just by commandeering the phone.
STEVE: Yes. And there's a cornucopia of little apps that you can download, that people are downloading all the time, that do things. And the problem, of course, is that people are also using their phones for storing personal, confidential data.
STEVE: Text message dialogues and their address books and so forth. And there have been high-profile instances where celebrities got their data sucked off their phone for reasons of, like, a dumb password. Paris Hilton I think famously had that happen to her because…
LEO: She had a dumb secret question that was her dog's name, which everybody knows.
STEVE: Exactly. So the problem is these things become repositories where you assume confidentiality that you really can't assume on a connected device. So the lesson is security-conscious people really need to exercise extreme self-control with the apps that they run. We would like to believe that the sandboxing, which Apple and Android both have deliberately engineered, is going to work. But we're seeing instances where it just doesn't, where mistakes made in the code break out of the sandbox, much as this jailbreakme problem with the PDF rendering elevates Safari to full root access, and then it can do whatever it wants to.
LEO: It raises a really interesting question because I think people have said, oh, well, the Google store isn't as safe, the Android store isn't as safe because it's not vetted. And people have proposed that maybe there should be a vetted and unvetted store. Maybe Google should have Google-approved applications, or the carrier. Actually Verizon does that, Verizon-approved applications. But you raise that point that you cannot ever be 100 percent sure unless you demand source code. And even then it's tough.
STEVE: Yes. I would say that there's no better example of what would end up being a false sense of security.
STEVE: Coming from anyone saying, okay, we're going to put our stamp of safety. It's like, well, are you going to guarantee? Well, of course not. They would never do that.
LEO: They can't.
STEVE: They can't.
LEO: What about antivirus software, that kind of thing? Is that the next thing to do? I mean, there is antivirus software in Android. There's Lockout, something like that, that I've used, that looks like it scans every download. I don't know what it's scanning for, but I don't think that would solve it.
STEVE: I don't think so.
LEO: It needs heuristics, wouldn't it. It would need to monitor what's going on.
STEVE: Yeah, and we've got - two more bullet points ahead of us is an interesting concept that was released at Black Hat that we're going to spend some time talking about.
LEO: I won't slow you down. Go ahead.
STEVE: Sort of like that. In the news, the U.K.'s Information Commissioner's Office, the ICO, formally concluded that Google “did not collect meaningful personal details.”
LEO: Thank you.
STEVE: So, yes, exactly. So they have said they looked at what Google collected, and they were one of the first people to say we want to understand what was going on. They do. And they've essentially let Google off the hook. They did say they were going to keep an eye on what other countries' investigations uncover. But their preliminary feeling is they were collecting it by mistake, they didn't intend to use it, they didn't use it, and they're sorry. So, I mean, and I think that's all true.
Unfortunately, while the Information Commissioner's Office seems to have a clue, the U.K. government itself seems not to. Well, or they're stuck between a rock and a hard place. They've formally said that they're going to continue using IE6, against mounting pressure to get with a better browser, even 7 or 8 under IE, or maybe Firefox. The bad news is they made the mistake many years ago of commissioning the creation of a large body of custom, government-driving software which only runs on IE6.
LEO: [Laughing] Sorry.
STEVE: It is locked to IE6…
LEO: Oh, dear.
STEVE: …platform, and it will not run anywhere else.
LEO: Oh, why?
STEVE: So they're saying they cannot leave IE6 without incurring a huge cost. It's like, well…
LEO: Yeah, I'll tell you a huge cost. You want to see huge costs? I'll show you huge costs.
STEVE: [Indiscernible] Microsoft stop supporting that. And then good luck to you.
LEO: Well, I see this all the time, especially in line-of-business software that just requires IE. And maybe it's ActiveX. It probably is. It's probably that they require ActiveX; right?
LEO: But it's just, oh. But that should be a red flag for anybody who's buying or using software. I think.
LEO: I'm sure you would agree.
STEVE: Also, speaking of Dubai and places in the region, the UAE has stated that - they've even given a date. As of October 11th they are going to shut down BlackBerry service within the UAE because they're unable to determine what people are texting and sending back and forth to each other. BlackBerry's crypto is state of the art. It's a properly designed public key crypto system where individual BlackBerry phones have public keys that they use. Each phone contains a certificate that it uses to negotiate a secure connection to BlackBerry's servers, wherever they're located, in Canada presumably. And that establishes a tunnel whose cryptography, whose encryption cannot be broken, as far as anyone knows.
So this has been a problem. As you were saying before, India a few years ago brought up the issue. They were uncomfortable with what RIM was doing. And BlackBerry, the RIM folks said, well, we're not going to drop our encryption. They sent some emissaries over to India to negotiate, and no one's really sure what happened except that BlackBerry, RIM was still able to continue service. So other countries in the region are similarly concerned that these phones are going to somewhere outside of their control, and who knows what's happening? I mean, I don't know what RIM is doing. All we do know is that the technology is so safe that our own government does allow BlackBerries to be used in sensitive situations.
LEO: Everywhere in government. Everybody in government uses BlackBerries. At least the last time I was in DC. They all use BlackBerries. This is when we - this was a few years ago, five years ago, when we interviewed Michael Powell, who was the chairman of the FCC at the time. He lived on his BlackBerry. Now, if the chairman of the FCC feels it's secure, I think it's probably secure.
The European Union Commission has just announced that they're not going to use BlackBerries. The quote is they've evaluated - and it's not just for security. They say for durability and running costs, as well. But you've got to think security is the primary concern. “Following this evaluation, the HTC and the iPhones emerged as the most suitable platforms for voice/mail-centric mobile devices. As a result, the Commission currently supports these two platforms,” not BlackBerry.
STEVE: Well, and of course those are generic email clients where you configure them to connect to whatever server, wherever.
LEO: So they could run their own, I guess, and not have to worry about going through Canada, the RIM servers in Canada and so forth.
STEVE: Yup, exactly. And so that means that those email servers can then be monitored and watched…
LEO: I think that's what's - yeah. That's really what's going on. It's not that they're insecure, it's that they couldn't monitor them. They couldn't watch.
STEVE: Well, if you have, for example, you have two BlackBerry phones in the UAE, and they are texting to each other, that sets up two very secure encrypted connections back to RIM. And it's only there that the text is decrypted and then reencrypted and sent back out to the other phone. So nobody anywhere in between, except at RIM, is able to see what's going on. So not only can no other extra government forces monitor the channel, but it is the case that back there at BlackBerry those communications are briefly decrypted as they're being reencrypted and sent to the other phone. So there's a vulnerability there from a state secrets standpoint. It must be, I guess it's possible for corporations and no doubt the government to run its own servers. I don't know what the architecture is from that standpoint. But…
LEO: Yeah, they have these BIS servers that they could run.
STEVE: Yes. And I don't know whether that still runs through BlackBerry or how the security architecture works because you would think that governments could do that, I mean, like the UAE could do that, except obviously that's not an option for…
LEO: They say, and this is why the UAE's banning it, they have their own state-run telecom - it's Telesat, I think is what it's called, or eTelesat. And they say that, because it still has to run through Canada, they can't - they won't support it. October 11th they're going to cut off email Internet access. There's half a million users in the UAE. When I was in Dubai, everybody had BlackBerries. But they love iPhones.
STEVE: Interesting. Also at Black Hat, an interesting - and this is what I wanted to talk about - an interesting concept called “Blitzableiter,” which is German for lightning rod.
LEO: Love it.
STEVE: Presumably, I guess it was named because what it does is it's an interesting approach for making Flash secure, the idea that it turns lightning into just a flash or something, so lightning rod. And it's an interesting concept. And from a security standpoint, I really like it. Which is why I wanted to give it a little bit of time and talk about it. The concept is that it's sort of an intermediary which reads a Flash file, a Flash movie, as they're still called, and parses the file into essentially a meta language, into sort of its own intermediate representation, and then builds that back into a Flash file. And this is something, this is a technique that has been around for years. It's one way, for example, in the case of Internet packets, where there's a concern that network packets could in some way be malicious.
The idea is you never let a packet cross from an untrusted area into a trusted area. Instead you have something in between which interprets the packet, basically breaking it down into an intermediate language, into some description of what this packet is supposed to do. You then discard that packet completely; and, using the description only, you build a new packet that does the same thing. And the beauty of that is things you don't know about, mistakes that are being made, for example, deliberately created in the original packet, they get flushed away by this reinterpretation.
First of all, if the interpreter looks at the packet and can't understand something, well, it's probably been malformed. So it ought to just be dropped. It's like a bad packet. But if everything seems to be okay, the act of - it's as if someone who couldn't lie was being used as a proxy and received some information and then turned around and told it to someone else. Well, if that person can't lie and has knowledge of the truth, then they're a filter. They're going to prevent a lie from passing through them. Similarly, if this interpreter is designed to build benign packets from a description of what an incoming packet does, well, it's going to prevent any sort of badness from getting through.
Well, that's what these guys have done with Flash. It's GPLed. It's on Google, in Google's code base is this - this work is being developed. They don't have a complete interpretation of Shockwave Flash at this point. They've got a large body of it done. But it literally discards the original file. So if you want to - it's available as an installation. At this point I'm not recommending people use it. I think it's too immature. But it works with, it integrates with NoScript running on Firefox.
LEO: Really. Oh, that's neat.
STEVE: And so the idea is that, if you ran some Flash, that Flash never hits the actual Adobe interpreter. This thing gets it first and breaks it down into what the Flash is supposed to do, and essentially understands what it's supposed to do, discards that file, the original file completely, and then recompiles a new Flash file from that intermediate description, which is then what the Flash interpreter runs. And so you are, in the same way that I described with Internet packets, you're protected because somebody in between said, okay, this is what this is supposed to do. And this rebuilder essentially, well, you're not using the original file. So tricks like buffer overruns and things that are depending upon particular characteristics of the interpreter to be breakable, end up not making it through sort of this purifying process. So it's an interesting notion. And I'll bet we see things like this in the future because it's a very powerful concept.
LEO: Very cool.
STEVE: Somewhere, I think it was on one of the TWiT shows that I was listening to, I heard some guest ranting about - might have been Paul, actually - about reflection from the iPad. In fact, I think it was Paul. I think Paul Thurrott was saying he's on a plane, and the only thing he can ever see in his iPad is his own face.
LEO: Yeah. It's glass. It's a very reflective surface. As you can see, I'm reflecting our lights right back at you. It's very reflective.
STEVE: And so I just wanted to make another pitch for this iLuv anti-glare film. I have it on both of my iPads. Every iPad owner who sees it says, oh my god, where did you get that iPad? I say, no, no, it's the same iPad. If I peel this back, you'll see yourself looking at yourself. But, I mean, it is a pain to get on because it's one thing to, like, put an anti-glare film on something the size of a phone.
STEVE: It's much more difficult, I mean, it is really difficult. And the stuff's not inexpensive, and you'll probably go through some getting it on right. The iLuv anti-glare, you get two per package.
LEO: Oh, it's not - so it's not a sheet that goes over it?
STEVE: Oh, yeah, it is.
LEO: Oh, it is. Okay, just but getting it right is hard to do.
STEVE: Well, first of all, you've got to get the surface clean. Then the problem is peeling the backing off of the anti-glare film, inherently, you're, like, peeling it apart. That generates static electricity. So then every bit of dust in the neighborhood comes rushing to it. I mean, it really is a pain. And then you've got this big sheet which you have to get exactly aligned correctly. I realize I'm not selling this very well, but I'm wanting to caution people. I mean, it is such a mixed blessing. But the upside is, if you can get it done, oh, it's unbelievably good.
I mean, it's the biggest mistake Apple made, I think, is this high-gloss mirror-finish glass on the iPad. I know that's what Apple likes. Yes, it's sharper and crisper and more wonderful. But boy, it's annoying. When I look at somebody else's iPad - oh, and also, of course, everybody else's iPad just looks like they're finger-painting with their body grease all over it. And so the anti-glare really does a good job of hiding fingerprints, as well. I just can't recommend it highly enough. I wanted just to get it out into the ether after listening to Paul ranting about how tired he is about, I mean, he was really ranting about it. I thought, okay, I've just got to say this anti-glare film really does work, and it is really wonderful once it's in place. And then you never have to worry about it again. Getting it down right is a real pain, but it's possible. I've done it several times.
LEO: i-L-u-v; right?
STEVE: And Amazon sells it. i-Luv.com sells it. I think it's i-Luv.com. But Amazon also sells it. And it's less than 20 bucks, I think, for two sheets. And you'll need two because the first one will be a learning experience. But it just - it does work. I'm here to tell you.
LEO: Good to know, yeah. I'm ordering it right now.
STEVE: Good. I think it's worth trying, Leo. It really makes a difference. I had a fun story, just because the guy's a little bit over the top. Greg Scheeler says, “Well, I can't believe it. I'm now one of the masses contacting you to tell you what a great product you have,” speaking in this case of SpinRite. He said, “Here's the story. I had an upset co-worker. Her home PC would no longer boot Windows XP after a power outage. I offered to help. After identifying the point of failure during boot-up, I realized that something was wrong with the hard drive. I thought about moving the drive to another PC so that I could check it out, but I didn't have a PC available with the correct connections. And, frankly, I was trying to avoid spending $89 for your product.”
LEO: I don't believe that.
STEVE: “I finally gave in. There was nothing else to do. I purchased SpinRite 6, not really convinced that it would make any difference. I thought I had just wasted $89. I let SpinRite run overnight. In the morning I rebooted the PC, and it came right up into Windows. I'm a convert. I realized that I just can't be without this tool, in my side business which is PC repair/web design, in my toolbox. I'm now saving up to get the site license. Great job, Steve. Greg.”
LEO: Very nice.
STEVE: And Greg, thank you very much.
LEO: All right, Steve. DNS rebinding. What's the story here?
STEVE: Okay. So the problem has been understood for quite a while. We need to step back a little bit and talk about what's called “same-origin policy,” which is sort of a fancy word for “same-site policy.” So you can think of same-site policy as what this is really about.
So they said, okay, how do we constrain the script so that it's not going to get up to any other mischief? And they said, well, let's let the script only deal with the same site, that is, the site that it came from is the only server domain name that it's able to access. And so this notion of same-origin policy, that is, the origin where the script originated, the origin of the script is a constraint that all browsers since then have imposed. Some of them do it to different degrees. And different resources have different degrees, sort of like levels of enforcement.