Matasano Chargen

~-,._.,-~'`^`'~-,._.,-~'`^`'~-,._.,-~'`^`'~-,._.,-~'`^`'~-,._.,-~

MATASANO SECURITY - Chicago. New York City. Sunnyvale.

Application Security Consultant

Full-Time, work visa sponsorship available

~-,._.,-~'`^`'~-,._.,-~'`^`'~-,._.,-~'`^`'~-,._.,-~'`^`'~-,._.,-~

The security of computer systems has increasingly become an everyday concern. The news all too often brings word of yet another compromise, exposing financial information, personal details, or simply salacious pictures. Whatever the impact, it's clear the technology industry has a problem, and there are few easy solutions.

Some seek legislation to impose harsher penalties on the responsible parties. This ignores the fact that many of those responsible are outside the jurisdictions which seek to punish them. In some cases, they may have tacit approval of their own government, or even be operating on their government's behalf. Others turn to established security products looking for antivirus and network filtering technologies to add protection. This is an also an imperfect solution. It places the defender in a reactive posture, responding only to those threats which have been previously detected, and for which countermeasures have been developed. There's no perfect solutions.

At Matasano, we believe the best way to combat security weaknesses is at their source; by discovering and remediating software vulnerabilities before others leverage them for ill effect. Our clients see the value in this approach. …

Security has been a focus of NaCl from the outset. It uses a sandbox security model built around a restricted set of "native code". The aim was to make NaCl apps verifiable from a security stand point.

Chris Rohlf from Matasano did a great blog post, The Security Implications Of Google Native Client, that compares the NaCl approach to ActiveX and Java -- and included beautiful diagrams to boot! Unfortunately the images appear to be broken on the Matasano blog [1] but I've found a PDF'd version [2] that contains them in all their glory.

The post came out of the Matasano team's entry in the Native Client Security Contest [3] that Google held early last year. The Matasano team ended up taking second place behind Mark Dowd / Ben Hawkes [4]. All those guys are 'rockstars' in the security industry.

So, Google has thought deeply and tried hard when designing NaCl's security. They a care enough and are switched on enough to run a security contest that was well received by the industry (rare). A number of mega-brains-on-sticks found issues back in May '09 -- hopefully they have all been addressed.

It looks to me that Google has done a good job at learning from past mistakes when implementing NaCl and it should be different. No doubt there will be further security issues found but then again, name a framework that is free from flaws?

[1] http://chargen.matasano.com/chargen/2009/8/27/the-security-implications-of-google-native-client.html

[2]…

What you are referring to is called "stretching". It's a lot better than a simple salted hash, but bcrypt would still be better.

I'm no crypto expert, but I think this is due to the way bcrypt was designed, and their use of a pessimized Blowfish cypher. SHA512 was designed for speed, which is the opposite of what you want with a password hashing scheme.

tptacek talks a little about this in this blog post:

http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html

"Bcrypt uses Blowfish instead of MD5. Blowfish is a block cipher with a notoriously expensive setup time. To optimize Blowfish to run much faster, you’d have to contribute a major advance to cryptography. We security practioners are all “betting people”, and we usually like to place our bets on the side that “demands major advances in cryptography”."

Other interesting links:
http://stackoverflow.com/questions/3722780/do-any-security-experts-recommend-bcrypt-for-password-storage
http://en.wikipedia.org/wiki/Bcrypt

This isn't great, but it's not quite as terrible as its being made out to be for the official packages. The Mercurial bug is only relevant if you're using Mercurial with user supplied input on your production servers. Unlikely if you're not BitBucket. http://chargen.matasano.com/chargen/2015/3/17/this-new-vulnerability-mercurial-command-injection-cve-2014-9462.html Is a good read on the subject.

The libtasn1 bug seems to be only relevant if you're using GnuTLS. Again, not great but not the most widely used library either.

Cutting those two out cuts the number of vulnerable images in half and there's probably a few more rarely used programs with security issues further down the tail. Again, this isn't great, but it's not quite as terrible as the authors are making it to be.

The user supplied packages on the other hand seems to be quite a bit worse.

Not checking malloc's return value can easily lead to security vulnerabilities, particularly in bytecode interpreters and things like that.

The basic plan is simple: Trick the target program into allocating an impossible huge block of memory (e.g. 3 gigabyte on a 32 bit system). Malloc will return NULL but the program blindly assumes the allocation has succeeded. Now use carefully chosen indices to read and write whatever memory you want.

As an example, here's a classic Flash exploit that used this technique: http://chargen.matasano.com/chargen/2007/7/27/this-new-vulnerability-dowds-inhuman-flash-exploit.html

Really, xmalloc is five lines of code. Just use it.

void *xmalloc(size_t size) {
void *ptr = malloc(size);
if (!ptr) abort();
return ptr;
}

Yes. As a simple example, if you XORd your input text with a 1-byte key, the letter frequency of english text would be unchanged.

So your most common byte in your output would be likely to be the encrypted char 'e'. You could then recover the key by XOR 'e' with that most common byte.

More complex systems have more complex patterns, but that's what cryptopgraphers do - try and spot weaknesses in an algorithm.

As always, this is a great read: http://chargen.matasano.com/chargen/2009/7/22/if-youre-typing-the-letters-a-e-s-into-your-code-youre-doing.html

Search for "Garbling a block to confuse an app" and read on from there for a real-world use of output patterns (used when you can partially control the input).