NIST is currently holding a competition to choose a design for the SHA-3 algorithm (Bruce Schneier has a good description of secure hashing algorithms and why this is important). The reference implementations of a few of the contestants have bugs in them that could cause crashes, performance problems, or security problems if they are used in their current state. Based on our bug reports, some of those bugs have already been fixed. Here's the full story:

The main idea behind the competition is to have the cryptographic community weed out the less secure algorithms and choose from the remainder. A couple of us at Fortify (thanks to Doug Held for his help) decided to do our part. We're not hard-core cryptographers, so we decided to take a look at the reference implementations.

This competition is to pick an algorithm, but all of the submissions had to include a C implementation, to demonstrate how it works and test the speed, which will be a factor in the final choice. We used Fortify SCA to audit the 42 projects accepted into Round 1. We were impressed with the overall quality of the code, but we did find significant issues in a few projects, including buffer overflows in two of the projects. We have emailed the submission teams with our findings and one team has already corrected their implementation.

Confirmed issues:

One of the projects with buffer issues was MD6, the implementation provided Professor Ron Rivest and his team. All of the problems came back to the hashval field of the md6_state struct:

     unsigned char hashval[ (md6_c/2)*(md6_w/8) ];

The buffer size is determined by two constants:

     #define w md6_w     /* # bits in a word                   (64) */      #define c md6_c     /* # words in compression output      (16) */

At several points, this buffer is read or written to using a different bound:

     if (z==1) /* save final chaining value in st->hashval */           { memcpy( st->hashval, C, md6_c*(w/8) );             return MD6_SUCCESS;           }

Further analysis showed that ANSI standard layout rules would make incorrect behavior unlikely, but other compilers may have allowed it to be exploited. The MD6 team has doubled the size of the vulnerable buffer, which eliminated the risk. In this case, Fortify SCA found an issue that would have been difficult to catch otherwise.

The other buffer overflow was found in the Blender implementation, from Dr. Colin Bradbury. This issue was a classic typo:

     DataLength sourceDataLength2[3];	// high order parts of data length      ...      if (ss.sourceDataLength < (bcount | databitlen)) // overflow           if (++ss.sourceDataLength2[0] == 0) // increment higher order count                if (++ss.sourceDataLength2[1] == 0) // and the next higher order                     ++ss.sourceDataLength2[3]; // and the next one, etc.

The developer simply mistyped, using 3 instead of 2 for the array access. This issue was probably not caught because it would not be exposed without a very large input. The other issues we found were memory leaks and null dereferences from memory allocation.

This just emphasizes what we already knew about C, even the most careful, security conscious developer messes up memory management. Some of you are saying, so what? These are reference implementations and this is only Round 1. There are a few problems with that thought.

Reference implementations don't disappear, they serve as a starting point for future implementations or are used directly. A bug in the RSA reference implementation was responsible for vulnerabilities in OpenSSL and two separate SSH implementations. They can also be used to design hardware implementations, using buffer sizes to decide how much silicon should be used.

The other consideration is speed, which will be a factor in the choice of algorithm. The fix for the MD6 buffer issues was to double the size of a buffer, which could degrade the performance. On the other hand, memory leaks could slow an implementation. A correct implementation is an accurate implementation.

We will put out a more detailed report on all the results soon.

Technorati Tags: sha-3 buffer overflow

From an industry standpoint, this is a big deal. Gartner's recognition means software security has hit the mainstream. Gartner creates an MQ when an industry segment reaches $100M in total revenue. Then Gartner, as an independent organization, invites vendors to participate. No vendor pays for the MQ and Gartner doesn't charge for it. They evaluated ten vendors. Fortify took the top spot.

Its worth looking at the Gartner methodology to understand what that means. The report is primarily based on what Gartner hears from its clients. (Being an analyst is a good gig if you can get it.) Gartner talked to hundreds of people, not just the companies being evaluated. And customer input is the most influential factor. We had to answer lots of questions about our product and strategy, and I'm sure our sweet and soothing words didn't hurt, but this is not an essay test. Bottom line: it's what the market told Gartner. My favorite part: although static analysis was the focus of the MQ, the runtime components in Fortify 360 were the first thing they called out as Fortify's key differentiator. Satisfaction.

