Entries Tagged "Linux"

Page 3 of 4

Random Number Bug in Debian Linux

This is a big deal:

On May 13th, 2008 the Debian project announced that Luciano Bello found an interesting vulnerability in the OpenSSL package they were distributing. The bug in question was caused by the removal of the following line of code from md_rand.c

	MD_Update(&m,buf,j);
	[ .. ]
	MD_Update(&m,buf,j); /* purify complains */

These lines were removed because they caused the Valgrind and Purify tools to produce warnings about the use of uninitialized data in any code that was linked to OpenSSL. You can see one such report to the OpenSSL team here. Removing this code has the side effect of crippling the seeding process for the OpenSSL PRNG. Instead of mixing in random data for the initial seed, the only “random” value that was used was the current process ID. On the Linux platform, the default maximum process ID is 32,768, resulting in a very small number of seed values being used for all PRNG operations.

More info, from Debian, here. And from the hacker community here. Seems that the bug was introduced in September 2006.

More analysis here. And a cartoon.

Random numbers are used everywhere in cryptography, for both short- and long-term security. And, as we’ve seen here, security flaws in random number generators are really easy to accidently create and really hard to discover after the fact. Back when the NSA was routinely weakening commercial cryptography, their favorite technique was reducing the entropy of the random number generator.

Posted on May 19, 2008 at 6:07 AM • View Comments

Physically Hacking Windows Computers via FireWire

This is impressive:

With Winlockpwn, the attacker connects a Linux machine to the Firewire port on the victim’s machine. The attacker then gets full read-and-write memory access and the tool deactivates Windows’s password protection that resides in local memory. Then he or she has carte blanche to steal passwords or drop rootkits and keyloggers onto the machine.

Full disk encryption seems like the only defense here.

Posted on March 13, 2008 at 11:54 AM • View Comments

The Strange Story of Dual_EC_DRBG

Random numbers are critical for cryptography: for encryption keys, random authentication challenges, initialization vectors, nonces, key-agreement schemes, generating prime numbers and so on. Break the random-number generator, and most of the time you break the entire security system. Which is why you should worry about a new random-number standard that includes an algorithm that is slow, badly designed and just might contain a backdoor for the National Security Agency.

Generating random numbers isn’t easy, and researchers have discovered lots of problems and attacks over the years. A recent paper found a flaw in the Windows 2000 random-number generator. Another paper found flaws in the Linux random-number generator. Back in 1996, an early version of SSL was broken because of flaws in its random-number generator. With John Kelsey and Niels Ferguson in 1999, I co-authored Yarrow, a random-number generator based on our own cryptanalysis work. I improved this design four years later—and renamed it Fortuna—in the book Practical Cryptography, which I co-authored with Ferguson.

The U.S. government released a new official standard for random-number generators this year, and it will likely be followed by software and hardware developers around the world. Called NIST Special Publication 800-90 (.pdf), the 130-page document contains four different approved techniques, called DRBGs, or “Deterministic Random Bit Generators.” All four are based on existing cryptographic primitives. One is based on hash functions, one on HMAC, one on block ciphers and one on elliptic curves. It’s smart cryptographic design to use only a few well-trusted cryptographic primitives, so building a random-number generator out of existing parts is a good thing.

But one of those generators—the one based on elliptic curves—is not like the others. Called Dual_EC_DRBG, not only is it a mouthful to say, it’s also three orders of magnitude slower than its peers. It’s in the standard only because it’s been championed by the NSA, which first proposed it years ago in a related standardization project at the American National Standards Institute.

The NSA has always been intimately involved in U.S. cryptography standards—it is, after all, expert in making and breaking secret codes. So the agency’s participation in the NIST (the U.S. Commerce Department’s National Institute of Standards and Technology) standard is not sinister in itself. It’s only when you look under the hood at the NSA’s contribution that questions arise.

Problems with Dual_EC_DRBG were first described in early 2006. The math is complicated, but the general point is that the random numbers it produces have a small bias. The problem isn’t large enough to make the algorithm unusable—and Appendix E of the NIST standard describes an optional work-around to avoid the issue—but it’s cause for concern. Cryptographers are a conservative bunch: We don’t like to use algorithms that have even a whiff of a problem.

