Vulnerabilities

Microsoft Patched; Firefox’s Turn

By Rich

While Microsoft releases patches for various vulnerabilities, including the two active zero day attacks, Firefox is being actively exploited.

According to the Mozilla Security Blog, there is a flaw in how Firefox handles JavaScript. We suggest you follow the instructions in that post to mitigate the flaw until they release a patch (which should be soon).

Not that we plan to post every time some piece of software is exploited or patched, but this series seems to... bring some balance to the Force.

–Rich

The Government Must Save Our Children from Apple!

By Macalope

Editors Note: This morning I awoke in my well-secured hotel room to find a sticky note on my laptop that said, “The Securosis site is now under my control. Do not attempt to remove me our you will suffer my wrath. Best regards, The Macalope.”

ComputerWorld has published an interesting opinion piece from Ira Winkler entitled “Man selling book writes incendiary Mac troll bait”.

Oh, wait, that’s not the title! Ha-ha! That would be silly! What with it being so overly frank.

No, the title is “It’s time for the FTC to investigate Mac security”.

You might be confused about the clumsy phrasing because the FTC, of course, doesn’t investigate computer security, it investigates the veracity of advertising claims.  What Winkler believes the FTC should investigate is whether Apple is violating trade laws by claiming in its commercials that Macs are less affected by viruses than Windows.

Apple gives people the false impression that they don’t have to worry about security if they use a Mac.

Really? The ads don’t say Macs are invulnerable. They say that Macs don’t have the same problem with exploits that Windows has.  And it’s been the Macalope’s experience that people get that.  The switchers he’s come into contact with seem to know exactly the score: more people use Windows so malicious coders have, to date, almost exclusively targeted Windows.

Some people—many of them security professionals like WInkler—find this simple fact unfair.  Sadly, life isn’t fair.

Well, “sadly” for Windows users. Not so much for Mac users.  We’re kind of enjoying it.

And perhaps because the company is invested in fostering that impression, Apple is grossly negligent in fixing problems. The proof-of-concept code in this case is proof that Apple has not provided a fix for a vulnerability that was identified six months ago. There is no excuse for that.

On this point, the Macalope and Winkler are in agreement. There is no excuse for that.  The horny one thinks the company has been too lax on implementing a serious security policy and was one of many Mac bloggers to take the company to task for laughing off shipping infected iPods.  He’s hopeful the recent hire of security architect Ivan Krstic signals a new era for the company.

But let’s get back to Winkler’s call for an FTC investigation. Because that’s funnier.

The current Mac commercials specifically imply that Windows PCs are vulnerable to viruses and Macs are not.

Actually, no. What they say is that Windows PCs are plagued by viruses and Macs are not.

I can’t disagree that PCs are frequent victims of viruses and other attacks…

Ah, so we agree!

...but so are Macs.

Oops, no we don’t.

The Macalope would really love to have seen a citation here because it would have been hilarious.

In fact, the first viruses targeted Macs.

So “frequent” in terms of the Mac here is more on a geologic time scale. Got it.

Apple itself recommended in December 2008 that users buy antivirus software. It quickly recanted that statement, though, presumably for marketing purposes.

OK, let’s set the story straight here because Winkler’s version reads like something from alt.microsoft.fanfic.net.  The document in question was a minor technical note created in June of 2007 that got updated in December.  The company did not “recant” the statement, it pulled the note after it got picked up by the BBC, the Washington Post and CNet as some kind of shocking double-faced technology industry scandal.

By the way, did you know that Apple also markets Macs as easier to use, yet continues to sell books on how to use Macs in its stores? It’s true! But if it’s so easy to use, why all the books, Apple? Why? All? The? Books?

A ZDNet summary of 2007 vulnerabilities showed that there were five times more vulnerabilities for Mac OS than for all types of Windows PC operating systems.

No citation, but the Macalope knows what he’s talking about. He’s talking about this summary by George Ou.  George loved to drag these stats out because they always made Apple look worse than Microsoft. But he neglected to mention the many problems with this comparison, most importantly that Secunia, the source of the data, expressly counseled against using it to compare the relative security of the products listed because they’re tracked differently.

But buy Winkler’s book! The Macalope’s sure the rigor of the research in them is better than in this piece!

How can Apple get away with this blatant disregard for security?

How can Computerworld get away with printing unsourced accusations that were debunked a year and a half ago?