If you're already down with the Gartner crew, you should talk to the authors: Joseph Feiman or Neil MacDonald.

Technorati Tags: Gartner Magic Quadrant Static Analysis

This is retired Major Bruce Jenkins of the USAF commenting on cyber attacks originating from the Middle East.

Companies with even the remotest connections to the Middle East should be on guard against a malware or similar cyber-attack as a result of the ongoing conflict between Israel and the Palestinians.

Our observations suggest that a large number of Web sites have been defaced by a variety of hacker groups from Iran, Lebanon, Morocco and Turkey, and the trend is accelerating.

In the past, attacks were focused on the Department of Defense and other government organizations. But as the government, led by the US Air Force, have built up their cyber defenses, hackers need to move to less suspecting targets. Basically this means that any company with an Internet connection and which has perceived or rumoured connections with the two countries involved in this conflict - or has links with allegedly partisan firms who are also connected - could find their Web site and/or Internet- connected systems under active attack.

As a result, many tens of thousands of companies on the Web could find their hacker attack profile raised significantly, often for no good reason other than rumour and innuendo.

These sorts of attacks are random and reflect a hacker herd mentality. As a result, companies of all sizes should take extra precautions to protect their IT resources.

These precautions include ensuring your IT security, operating system and software patches are up to date, and monitoring the firm's network traffic for any unusual activity.

Given the fact that many Western leaders are urging all sides in the current Middle-Eastern conflict to stage a cease-fire and open diplomatic negotiations, most countries are now in the hacker firing line.

Given the fact that the Internet is so pervasive, I think we could see some very driven hacking and cracking attacks on all manner of targets. Companies of all types need to take precautions, especially as the Internet wakes up after the holiday period. Go here for an article on this subject.

So, apparently there have been little if any repercussions for the recent Monster.com breach. Society at large is starting to suffer from "security breach" a fatigue and customers are being told to believe breaches don't matter if SSNs aren't exposed. What will it take to finally get these companies to be accountable for AVOIDABLE losses?

This quote in particular sums it up: "And yet Monster might suffer little fallout - because the overall state of computer security is so bad anyway."

That kind of sentiment wouldn't be acceptable in any other industry. Oy!

http://www.google.com/hostednews/ap/article/ALeqM5g_bw5CTl4CQJz0y50UE_ebQRfJ8QD964UTIG0

Technorati Tags: security hack monster.com wtf fail

Technorati Tags: security hack rbs cybercrime get rich quick

How do you take down The Google? They have lots of data centers, gobs of bandwidth, unrivaled peering, and a scary amount of compute power. A DDOS from your pimply nephew's botnet won't get the job done. The one force in the universe able to tackle The Google head on? Google Security! Their list of malicious web sites is so powerful that a single fat finger on a Saturday morning can essentially shut down Google search for the better part of an hour. (If you haven't read the story already, go here.)

This turns out to be an all-too-common failure mode for security mechanisms. If the security is powerful enough to do a good job of protecting you, it's probably powerful enough to do some real damage too. People make mistakes, and so sometimes the whole web gets marked as a purveyor of malware, and sometimes your anti-virus deletes applications like Excel.

And those are only the accidents. The more exciting cases are the ones where attackers turn the security system back on the people it's supposed to protect. My favorite from 2008 was the Maryland high school kids who figured out that they could fake up a license plate with a laser printer, drive by a speed camera, and give a speeding ticket to anyone they chose.

People have long known that locking accounts based on authentication failures can have the same sort of effect: if I don't like you, I can lock you out of your account until customer support opens on Monday morning. If I don't like customer support, I can lock out a few thousand users and sit back and enjoy the chaos.

The moral to the story: security features are just like all of the other features. If you haven't thought through what happens when they go wrong, you're probably in for a surprise. Security features sometimes get a free pass because somebody in the security group dreamed them up, and that's a recipe for trouble.

Technorati Tags: google malware