But today there’s an even bigger stink brewing around Dual_EC_DRBG. In an informal presentation (.pdf) at the CRYPTO 2007 conference in August, Dan Shumow and Niels Ferguson showed that the algorithm contains a weakness that can only be described as a backdoor.

This is how it works: There are a bunch of constants—fixed numbers—in the standard used to define the algorithm’s elliptic curve. These constants are listed in Appendix A of the NIST publication, but nowhere is it explained where they came from.

What Shumow and Ferguson showed is that these numbers have a relationship with a second, secret set of numbers that can act as a kind of skeleton key. If you know the secret numbers, you can predict the output of the random-number generator after collecting just 32 bytes of its output. To put that in real terms, you only need to monitor one TLS internet encryption connection in order to crack the security of that protocol. If you know the secret numbers, you can completely break any instantiation of Dual_EC_DRBG.

The researchers don’t know what the secret numbers are. But because of the way the algorithm works, the person who produced the constants might know; he had the mathematical opportunity to produce the constants and the secret numbers in tandem.

Of course, we have no way of knowing whether the NSA knows the secret numbers that break Dual_EC-DRBG. We have no way of knowing whether an NSA employee working on his own came up with the constants—and has the secret numbers. We don’t know if someone from NIST, or someone in the ANSI working group, has them. Maybe nobody does.

We don’t know where the constants came from in the first place. We only know that whoever came up with them could have the key to this backdoor. And we know there’s no way for NIST—or anyone else—to prove otherwise.

This is scary stuff indeed.

Even if no one knows the secret numbers, the fact that the backdoor is present makes Dual_EC_DRBG very fragile. If someone were to solve just one instance of the algorithm’s elliptic-curve problem, he would effectively have the keys to the kingdom. He could then use it for whatever nefarious purpose he wanted. Or he could publish his result, and render every implementation of the random-number generator completely insecure.

It’s possible to implement Dual_EC_DRBG in such a way as to protect it against this backdoor, by generating new constants with another secure random-number generator and then publishing the seed. This method is even in the NIST document, in Appendix A. But the procedure is optional, and my guess is that most implementations of the Dual_EC_DRBG won’t bother.

If this story leaves you confused, join the club. I don’t understand why the NSA was so insistent about including Dual_EC_DRBG in the standard. It makes no sense as a trap door: It’s public, and rather obvious. It makes no sense from an engineering perspective: It’s too slow for anyone to willingly use it. And it makes no sense from a backwards-compatibility perspective: Swapping one random-number generator for another is easy.

My recommendation, if you’re in need of a random-number generator, is not to use Dual_EC_DRBG under any circumstances. If you have to use something in SP 800-90, use CTR_DRBG or Hash_DRBG.

In the meantime, both NIST and the NSA have some explaining to do.

This essay originally appeared on Wired.com.

Posted on November 15, 2007 at 6:08 AM • View Comments

New German Hacking Law

There has been much written about the new German hacker-tool law, which went into effect earlier this month.

Dark Reading has the most interesting speculation:

Many security people say the law is so flawed and so broad and that no one can really comply with it. “In essence, the way the laws are phrased now, there is no way to ever comply… even as a non-security company,” says researcher Halvar Flake, a.k.a. Thomas Dullien, CEO and head of research at Sabre Security.

“If I walked into a store now and told the clerk that I wish to buy Windows XP and I will use it to hack, then the clerk is aiding me in committing a crime by [selling me] Windows XP,” Dullien says. “The law doesn’t actually distinguish between what the intended purpose of a program is. It just says if you put a piece of code in a disposition that is used to commit a crime, you’re complicit in that crime.”

Dullien says his company’s BinNavi tool for debugging and analyzing code or malware is fairly insulated from the law because it doesn’t include exploits. But his company still must ensure it doesn’t sell to “dodgy” customers.

Many other German security researchers, meanwhile, have pulled their proof-of-concept exploit code and hacking tools offline for fear of prosecution.

[…]

The German law has even given some U.S. researchers pause as well. It’s unclear whether the long arm of the German law could reach them, so some aren’t taking any chances: The exploit-laden Metasploit hacking tool could fall under German law if someone possesses it, distributes it, or uses it, for instance. “I’m staying out of Germany,” says HD Moore, Metasploit’s creator and director of security research for BreakingPoint Systems.