Its advertising claims seem comparable to an automobile manufacturer implying that its cars are completely safe and its competitors’ cars are death traps, when we all know that all cars are inherently unsafe.

That’s a really lousy analogy. But to work with it, it’s not that Apple’s saying its car is safer, it’s saying the roads in Macland are safer. Get out of that heavy city traffic and into the countryside.

The mainstream press really doesn’t cover Mac vulnerabilities…

The real mainstream press doesn’t cover vulnerabilities for any operating system. It covers attacks (even lame Mac attacks). The technology press, on the other hand, loves to cover Mac vulnerabilities, despite Winkler’s claim to the contrary, even though exploits of those vulnerabilities have never amounted to much.

When I made a TV appearance to talk about the Conficker worm, I mentioned that there were five new Mac vulnerabilities announced the day before. Several people e-mailed the station to say that I was lying, since they had never heard of Macs having any problems. (By the way, the technical press isn’t much better in covering Mac vulnerabilities.)

So, let’s get this straight. Winkler gets on TV and talks up Mac vulnerabilities in a segment about a Windows attack. But because he got five mean emails, the story we’re supposed to get is about how the coverage is all pro-Apple?  Were the five emails from TV news anchors or something?

And just to be clear, it is not that Apple’s software has security vulnerabilities that is the problem; all commercial software does. The problem is that Apple is grossly misleading people to believe otherwise.

Wow, there is an awful lot of loose talk about how badly Apple is misleading the public with its wild claims. It’s somewhat surprising that Winkler doesn’t get around to actually quoting any of those very dangerous claims that the FTC should immediately investigate.

The Macalope thought about going back and pulling the quotes from the commercials and showing how all they actually do is say the Mac simply doesn’t have the virus problems Windows does (true!), but then he thought, hey, Winkler’s the one making the accusations. Why shouldn’t he be forced to back them up?

But buy Winkler’s book! The Macalope’s sure it’s awesome.

Winkler’s right that all commercial software has vulnerabilities.  And Vista actually better implements technologies designed to make writing exploits harder. He’s also right that there’s been much to criticize Apple about over security.  But the mildly honest parts of Winkler’s piece conflate vulnerabilities and exploits in an effort to make the Mac look worse and the dishonest parts are just utter fabrications (e.g. Macs are “frequently” hit by viruses).

An FTC investigation?  That’s just standing on the diving board and jumping up and down yelling “Look at me! Look at me! Hey, everyone, look what I can do!”

If Winkler had a serious argument about there needing to be an FTC investigation, he would have linked to the FTC’s guidelines for the substance of advertising claims and contrasted them with quotes from Apple’s ads. But he didn’t do that.

Because he doesn’t have a serious argument to make.

But buy his book!

This post thanks to www.macalope.com

–Macalope

Using a Mac? Turn Off Java in Your Browser

By Rich

One of the great things about Macs is how they leverage a ton of Open Source and other freely available third-party software. Rather than running out and having to install all this stuff yourself, it's built right into the operating system.

But from a security perspective, Apple's handling of these tools tends to lead to some problems. On a fairly consistent basis we see security vulnerabilities patched in these programs, but Apple doesn't include the fixes for days, weeks, or even months. We've seen it in Apache, Samba (Windows file sharing), Safari (WebKit), DNS, and, now, Java. (Apple isn't the only vendor facing this challenge, as recently demonstrated by Google Chrome being vulnerable to the same WebKit vulnerability used against Safari in the Pwn2Own contest). When a vulnerability is patched on one platform it becomes public, and is instantly an 0day on every unpatched platform.

As detailed by Landon Fuller, Java on OS X is vulnerable to a 5 month old flaw that's been patched in other systems:

CVE-2008-5353 allows malicious code to escape the Java sandbox and run arbitrary commands with the permissions of the executing user. This may result in untrusted Java applets executing arbitrary code merely by visiting a web page hosting the applet. The issue is trivially exploitable.

Landon proves his point with proof of concept code linked to his post.

Thus browsing to a malicious site allows an attacker to run anything as the current user, which, even if you aren't admin, is still a heck of a lot.

You can easily disable Java in your browser under the Content tab in Firefox, or the Security tab in Safari.

I'm writing it up in a little more detail for TidBITS, and will link back here once that's published.

–Rich

There Are No Trusted Sites: Paris Hilton Edition

By Rich

While not on the scale of Amex or BusinessWeek, I just find this one amusing.

