Making encryption easier and accessible is all the rage. From a programming perspective, one of the most frequent suggestions is to use nacl. I have a few gripes with it.

more...

Here at 31C3, Sebastian Schinzel just gave a presentation based on Revisiting SSL/TLS Implementations: New Bleichenbacher Side Channels and Attacks. The particular attack that caught my eye was the failure to generate a fake PMS before checking for bad padding, not after. Doing it afterwards exposes a timing difference of up to a few microseconds which can be measured over the network.

Of course, this depends on the OpenSSL RAND_pseudo_bytes function taking a measureable amount of time. In LibreSSL, we replaced the random number generator with arc4random which should be much faster. Time to measure. Thanks to benno for setting me up with a 5.5 test machine. (5.5 is the perfect release to test: new chacha20 arc4random, but still vanilla OpenSSL.)

#include <openssl/rand.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <machine/pctr.h>

int
main(int argc, char **argv)
{
        uint64_t before, after;
        int i;
        char buf[48];

        for (i = 0; i < 100; i++)
                RAND_pseudo_bytes(buf, sizeof(buf));
        before = rdtsc();
        for (i = 0; i < 10000; i++)
                RAND_pseudo_bytes(buf, sizeof(buf));
        after = rdtsc();
        printf("RAND_bytes duration: %f\n", (after - before) / 10000.0);
        for (i = 0; i < 100; i++)
                arc4random_buf(buf, sizeof(buf));
        before = rdtsc();
        for (i = 0; i < 10000; i++)
                arc4random_buf(buf, sizeof(buf));
        after = rdtsc();
        printf("arc4random duration: %f\n", (after - before) / 10000.0);
        return 0;
}

Results:

RAND_bytes duration: 24759.2385000
arc4random duration: 2376.2070000

10x faster. Not bad. That microsecond timing attack is now a nanosecond timing attack (albeit for larger values of nanosecond.)

There’s a “smart” shortcut one can take when writing a comparison function (such as for qsort or an RB tree): return the difference between two numbers. Unfortunately, it’s not very smart.

int
compar(int x, int y)
{
        return x - y;
}

Consider x = 4 and y = 6. This does indeed return a negative number (-2), to indicate that x is less than y. If x = 5 and y = -3, then it returns 8 (positive). Two test cases, all passing. Mark it done.

But wait. What if x = 1987654321 and y = -1987654321? Then the difference between them is -319658654 (negative) which proves that x is less than y. That’s less than correct. (Never mind the undefinedness of sign overflow; unsigned won’t save you here.)

Unfortunately, this idiom keeps coming back, probably because some people cheat when writing examples and then other people cheat and copy example code without thinking. Long ago, I fixed one example in the tree man page. A Google search reveals that the practice is both common and widely known to be dangerous.

Even so, it continues to happen even in production code. I noticed in passing this problem existed in nsd. Coincidentally, otto just spent a few days pulling his hair out because nsd was spinning in an infinite loop because a corrupted tree contained a loop, only to find the broken comparison was precisely the problem.

Moral: Don’t do subtraction instead of comparison, even if they tell you “look how cool this is” at school!

Not always, but more frequently than never, I manage Firefox’s cookies by hand. Seeing what’s set, clearing out some I don’t like. Recently I discovered the button to do so in the Preferences dialog had disappeared from the Privacy tab.

Where did it go? It’s hiding under the history section. You have to change Firefox will: “Remember history” to “Use custom settings for history” and then the “Show Cookies...” button reappears. Because that totally makes sense. Just looking at cookies clearly requires that I also change to custom history settings.

A bit of commentary for some selected examples from Theo’s random hunt. Mostly a post commit justification for the great posix violation.

more...

OpenBSD libc is now at version 78.0, featuring a good mix of features. Something old, something new, something different.

old

The setkey and encrypt functions were deleted. Traditionally, they implement the DES algorithm, however the the standard doesn’t mandate any algorithm, meaning interoperability is not guaranteed. XOR would satisfy the requirement, for instance. It’s not really possible to use a much better algorithm, however, because the block size is fixed at 64 bits (expressed as 64 bytes, because that’s convenient), which rules out AES. Switching to blowfish just doesn’t seem worth it, given that the interface only supports a global key. The good news is that out of the ports tree, only one program used these functions. claws mail encrypts users’ passwords with the key “passkey0”. Hope that wasn’t a secret.

The cfree function was also removed. It was added long ago to be compatible with SunOS. SunOS is dead; so is the software written for it.

new

SipHash was added to libc. It’s been in the kernel for a little while, slowly replacing other ad hoc hash functions. It’s faster than algorithms like MD5 or SHA, but less predictable than simpler functions like add and shift or FNV due to the introduction of a random key. Although the round counts are variable, we’ve standardized on 2/4 as a good enough mix. Easily changed later if it becomes necessary, but we’d like to keep things fast so that SipHash24 becomes the goto default hash function.

guenther@ added one more at syscall, chflagsat, which is like fchmodat, etc. Gotta have ‘em all.

different

deraadt@ decided that another fix for programs relying on bobo rand calls for randomness is to simply break the standard and give them what they’ve been hoping for all along.

It’s been a few years since realloc was fixed but occasionally things change, so it’s good to check up on them to make sure there aren’t any regressions. In fact, at the time of the fix, I didn’t even have a complete test case. Now I do.

more...

Everybody knows that MD5 is as terribly useless as ROT13 and you should have switched to SHA3-512 like twenty years ago. But lots of usage sticks around, and will continue to stick around for a long time to come, leading to the long tail of MD5. Why not simply convert to a better hash function? Maybe it’s not so simple.

more...

First, start with there are no good constant-time data structures. After reading the HN thread, I wanted to see if the attack was truly viable. Can we recovery a JSESSIONID? My previous efforts attacking Lua took a slightly different tack.

more...

A few notes about memcpy vs memmove and some related items as well.

more...