Security Now! - Episode 221
SERIES: Security Now!
DATE: November 5, 2009
SPEAKERS: Steve Gibson & Leo Laporte
GUEST: John Graham-Cumming
SOURCE FILE: http://media.GRC.com/sn/SN-221.mp3
FILE ARCHIVE: http://www.GRC.com/securitynow.htm
LEO LAPORTE: It's time for Security Now!, the show that covers all things secure and private and important, like that. With us right now, the king of security, Mr. Steve Gibson from GRC.com. Hello, Steve.
STEVE GIBSON: Hey, Leo. Great to be back with you again for our 221st episode of Security Now!.
LEO: Unbelievable. We have a good show this week, too.
LEO: Hmm. This is right after your own heart, isn't it.
LEO: Well, we're going to get him on in just a minute. I'm sure there's some security news in the hopper. So, Steve, what's been happening in the week since we talked last?
LEO: Of course, what else.
STEVE: Of course. There's a heap buffer overflow, remember we talked about it, in the GIF color image map parser. In this case the security research firm iDefense reported a heap-based buffer overflow in Mozilla's GIF image parser. This vulnerability could potentially be used by an attacker to crash a victim's browser and run arbitrary code on their computer.
Three to go. Download filename spoofing with RTL, that's right-to-left override. Mozilla security researchers Jesse Ruderman and Sid Stamm reported that when downloading a file containing a right-to-left override character in the filename, the name displayed in the dialogue title bar conflicts with the name of the file shown in the dialogue body. An attacker could use this vulnerability to obfuscate the name and file extension of a file to be downloaded and opened, potentially causing a user to run an executable file when they expected to open a non-executable file. So that could kind of catch out people who think they're more savvy and professional and know what's going on, like checking the filenames. Except whoops, due to the way this is handled, it's possible to obfuscate the actual name of the file that you're downloading.
Number nine, we talked about the media libraries being upgraded. It was called an upgrade, the media libraries, to fix memory safety bugs. Mozilla upgraded several third-party libraries used in media rendering to address multiple memory safety and stability bugs identified by members of the Mozilla community. Some of the bugs discovered could potentially be used by an attacker to crash a victim's browser and execute arbitrary code on their computer. The liboggz, libvorbis, and liboggplay libraries were all upgraded to address these issues. And then on the Mozilla site it said, “Note: Audio and video capabilities were added in Firefox 3.5.” So prior releases of Firefox, such as 3.0, were not affected.
LEO: Although as we've seen, everything old has problems, too. It's not like, I mean, it's not - they're just a new set of problems.
STEVE: Yes. Well, okay, yes.
LEO: I mean, it's not like old code is somehow magically better code.
STEVE: I would disagree, Leo. I think older code is better code. Older code has had this kind of stuff pounded out of it. But what we need is…
LEO: Well, that's the question, is does it get pounded out, or does it just get pounded? I mean, you can't say XP is safer because it's had many, many, many, many patches. Because we keep finding holes in it.
STEVE: Well, it's because people - no one leaves it alone. We're still - it's not a static operating system. Microsoft keeps messing with it. 98 is old, but solid, and isn't prone to being affected now. I really do believe older code is better code than new code. However, it's got to be old code that you leave alone, that you don't keep messing with. And so XP continues to be brought forward because Microsoft's supporting it, and features that are being added in Vista and Windows 7 are still being backported into XP, which is destabilizing it.
LEO: True. True, true, true.
STEVE: So it is significant, though. Relative to Firefox 3.0 and 3.5, I wanted to mention to people that Mozilla has formally stated they are not going to be continuing to support Firefox 3.0, the Firefox 3.0 series, after January of 2010. So only November and December, two more months of support for Firefox 3.0.
LEO: Really. That's all?
LEO: Wow. That's pretty quick.
STEVE: Yeah. That does strike me as being quick. I wanted to mention to people using the Opera browser to check for updates. They're now at version 10.01 with a bunch of vulnerabilities. I won't go into them in detail. But there's a set of vulnerabilities. They're publicly known and available. So if you're an Opera user you definitely want to make sure you stay current there.
And then one bizarre bit of news. I picked up on this on the Discovery Channel news. Their security editor, Eric Bland, on the 28th posted an article that just captured my imagination. The title was “[Digital 'Ants' Take on Computer Worms].” “Digital ants could soon be crawling through your computer's hard drive, but don't worry, they are there to help.” And, okay, this is just too fun.
“Scientists from Wake Forest University and the Pacific Northwest National Laboratory have created an army of digital ants and their superior officers, digital sergeants and sentinels, to search out viruses, worms and other malware. The new antivirus software could provide better protection while freeing up valuable hardware.
”'We are using the ants to sense something very basic, like a connection rate,' said Errin Fulp, a professor of computer science at Wake Forest University who helped develop the digital ants. 'Then we collect that evidence which points us to a particular infection or security threat,' said Fulp.
“Like their biological counterparts, each individual ant is not very bright. A connection rate, CPU utilization, or one of about 60 other technical details is all they can sense. When an ant detects something unusual, it leaves a digital pheromone, a tiny digital sense that says something” - oh, this is wacky.
LEO: This analogy's gone a little too far.
STEVE: “…a tiny digital sense that says something unusual is going on here, and that other ants should check it out. The digital ants report any suspicious activity to a digital sentinel, a program designed to watch over a set of computers in a network. The sentinel sorts through all the information the ants gather and, if it's suspicious, passes the information on to a digital sergeant. The sergeant then alerts the human supervisor, who can deal with the problem. The sentinels and sergeants reward the ants for finding problems. If an ant doesn't find enough problems, it 'dies' off, although a minimum number is always maintained.
“If a particular kind of ant finds lots of problems, then more of them are created to monitor the problem. The entire system is modeled off of a normal ant colony and uses 'swarm intelligence' to find and diagnose problems. The beauty of using digital ants, instead of a traditional antivirus program, is their flexibility. Traditional antivirus software usually scans constantly or on a set time schedule. Constantly scanning for threats is effective, but uses a lot of computer resources, resources that could be better spent doing something else.
“Scanning at certain times, usually at night, optimizes computer usage, but it leaves a computer more vulnerable [in the interim]. Since the number of ants rises and falls with number of problems being detected, it can free up computer hardware to perform calculations when an attack isn't happening. If an attack is happening, more ants can quickly be created to help deal with it.” So there you go, Leo.
LEO: Digital ants.
STEVE: We're going to have ants crawling around in our computers.
STEVE: And I have to say, all of this starts making my PDP-8 computer look…
LEO: Look better and better.
STEVE: …pretty good.
LEO: Hey, if you never get on the Internet, you'll never have a problem.
STEVE: That is, that is the case.
LEO: Well, maybe never. But you'll have fewer problems. What else we got before we - should I get John on, or do you want to cover some errata first?
STEVE: I'm not going to hold him up for long. I have a brief errata and a short little SpinRite story.
STEVE: My errata is titled “I hate Adobe.”
LEO: That's not an errata. That's a facta.
STEVE: Okay. Get this, Leo. I haven't had it happen a second time because I haven't used another machine. But Adobe's Flash updater, with no apparent ability for me to stop it, installed a demo of NaturalReader.
LEO: Oh, no, that's not right.
STEVE: Now, there was a checkbox. It also wanted to give me a free MacAfee security scan.
STEVE: And I said no, thank you. But then it says it's - I'm watching it update itself, and it says it's installing a demo of NaturalReader. Well, first of all, I own NaturalReader.
LEO: Oh, great.
STEVE: I use the voice for various things. So, and sure enough, on my desktop now - or was, I deleted it - but there didn't seem to be a way of uninstalling the demo. It didn't leave…
LEO: Oh, that's inexcusable.
STEVE: Didn't put something in the Add/Remove Programs. There was an icon it added to my desktop. When I clicked it, and I made sure this was all legit, it popped open. It was a web page that was running NaturalReader from my system. And it's like, okay, wait a minute. I mean, so this is nothing to do with Adobe Flash. And this thing is installing demoware that I couldn't see any way to avoid. I mean, this is really wrong. So…
LEO: What was the updater? Was it your Adobe Reader updater? I mean, what was…
STEVE: It was the…
LEO: The Flash updater?
STEVE: It was the Adobe Flash updater.
STEVE: And so I just, I wanted to put out a call. I'm sure if other listeners had this happen to them, drop me a note at GRC.com/feedback. Let me know if you saw the same thing. This is just - at this point it happened to me. I haven't seen anything more about it. But it's like, oh, if Adobe starts doing this, then this is really wrong.
LEO: Companies do tend to like to do stuff like that, just kind of auto-install software.
STEVE: I know.
LEO: Lately I've just made sure, you know, like very carefully when I'm installing software, especially free software, watching each window, say oh, no, I don't want the Yahoo! toolbar. No, I don't want the - uncheck, uncheck, uncheck.
STEVE: I know. And by default they're checked, and you've got to go in and manually say, no, thank you, I don't need another copy of Google Toolbar installed.
STEVE: Anyway, we did have a nice note from Martin. He said, “Hello, Steve and Leo.” So he addressed both of us. He says, “Not a great SpinRite story, but just a successful one.” He said, “My primary data print server started acting funny. So I thought a reboot was in order. Once the server turned back on, it sat and sat at the 'applying computer settings' screen. Uh-oh. A need for SpinRite. So I ran SpinRite at Level 2. It found two bad, unrecoverable sectors in the course of 30 hours. Following the completion of the scan, a successful reboot was performed, and the server works perfectly now. I've since reconfigured a new server for my data and printing. But without SpinRite, I would have had a really tough time pulling my data off the old machine. Like I said, just a plain SpinRite success story, a successful one. Thank you for a great product.”
LEO: That's not so plain. That's nice.
LEO: It's a good feeling. Let's get John on right now because he's been, poor guy, he's been waiting in the wings for half an hour now, and I want to call him. I think he's in Great Britain, which means it's also getting later and later at night.
LEO: So let's get him on. He's the author of “The Geek Atlas,” which I love. In fact, I will go get my copy of it to hold up as we talk to John. It's really a must-see. And he has a good website, too, which you can go to. It's, let's see, JGC.org. I'm just calling him up right now.
JOHN GRAHAM-CUMMING: All right.
LEO: There he is. Hey, John.
LEO: Welcome to the show, John.
JOHN: Now, do you see me all right?
LEO: I don't see you yet. But if you turn on your camera…
JOHN: Maybe if I press this video button…
LEO: It's a magic button there. There he is.
STEVE: And Leo, this is an authentic UK accent.
LEO: As opposed to my crappy fake one? Yes, it is. John, it's great to see you again. Welcome to the show.
JOHN: You actually sound like an evil villain in an American movie, trying to be British, when you do it.
LEO: Yeah, yeah. Not good, I know.
JOHN: Although somebody in the chatroom accuses me of sounding like an evil villain. And I do actually have a white Persian cat.
JOHN: Which I could bring onto…
STEVE: Uh-on. Long as it's not on your lap, stroking it.
JOHN: Not right this minute.
JOHN: Okay. What an introduction. So perhaps I should tell you just a little bit about this talk that I gave and the conference it was at because it sets the scene a little bit for what I was talking about, which is that this was given at the Virus Bulletin Conference in Geneva in September. And Virus Bulletin is typically about viruses, malware, worms, all the sorts of things that come out of the virus industry. It's a very hardcore conference. There is a commercial track in the conference where you get some sort of commercial discussions, but it's really about technology.
LEO: That's something you don't have to do here because that's pretty much what this show is all about.
JOHN: Yeah. And of course as a listener I'm well aware that…
LEO: It's about all we talk about.
LEO: Understandably. Me, too, now, I have to say.
JOHN: Well, you know, and to get things off to sort of a good start, the way in which I deal with it, just so everyone knows, is I use NoScript…
JOHN: …in Firefox.
LEO: As does Steve.
JOHN: So I whitelist the sites I really trust. And then when I come to something I don't trust, obviously it's off. And then if I need it, I'll do the “temporarily turn it on,” just so I can take a look around at what's needed on that particular site.
JOHN: No, I don't think you're crazy.
And then the other key thing was stop a malicious website interacting with another one. So you can't be on your bank's website, and then some other website suddenly is able to play with the bank's website and do a transfer or something. That one's still very, very important. That's a very important part. That's the cross-domain security which we can talk about.
STEVE: Well, and it's also…
JOHN: Yeah, go ahead.
STEVE: And so it…
STEVE: So if this was actually done and exploited, which I guess is what you're saying happened…
JOHN: Yeah, absolutely. I mean, this was done by some security researchers. And I'd have to find the exact reference to it. But it's pretty easy to define, though, because I know that Bruce Schneier talked about it. It's called “JSON hijacking.” And JSON is spelled J-S-O-N.
STEVE: Would you call them separate name spaces?
So, you know, there are proposals. I made a different proposal which is around signing scripts - and we can talk about that a little bit further on - which is to do with cross-site scripting, which is another big area. But this idea that all the scripts are running in the same context is scary and I think does need to get addressed. And I think there are some thinking - there is thinking around addressing it.
STEVE: And do scripts not stomp on each other then by mistake? Like, I mean…
JOHN: They can do.
STEVE: And is there any evidence at this point that this single-context environment is currently being used by some scripts to talk across to other scripts so that creating some separation would then break sites that had become dependent upon it?
JOHN: Yeah, it probably would. There are some examples in the web analytics world, particularly when you get in a situation where you upgrade to a new version where they make use of the fact they can read what the old version was up to and grab data out of it. So, you know, you've got the old tag and the new tag. And the new tag can say, oh, by the way, I can go grab that from this tag over there, because it knows it can get access to it. So, yeah, there is an upgrade issue for that. And it's certainly the case that inline scripts, i.e., ones that haven't been sourced from somewhere else, if you go and look at, you know, any large website, they are expecting to be in the same context. So you've got to, you know, you've got to be careful about how you do this. But I think it is, from a security perspective, something that needs to be worried about. Because it is, that combination is scary.
STEVE: What's your sense of how worried people are? I mean, are we the only people worrying about it? Or are, like, important people worrying about it?
JOHN: I think…
LEO: You guys are important, now, come on.
JOHN: No, I know, self-important.
STEVE: People who could actually do something.
LEO: Ah. That's different.
STEVE: What scripting does an ad need to run? I don't want ads running scripts.
JOHN: No, I realize you don't. You probably just want there to be…
STEVE: I mean, it's enough to put up with the ad itself.
STEVE: To invoke the Flash, right.
STEVE: Well, in my case, I was briefly using Google Analytics until I looked closely at what it was doing, and I realized that every time one of GRC's pages was being presented to anyone who visited GRC, the code which I had been asked by Google to tack onto the end of my page was going out and fetching a block of code on the fly that I had no chance to look at or understand. But it was - so basically my server was causing anything Google wanted to append to all of my pages to be included. And I just - I thought, well, I just can't have this. I mean, that's ridiculous.
JOHN: Well, and if you look at that TechCrunch example I gave, I mean, there's tens of them. And TechCrunch is basically in a trust situation. They say, well, we trust this code isn't doing anything malicious, and it probably isn't. And we also trust that nothing's ever going to go wrong with it. And you've just got no way of verifying it.
STEVE: Yeah, one of the things that all security experts know is, as bad as external security problems are, the great majority of actual exploitation or mistakes or, I mean, either by mistake or deliberate, occur internally. So all it would take would be somebody with some malicious intent at any one of these sources, for example, in the TechCrunch example, not to pick on them specifically because, as you said, many sites are pulling many scripts from many locations. But, I mean, it creates this multiplication of potential for problem. It would just take one insider job exploiter to change the script in some subtle way that would have a huge effect on the Internet, not just one site, but every site that pulled script from them.
JOHN: Right, exactly. Exactly. So that is a real worry, yes, definitely, that, you know - and I think in a way it can be quite easily dealt with by siloing. So if something bad happens, you know, it's contained, at least. Now, that would make an enormous difference. I think if we could then sign scripts, then that would make a big difference because then you, you know, you'd enter into some agreement and say, hey, you know, these guys signed it, and so that gives you another level of, you know, assurance that it's the right thing, the thing you were actually asking for.
STEVE: And are you suggesting that it be digitally signed so that it would have a certificate that would be checked before it was run? Or that then it would be agreed to, a certain script, and then they would not be able to change it without going through some sort of authentication process or authorization process.
STEVE: Yup, and then that - go ahead.
STEVE: Right. So it really, in the case of cross-site scripting, it really is a strange fluke of sort of the Web 3.0 approach where users are submitting content, that malicious users can submit script content which will be displayed and run by anyone who then views that content.
And there've been, you know, classic examples of this. The reddit one was interesting because it was a bug in their markdown implementation. There was a Ruby on Rails one to do with Unicode decoding, where they had this thing which tried to deal with Unicode, and they'd handwritten it themselves, and it turned out there were some bugs in it, and it was possible to create essentially bad Unicode that got decoded into ASCII with a script tag in it. So that, you know. And there's another great example which is to do with UTF-7, you know, Unicode type thing, which is if your website wasn't specifying that it was in, you know, UTF-8, UTF-16 or whatever, you could use UTF-7 characters and then stick in their metatags - and by the way, this is UTF-7, which would then promptly get decoded by the browser into a script tag, and off you go.
So there's loads of potential. I think Douglas Crockford calls this the turducken problem. You know that thing where they put a chicken inside a duck inside a turkey? You've got just layers and layers of different stuff. So, sorry, I'm getting too excited. Now I'm going to have to start coughing.
LEO: Stop talking about turduckens.
JOHN: Actually, to be honest with you, I think it's pretty good. There have been lots of bugs. But, you know, hey, what a surprise. It's certainly no Windows, let's put it that way. I mean, it's, you know, there are bugs, and you do see examples, if you look in the SANS database and things like that, of such and such a bug in the sandbox where we could get through and do cross-domain things or cross-security-domain things in IE. But, yeah, there are bugs. What a surprise. There was a nasty one in Google Chrome which the Mozilla guys found in, funnily enough, by actually inspecting their code. That was just a few weeks ago.
JOHN: But to be honest, the sandbox has been pretty good. The bigger problem is not the sandbox because, as I say, it's not breaking out of the sandbox is the problem. You can do plenty of damage within the sandbox.
JOHN: Yeah. And by the way, I've got nothing against us having a scripting engine in the machine. I think that's actually a very important part of where we're going with, you know, mobile code being able to be downloaded. And, you know, I'm very happy to use things like Gmail. I think it's fantastic.
LEO: Yeah, absolutely. You use Google Docs in your company. You can't do it without scripting.
LEO: Steve, I don't want to preempt, if you have some other questions before we get to John's recommendations.
STEVE: No, I think this is perfect. I'd love, I mean, I know my solution.
LEO: Well, it sounds like John uses the same solution. You both prefer to use NoScript. Is that right?
STEVE: Right. Right.
LEO: John, how do you use NoScript? You said you turn on full protection and then allow sites.
LEO: Nothing wrong with that.
LEO: That's why I don't use it.
JOHN: Yeah, no, I understand. I mean, so…
LEO: You need it, though, it sounds like.
JOHN: Yeah, I mean, I have an iPhone. And to be honest with you, I use it to access not very many different sites, so…
LEO: Stay off the web.
JOHN: No, I use it to stay on the web, of course, particularly for email and Twitter. But I don't find myself browsing around a lot on my iPhone.
LEO: For that reason.
But the idea that these more appalling security holes, I mean, the things that are in there really by design are being looked at and can be tightened up I think is tremendous good news. And I will tell everybody that, I mean, using NoScript is a burden. You go to a site and something doesn't seem right. It's not quite working. And so then it's like, okay, let's see if turning scripting on will make the form work correctly. And it always does.
STEVE: I don't have NoScript set to tell me when it's blocking something. That's really obnoxious because scripting is everywhere now. So all I do is, if I see that a site doesn't seem to be functioning right, I look down at the bottom, and there'll be like a little red slash through the “S,” saying I'm blocking stuff for you. And it's like, okay, fine. And so normally I temporarily allow scripting. You're able to do it just like for the session or to permanently whitelist, which is very nice. That way I don't have my whitelist growing forever. Because most sites that I'm randomly going to, I'm not coming back to. So I find that it really works for me. And I think for today it's the right balance between, you know, we have to have some scripting for sites that need it; yet you don't really just have to be running around completely naked on the 'Net all the time and allowing anyone to poke at your browser.
JOHN: The problem is with NoScript is that, you know, you have to be a pretty high-end user to be able to use it. And that's why, you know, my presentation, you mentioned this at the beginning, Steve, which is I said there's no viable way for my mother to control this. And that's why this is something that's got to be fixed technically to protect people from what's happening. It's good for people like us. But it's not a solution for the general web user at all. It drives me insane. And, you know.
LEO: Well, that's why I don't use it. But now I'm terrified.
STEVE: Ah, I meant to bring that up. Yes, yes, yes, I meant to bring that up. Yeah, talk about that, John.
LEO: This is that click fraud thing; right?
JOHN: Yes. The thing is…
STEVE: Well, yes. And for all kinds of, I mean, we talk about authentication a lot. And so it's really important to be able to, like for a server remotely to be able to know for sure that when it challenged the user, the user himself physically moved the cursor over a button and clicked on it, rather than the page happened to load some script from somewhere that did that on the user's behalf, for something really important where you really want to assure you actually have user focus and awareness and interaction. And with the model as it is now, you don't have that.
JOHN: Yeah. Yeah. So that's, you know, one of those things in, you can argue whether that's in the language or in the implementation of the language in the browser, but is a worrying thing if you're trying to understand, you know, what did a machine do and what did a person do.
LEO: Well, I hope that people are paying attention to this, and I hope that something gets done about it. We need it. It's a very powerful language.
STEVE: The important people. We hope the important people are paying attention.
LEO: Well, all it takes is for Google, for instance, although given the problems you talk about with Google Analytics, maybe there's no hope. But for Google or somebody, maybe Google could say, well, we're going to make Chrome enforce this. We're going to silo the data.
JOHN: Well, Google are the people behind the Caja - or Caha, depending on how you say that “j” - project. So there's definitely thinking in Google going on there about it. And I talk about Google Analytics just because of its incredible popularity. There's nothing inherently wrong with Google Analytics. I mean, it scares me that it's on so many sites. That's what worries me about it. I don't think Google's up to anything naughty.
JOHN: Yeah, it sure is. And it's just that's the biggest worry is that it lets us slap things together, and they're all running as the same priority, and that's a scary situation.
LEO: Is Caja as good a solution, do you think, as siloing or signing?
JOHN: No. I think if we had proper silo, you know, we could actually break things up into separate spaces and then…
LEO: We don't need to strip the language down, then.
JOHN: I think there's some merit in working, going down to a subset of the language which is known to be safe and sort of building back up again from there to try and avoid some of the scarier parts. I think that's a valid thing to do. But I think that, you know, just being able to sign things and know they are what you're expecting to get is very important.
STEVE: I mean, it's got nothing to do with Java at all.
LEO: Well, John, I'm so glad we could get you back on again. I do want to give a plug for your “Geek Atlas” because it's a great book from O'Reilly that covers 200, what 256 of the great geek…
LEO: 128, okay. Two to the…
JOHN: Yeah, here it is.
LEO: Here it is. Take a look at it. He's got it.
LEO: 2^7, not 2^8, yeah.
JOHN: If I can get it back in front of the camera. Here we go. And now, here's the big surprise. I just received this today.
LEO: Oh, but the book is upside down now. What, it's an updated…
JOHN: It's a German edition.
LEO: [Speaking German]
JOHN: Yeah, so he can speak German. So English or German, depending on what you like.
LEO: Well, that's great. Thank you, John. We really appreciate it.
STEVE: Thank you so much, John. It's great spending the time with you.
LEO: I've got to quickly go instead NoScript on all my machines.
JOHN: It's too late. I already infected them.
LEO: How many times have I said that before? But this time I'm going to really do it. You did finally scare me into it. And we'll see you next time on Security Now!.
LEO: Bye bye.
STEVE: Bye bye.
Copyright © 2009 by Steve Gibson and Leo Laporte. SOME RIGHTS RESERVED. This work is licensed for the good of the Internet Community under the Creative Commons License v2.5. See the following Web page for details: http://creativecommons.org/licenses/by-nc-sa/2.5/.