Paris Hilton's official website was hacked and is serving up a trojan (the malware kind, not what you'd expect from her*). From Network World:

The hack was discovered by security vendor ScanSafe, which said that Parishilton.com (note: this site is not safe to visit as of press time) had apparently been compromised since Friday. Visitors to the site are presented with a pop-up window urging them to download software in order to enhance their viewing of the site. Whether they click "yes" or "no" on this window, the site then tries to download a malicious program, known as Trojan-Spy.Zbot.YETH, from another Web site.

The best part? Only 12 of 37 tested AV vendors catch the trojan. All of you that give me crap for hammering on AV can go away now.

• sorry, couldn't help myself there.

–Rich

What Regular Users Need To Know About The SSL/Root Certificate Authority Exploit

By Rich

Update: Verisign already closed the hole.

This morning (in the US- afternoon in Europe), a team of security researchers revealed that they are in possession of a forged Certificate Authority digital certificate that pretty much breaks the whole idea of a trusted website. It allows them to create a fake SSL certificate that your browser will accept for any website.

The short summary is that this isn't something you need to worry about as an individual, there isn't anything you can do about it, and the odds are extremely high that the hole will be closed before any bad guys can take advantage of it.

Now for some details and analysis, based on the information they've published. Before digging in, if you know what an MD5 hash collision is you really don't need to be reading this post and should go look at the original research yourself. Seriously, we're not half as smart as the guys who figured this out. Hell, we probably aren't smart enough to scrape poop off their shoes (okay, maybe Adrian is, since he has an engineering degree, but all I have is a history one with a smidgen of molecular bio).

This seriously impressive research was released today at the Chaos Computer Congress conference. The team, consisting of Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Anne Osvik, and Berne de Weger took advantages of known flaws in the MD5 hash algorithm and combined it with new research (and an array of 200 Sony Playstation 3s) to create a forged certificate all web browsers would trust. Here are the important things you need to know (and seriously, read their paper):

• All digital certificates use a cryptographic technique known as a hash function as part of the signature to validate the certificate. Most certificates just 'prove' a website is who they say they are. Some special certificates are used to sign those regular certificates and prove they are valid (known as a Certificate Authority, or CA). There is a small group of CAs which are trusted by web browsers, and any certificate they issue is in turn trusted. That's why when you go to your bank, the little lock icon appears in your browser and you don't get any alerts. Other CAs can issue certificates (heck, we do it), but they aren't "trusted", and your browser will alert you that something fishy might be going on.
• One of the algorithms used for this hash function is called MD5, and it's been broken since 2004. The role of a hash function is to take a block of information, then produce a shorter string characters (bits) that identifies the original block. We use this to prove that the original wasn't modified- if we have the text, and we have the MD5 results, we can recalculate the MD5 from the original and it should produce exactly the same result, which must match the hash we got. If someone changes even a single character in the original, the hash we calculate will be completely different from the one we got to check against. Without going into detail, we rely on these hash functions in digital certificates to prove that the text we read in them (particularly the website address and company name) hasn't been changed and can be trusted. That way a bad guy can't take a good certificate and just change a few fields to say whatever they want.
• But MD5 has some problems that we've known about for a while, and it's possible to create "collisions". A collision is when two sources have the exact same MD5 hash. All hash algorithms can have collisions (if they were really 1:1, they would be as long as the original and have no purpose), but it's the job of cryptographers to make collisions very rare, and ideally make it effectively impossible to force a collision. If a bad guy could force an MD5 hash collision between a real cert and their a fake, we would have no way to tell the real from the forgery. Research from 2004 and then in 2007 showed this is possible with MD5, and everyone was advised to stop using MD5 as a result.
• Even with that research, forging an MD5-based digital certificate for a CA hadn't ever been done, and was considered very complex, if not impossible. Until now. The research team developed new techniques and actually forged a certificate for RapidSSL, which is owned by Verisign. They took advantage of a series of mistakes by RapidSSL/Verisign and can now fake a trusted certificate for any website on the planet, by signing it with their rogue CA certificate (which carries an assurance of trustworthiness from RapidSSL, and thus indirectly from Verisign).
• RapidSSL is one of 6 root CAs that the research team identified as still using MD5. RapidSSL also uses an automatic system with predictable serial numbers and timing, two fields the researchers needed to control for their method to work. Without these three elements (MD5, serial number, and timing) they wouldn't be able to create their certificate.
• They managed to purchase a legitimate certificate from RapidSSL/Verisign with exactly the information they needed to use the contents to create their own, fake, trusted Certificate Authority certificate they can then use to create forged certificates for any website. They used some serious math, new techniques, and a special array of 200 Sony PS3s to create their rogue certificate.
• Since browsers will trust any certificate signed by a trusted CA, this means the researchers can create fake certificates for any site, no matter who originally issued the certificate for that site.
• But don't worry- the researchers took a series of safety precautions, one being that they set their certificate to expire in 2004- meaning that unless you set the clock back on your computer, you'll still get a security alert for any certificate they sign (and they are keeping it secret in the first place).
• All the Certificate Authorities and web browser companies are now aware of the problem. All they need to do is stop using MD5 (which only a few still were in the first place). RapidSSL only needs to change to using random serial numbers to stop this specific technique.