“Just about everything the Metasploit project provides [could] fall under that law,” Moore says. “Every exploit, most of the tools, and even the documentation in some cases.”

Moore notes that most Linux distros are now illegal in Germany as well, because they include the open-source nmap security scanner tool—and some include Metasploit as well.

The law basically leaves the door open to outlaw any software used in a crime, notes Sabre Security’s Dullien.

Zoller says the biggest problem with the new law is that it’s so vague that no one really knows what it means yet. “We have to wait for something to happen to know the limits.”

Posted on August 28, 2007 at 1:32 PM • View Comments

2006 Operating System Vulnerability Study

Long, but interesting.

Closing

While there are an enormous variety of operating systems to choose from, only four “core” lineages exist in the mainstream—Windows, OS X, Linux and UNIX. Each system carries its own baggage of vulnerabilities ranging from local exploits and user introduced weaknesses to remotely available attack vectors.

As far as “straight-out-of-box” conditions go, both Microsoft’s Windows and Apple’s OS X are ripe with remotely accessible vulnerabilities. Even before enabling the servers, Windows based machines contain numerous exploitable holes allowing attackers to not only access the system but also execute arbitrary code. Both OS X and Windows were susceptible to additional vulnerabilities after enabling the built-in services. Once patched, however, both companies support a product that is secure, at least from the outside. The UNIX and Linux variants present a much more robust exterior to the outside. Even when the pre-configured server binaries are enabled, each system generally maintained its integrity against remote attacks. Compared with the Microsoft and Apple products, however, UNIX and Linux systems tend to have a higher learning curve for acceptance as desktop platforms.

When it comes to business, most systems have the benefit of trained administrators and IT departments to properly patch and configure the operating systems and their corresponding services. Things are different with home computers. The esoteric nature of the UNIX and Linux systems tend to result in home users with an increased understanding of security concerns. An already “hardened” operating system therefore has the benefit of a knowledgeable user base. The more consumer oriented operating systems made by Microsoft and Apple are each hardened in their own right. As soon as users begin to arbitrarily enable remote services or fiddle with the default configurations, the systems quickly become open to intrusion. Without a diligence for applying the appropriate patches or enabling automatic updates, owners of Windows and OS X systems are the most susceptible to quick and thorough remote violations by hackers.

Posted on April 2, 2007 at 7:38 AM • View Comments

DHS Funding Open Source Security

From eWeek:

The U.S. government’s Department of Homeland Security plans to spend $1.24 million over three years to fund an ambitious software auditing project aimed at beefing up the security and reliability of several widely deployed open-source products.

The grant, called the “Vulnerability Discovery and Remediation Open Source Hardening Project,” is part of a broad federal initiative to perform daily security audits of approximately 40 open-source software packages, including Linux, Apache, MySQL and Sendmail.

The plan is to use source code analysis technology from San Francisco-based Coverity Inc. to pinpoint and correct security vulnerabilities and other potentially dangerous defects in key open-source packages.

Software engineers at Stanford University will manage the project and maintain a publicly available database of bugs and defects.

Anti-virus vendor Symantec Corp. is providing guidance as to where security gaps might be in certain open-source projects.

I think this is a great use of public funds. One of the limitations of open-source development is that it’s hard to fund tools like Coverity. And this kind of thing improves security for a lot of different organizations against a wide variety of threats. And it increases competition with Microsoft, which will force them to improve their OS as well. Everybody wins.

What’s affected?

In addition to Linux, Apache, MySQL and Sendmail, the project will also pore over the code bases for FreeBSD, Mozilla, PostgreSQL and the GTK (GIMP Tool Kit) library.

And from ZDNet:

The list of open-source projects that Stanford and Coverity plan to check for security bugs includes Apache, BIND, Ethereal, KDE, Linux, Firefox, FreeBSD, OpenBSD, OpenSSL and MySQL, Coverity said.

Posted on January 17, 2006 at 1:04 PM • View Comments

1 2 3 4

Sidebar photo of Bruce Schneier by Joe MacInnis.