Thus at this point, your risk is essentially 0, unless Verisign (and the other CAs using MD5) are really stupid and don't switch over to a different hash algorithm quickly. We are at greater risk of someone like Comodo issuing a bad certificate without all the pesky math.

Nothing to worry about, and hopefully the CAs will avoid SHA1- another hash algorithm that cryptographers believe is prone to collisions.

And I really have to close this out with one final fact:

Chuck Norris collides hash values with his steely stare and power of will.

Update: Yes, if the researchers turn bad or lose control of their rogue cert, we could all be in serious trouble. Or if bad guys replicate this before the CAs fix the hole. I'm qualitatively rating the risk of either event as low, but either is within the realm of possibility.

–Rich

There Are No Trusted SItes: AMEX Edition

By Rich

Remember our first post that there are no trusted sites? Followed by our second one? Now I suppose it's time to start naming names in the post titles, since this seems to be a popular trend.

American Express is our latest winner. From Dark Reading:

Researchers have been reporting vulnerabilities on the Amex site since April, when the first of several cross-site scripting (XSS) flaws was reported. However, researcher Russell McRee caused a stir again just a week ago when he reported newly discovered XSS vulnerabilities on the Amex site. The vulnerability, which is caused by an input validation deficiency in a get request, can be exploited to harvest session cookies and inject iFrames, exposing Amex site users to a variety of attacks, including identity theft, researchers say. McRee was tipped off to the problem when the Amex site prompted him to shorten his password -- an unusual request in today's security environment, where strong passwords are usually encouraged. ... McRee says American Express did not respond to his warnings about the vulnerability. However, in a report issued by The Register on Friday, at least two researchers said they found evidence that American Express had attempted to fix the flaw -- and failed. "They did not address the problem," says Joshua Abraham, a Web security consultant for Rapid7, a security research firm. "They addressed an instance of the problem. You want to look at the whole application and say, 'Where could similar issues exist?'"

No, we don't intend on posting every one of these we hear about, but some of the bigger ones serve as nice reminders that there really isn't any such thing as a "safe" website.

–Rich

Stop Using Internet Explorer 7 (For Now), Or Deploy Workarounds

By Rich

There is an unpatched vulnerability for Internet Explorer 7 being actively exploited in the wild. The details are public, so any bad guy can take advantage of this. It's a heap overflow in the XML parser, for you geeks out there. It affects all current versions of Windows.

Microsoft issued an advisory with workarounds that prevent exploitation:

1. Set Internet and Local intranet security zone settings to "High" to prompt before running ActiveX Controls and Active Scripting in these zones.
2. Configure Internet Explorer to prompt before running Active Scripting or to disable Active Scripting in the Internet and Local intranet security zone.
3. Enable DEP for Internet Explorer 7.
4. Use ACL to disable OLEDB32.DLL.
5. Unregister OLEDB32.DLL.
6. Disable Data Binding support in Internet Explorer 8.

–Rich

Politics And Protocols

By Rich

Catching up from last week I saw this article in Techworld (from NetworkWorld) about an IETF meeting to discuss the impact of Dan Kaminsky's DNS exploit and potential strategies for hardening DNS.

The election season may be over, but it's good to see politics still hard at work:

One option is for the IETF to do nothing about the Kaminsky bug. Some participants at the DNS Extensions working group meeting this week referred to all of the proposals as a "hack" and argued against spending time developing one of them into a standard because it could delay DNSSEC deployment. Other participants said it was irresponsible for the IETF to do nothing about the Kaminsky bug because large sections of the DNS will never deploy DNSSEC. "We can do the hack and it might work in the short term, but when DNSSEC gets widely used, we'll still be stuck with the hack," said IETF participant Scott Rose, a DNSSEC expert with the US National Institute for Standards and Technology (NIST).

Look, any change to DNS is huge and likely ugly, but it's disappointing that there seems to be a large contingent that wants to use this situation to push the DNSSEC agenda without exploring other options. DNSSEC is massive, complex, ugly, and prone to its own failures. You can read more about DNSSEC problems at this older series over at Matasano (Part 1, Part 2, site currently experiencing some problems, should be back soon).

The end of the article does offer some hope:

The co-chairs of the DNS Extensions working group said they hope to make a decision on whether to change the DNS protocols in light of the Kaminsky bug before the group's next meeting in March. " We want to avoid creating a long-term problem that is caused by a hasty decision," Sullivan said. "There are big reasons to be careful here. The DNS is a really old protocol and it is fundamental to the Internet. We're not talking about patching software. We're talking about patching a protocol. We want to make sure that whatever we do doesn't break the Internet."

Good- at least the chairs understand that rushing headlong into DNSSEC may not be the answer. We might end up there anyway, but let's make damn sure it's the right thing to do first.

–Rich

1 In 4 DNS Servers Still Vulnerable? More Like 4 in 4

By Rich

I was reading this article over at NetworkWorld today on a study by a commercial DNS vendor that concluded 1 in 4 DNS servers is still vulnerable to the big Kaminsky vulnerability.

The problem is, the number is more like 4 in 4.

The new attack method that Dan discovered is only slowed by the updates everyone installed, it isn't stopped. Now instead of taking seconds to minutes to compromise a DNS server, it can take hours.

Thus if you don't put compensating security in place, and you're a target worth hitting, the attacker will still succeed.

This is a case where IDS is your friend- you need to be watching for DNS traffic floods that will indicate you are under attack. There are also commercial DNS solutions you can use with active protections, but for some weird reason I hate the idea of paying for something that's free, reliable, and widely available.

On that note, I'm going to go listen to my XM Radio. The irony is not lost on me.

–Rich

Clickjacking Details, Analysis, and Advice

By Rich

Looks like the cat is out of the bag. Someone managed to figure out the details of clickjacking and released a proof of concept against Flash. With the information out in public, Jeremiah and Robert are free to discuss it.

I highly recommend you read Robert’s post, and I won’t try and replicate the content. Rather, I’d like to add a little analysis. As I’ll spell out later, this is a serious browser flaw (phishers will have a field day), but in the big picture of risk it’s only moderate.

1. Clickjacking allows someone to place an invisible link/button below your mouse as you browse a regular page. You think you’re clicking on a regular link, but really you are clicking someplace the attacker controls that’s hidden from you. Why is this important? Because it allows the attacker to force you to interact with something without your knowledge on a page other than the one you’ve been looking at. For example, they can hide a Flash application that follows your mouse around, and when you go to click a link it starts recording audio off your microphone. We have protections in browsers to prevent someone from automatically initiating certain actions. Also, many websites rely on you manually pressing buttons for actions like transferring large sums of money out of your bank account.
2. There are two sides to look at this exploitation- user and website owner. As a user, if you visit a malicious site (either a bad guy site, or a regular site that’s been hit with cross site scripting), the attacker can force you to take a very large range of actions. Anytime you click something, the attacker can redirect that click to the destination of their choice in the context of you as a user. That’s the important part here- it’s like cross site request forgery (really, an enhancement of it) that not only gets you to click, but to execute actions as yourself. That’s why they can get you to approve Flash applications you might not normally allow, or to perform actions on other sites in the background. As with CSRF, if you are logged in someplace the attacker can now do whatever the heck they want as long as they know the XY coordinates of what they want you to click.
3. As a website owner, clickjacking destroys yet more browser trust. When designing web applications (which used to be my job) we often rely on site elements that require manual mouse clicks to submit forms and such. As Robert (Rsnake) explains in his post, with clickjacking an attacker can circumvent nonces (a random code added to every form so the website knows you clicked submit from that page, and didn’t just try to submit the form without visiting the page, a common attack technique).
4. Clickjacking can be used to do a lot of different things- launching Flash or CSRF are only the tip of the iceberg.
5. It relies heavily on iFrames, which are so pervasive we can’t just rip them out. Sure, I turn them off in my browser, but the economics prevent us from doing that on a wide scale (especially since all the advertisers- e.g. Google/Yahoo/MS, will likely fight it).
6. Clickjacking is very difficult to eliminate, although we can reduce its risk under certain circumstances. Because it doesn’t even rely on JavaScript and works with CSS/DHTML, it will take a lot of time, effort, and thought to eliminate. The fixes generally break other things.

After spending some time talking with Robert about it, I’d rate clickjacking as a serious web browser issue (it isn’t quite a traditional vulnerability), but only a moderate risk overall. It will be especially useful for phishers who draw unsuspecting users to their sites, or when they XSS a trusted site (which seems to be happening WAY too often).

Here’s how to reduce your risk as a user:

1. Use Firefox/NoScript and check the setting to restrict iFrames.
2. Don’t stay logged in to sensitive sites if you are browsing around (e.g., your bank, Amazon, etc.). Use something like 1Password or RoboForm to make your life easier when you have to enter passwords.
3. Use different browsers for different things, as I wrote about here. At a minimum, dedicate one browser just for your bank.

As a website operator, you can also reduce risks:

1. Use iFrame busting code as much as possible (yes, that’s a tall order).
2. For major transactions, require user interaction other than a click. For example, my bank always requires a PIN no matter what. An attacker may control my click, but can’t force that PIN entry.
3. Mangle/generate URLs. If the URL varies per transaction, the attacker won’t necessarily be able to force a click on that page.

Robert lays it out:

From an attacker"s perspective the most important thing is that a) they know where to click and b) they know the URL of the page they want you to click, in the case of cross domain access. So if either one of these two requirements aren"t met, the attack falls down. Frame busting code is the best defense if you run web-servers, if it works (and in our tests it doesn't always work). I should note some people have mentioned security=restricted as a way to break frame busting code, and that is true, although it also fails to send cookies, which might break any significant attacks against most sites that check credentials.

Robert and Jeremiah have been very clear that this is bad, but not world-ending. They never meant for it to get so hyped, but Adobe's last-minute request to not release caught them off guard. I spent some time talking with Robert about this in private and kept feeling like I was falling down the rabbit hole- every time I tried to think of an easy fix, there was another problem or potential consequence, in large part because we rely on the same mechanisms as clickjacking for normal website usability.

–Rich

Why The TCP Attack Is Likely Bad, But Not That Bad

By Rich

There's been a bunch of new information coming out the past few days about the potential big TCP denial of service flaw. The three most informative posts I've read are:

1. Fyodor's discussion of either the same, or a similar issue.
2. Richard Bejtlich's overview.
3. Rob Graham's take on the potential attack.

Here's what I think you need to know:

1. It is almost certainly real.
2. Using this technique, and attacker with very few resources can lock up the TCP stack of the target system, potentially draining other resources, and maybe even forcing a reboot (which could trash the host OS).
3. Anything that accepts TCP connections is vulnerable. I believe that means passive sniffing/routing is safe.
4. The attack is obvious and traceable. Since we are using TCP and creating open connections (not UDP) it means spoofing/anonymous attacks don't seem possible.
5. Thus, I'd be more worried about a botnet that floods your upstream provider than this targeted attack.
6. This is the kind of thing we should be able to filter, once our defenses are updated.

In other words- a bad attack, but a moderate risk. That said, there are aspects of this that still concern me and we need to keep in mind:

1. We don't know if our assumptions are correct. This could be a different, and much more serious, technique. Such as something spoofable. Unlikely, but possible.
2. Nothing says a botnet can't use this- and thus make filtering and tracing a real pain. Imagine a botnet rotating this attack technique around to different nodes. It could support more efficient botnet attacks, that could then drop to regular flood mode if it doesn't think the more efficient direct mode is working.
3. We don't know it doesn't do something to the router infrastructure or passive monitoring. Again, unlikely based on the information released, but I'd hate to dismiss this as concerning until we know more.
4. Until there's some sort of fix, the Defcon network and coffee shops near universities are really going to suck.
5. Until this is fixed, small businesses and individuals are the most likely to suffer. An enterprise might be able to detect and drop an attack like this, but individual users and small business don't have the resources. Get ready for vendor pouncing.

–Rich

Massive TCP Flaw Looming

By Rich

Yesterday, following up after recording the podcast on clickjacking, I was talking with Robert Hansen about the TCP flaw some contacts of his found over in Sweden. He wrote it up in his column on Dark Reading, and Dennis Fisher over at TechTarget also has some information up.

Basically, it's massive unpatched denial of service attack that can take down nearly anything that uses TCP, in some cases forcing remote systems to reboot or potentially causing local damage. Codified in a tool called "Sockstress", Robert E. Lee and Jack C. Louis seem to be having trouble getting the infrastructure vendors to pay attention. I can't but help think it's because they are with a smaller company in Sweden; had this fallen into the hands of one of the major US vendors/labs methinks the alarm bells would be ringing a tad louder.

From what Robert told me, supported by the articles, this tool allows an attacker to basically take down anything they want from nearly anywhere (like a home connection).

Robert and Jack are trying to report and disclose responsibly, and I sure as heck hope the vendors are listening. Now might be the time for you big end users to start asking them questions about this. It's hard to block an attack when it takes down your firewall, IPS, and the routers connecting everything.

One interesting tidbit- since this is in TCP, it also affects IPv6.

–Rich

PDF Security Pain: We Told You So

By Rich

Thanks to Slashdot, here's a story on Adobe PDF vulnerabilities:

The Portable Document Format (PDF) is one of the file formats of choice commonly used in today"s enterprises, since it's widely deployed across different operating systems. But on a down-side this format has also known vulnerabilites which are exploited in the wild.

I normally ignore stories coming out of vendor labs on new exploits that are coincidentally blocked by said vendor's products, but on occasion they highlight something of interest.

Back in February I mentioned three applications that are a real pain in our security behinds- IE/ActiveX, QuickTime, and Adobe Acrobat (the entire pdf format, to be honest). It's nice to see a little validation. Each of these, in their own way, allows expansion of their formats.

In the Adobe case they keep shoveling all sorts of media types and scripting into the format. This creates intense complexity that, more often than not, leads to security vulnerabilities. When you manage an open format, content validation/sanitization is an extremely nasty problem. Unless you design your code for it from the ground up, it's nearly impossible to keep up and lock down a secure format. I suspect Adobe's only real option at this point is to start failing with grace and focus on anti-exploitation and sandboxing (if that's even possible, I'll leave it up to smarter people than me).

Truth is I should have also put Flash on the list. My bad.

–Rich

Reminder- There Are No Trusted Sites

By Rich

Just a short, friendly reminder that there is no such thing as a trusted website anymore, as demonstrated by BusinessWeek.

We continue to see trusted websites breached, and rather than leaving a little graffiti on the site the attackers now use that as a platform to attack browsers. It's one reason I use FireFox with NoScript and only enable the absolute minimum to get a site running.

–Rich

New Poll (And Article) At Dark Reading

By Rich

Thanks to the unorthodox release of the DNS bug, there’s been a lot of debate in the past few weeks over disclosure. I posed a question here on the blog, and reading through the responses it became obvious that all of us base our positions on gut instinct, not empirical evidence. Andrew Jaquith, in the comments, suggested we take a more scientific approach to the problem, and this inspired my latest Dark Reading article, and a poll. Here’s an excerpt:

Sure, we all have plenty of anecdotal evidence to support our personal positions. We can all cite cases of this or that vendor tirelessly defending its customers, or putting them at mortal risk based on their handling of some vulnerability. We all know someone that suffered real losses at the hands of the latest random Metasploit exploit module, and someone else who used it to close critical holes in their security defenses before the bad guys made it in. We all talk about Blaster, Code Red, and other past incidents like they have any relevance in today’s world, which we all also admit has changed completely from a few years ago. There’s a word for picking and choosing examples to support a pre-existing belief without any scientific basis. It’s called religion. I propose that it’s long past time we brought some current science into the game. It’s time to move past anecdotal evidence or one-off cases into wider-ranging realm of epidemiological studies. It’s time to ask the users what they want, while developing risk metrics to allow them to make informed decisions despite their personal opinions. We may not reach definitive conclusions, and even if we do, they probably won’t last nor change the minds of the truly religious. But it’s always better to seek more data than to dismiss it before we even see it.

As a small first step, we attached a poll to the article to measure how different demographic groups, users, researchers/testers, and vendors, feel about disclosure. It’s not truly scientific, both due to the wording of the question and the self-bias of the readers, but I’ll always error more on the side of more data over less.

So take the poll, and we’ll get the results up in a couple of weeks. Until then, see ya at Black Hat and DefCon!

–Rich