Spent a couple hours last night writing the core of a stripped down, PHP4 compatible API library for Amazon SimpleDB (in the style of my flickr simple library. Just not a fan of abstraction for its own sake). In the process I discovered that Amazon had revved the version on their “Signature Method”. Which is good news as SignatureVersion 1 contains a classic crypto-blunder in its design, namely it encourages collisions. (more details, also why you care about collisions) To date the solution was use SSL, and wait patiently, very patiently. So yay for Amazon fixing this! And in fairness, first couple of drafts of the OAuth spec contained a similar issue, though it got ironed out quickly. Yay for many eyes and the open web.

“OAuth-compatible” signing

Great things are more secure, good news and all, but that isn’t what caught my eye. This block of text did:

Here is what’s different about forming the string to sign for signature version 2:

• You include additional components of the request in the string to sign
• You include the query string control parameters (the equals signs and ampersands) in the string to sign
• You sort the query string parameters using byte ordering
• You URL encode the query string parameters and their values before signing the request

You really have to be an OAuth-dork to find anything special with that paragraph, but if you were, you’d notice that those 4 bullets are an incredibly succinct description of generating an OAuth signature. (in fact a more succinct description then appears anywhere in the OAuth documentation

Which meant that my SimpleDB library can reuse most of the logic from my OAuth library to do the trickiest part of the API call, namely the signing. (Additionally it means that security reviews of both protocols support each other)

So my AWS signing method is a approximately a dozen characters different then my OAuth method and as straightforward as:

    .....

    $signature = aws_request_signature(AWS_SECRET_KEY, $http_method, AWS_SIMPLEDB_SERVICEURL, $parameters);
    $parameters['Signature'] = $signature;

    $encoded_params = array();

    foreach ($parameters as $k => $v){
        $encoded_params[] = oauth_urlencodeRFC3986($k).'='.oauth_urlencodeRFC3986($v);
    }

    $request_url = AWS_SIMPLEDB_SERVICEURL . '?' . implode('&', $encoded_params);

    .....

    function aws_request_signature($key, $http_method, $service_url, $parameters) {
        $base_string = aws_base_string($http_method, $service_url, $parameters);
        return base64_encode(hash_hmac('sha1', $base_string, $key, true));
    }

    function aws_base_string($http_method, $service_url, $parameters) {
        $parsed = parse_url($service_url);

        $host = strtolower($parsed['host']);
        $path = $parsed['path'] ? $parsed['path'] : '/';
        $data = array(
            strtoupper($http_method),
            $host,
            $path,
            oauth_normalized_request_params($parameters)
        );

        $base_string = join("\n", $data);
        return $base_string;
    }

(this uses my personal OAuth library, but your library should have similar methods)

Sure made my jobs of implementing a library easier. If you’re going to invent a new crypto protocol, please consider doing like Amazon, and re-using the basic building blocks. (which also happen to be best practices)

Congrats to waferbaby, mroth, and ph for totally owning on today’s friend importing feature (aka beehive).

We’re a little late to the game but its awfully nice to be able to launch with zero screenscraping, and zero phishing-creepy-give-us-your-password. This is what data-portability-open-data-delegated-trust future looks like.

update: and yes, we’re cheating, because Yahoo’s addressbook API is still internal+partners only. We’re working on it.

http://www.readwriteweb.com/archives/your_email_password_a_true_hor.php

http://www.zephoria.org/thoughts/archives/2007/11/15/algorithms_for.html

http://laughingmeme.org/code/hmacsha1.php.txt

http://defacebooked.blogspot.com/

It’s been “big news” that Twitter and Jott are vulnerable to CallerID spoofing. Can’t speak for the Jott kids, but I know this isn’t news to Twitter kids, given that Blaine and Rabble were demonstrating CallerID spoofing (and related techniques) over Asterisk several years ago.

This is one of those security problems that everyone knows about and quietly agrees not to speak too loudly about because alternatives like Nitesh proposes are usability disasters.

The carriers have designed their networks around the assumption of monopoly practices and zero information sharing, and it means they’re slow and make dumb mistakes. (I always think of it as a nice parallel to the current U.S. administration — organizational tactics constrain your imagination and your coping techniques)

Jabber, btw doesn’t have this problem.

Photo by thristian

http://blog.wired.com/27bstroke6/2007/01/myspace_alleged.html

http://groups.yahoo.com/group/yws-flickr/message/2034

http://www.ambiguous.org/archive.php3/2006/08/10#quinn2006810.1

Even folks who’ve managed to stay fairly anonymous leak a lot of info in their tags.

http://www.schneier.com/blog/archives/2005/12/30000_people_mi.html

http://rc3.org/2005/11/changing_the_rules.php

In particular this advisory applies to you if you accept unflitered URLs from strangers for passing to Magpie, and you have curl+SSL support compiled into Magpie.

If you’re running Magpie in a context where you allow people to submit unreviewed URLs, and you have PHP compiled with cURL SSL support then this vulnerability effects you.

Given a specially crafted (and very simple) URL, an attacker can execute arbitrary code in the web server context. There is no escalation possibly with this vulnerability, though potentially it could be combined with other attacks to allow some sort of permissions escalation.

I’ll will release a patch, and a new version this evening unless someone beats me to it. (unfortunately we haven’t been given a grace period here)

Its a variation on the traditional PHP null terminated string attack. (Does make me wish I had made it to Chris’ talk when he was here a few weeks ago, rather then being 1 of 3000 people turned away from the Murakami talk at MIT)

update 2005-10-28T15:33Z: I’ve got a patch out, waiting for a few people to sanity check it, before rolling out a new release.

Interestingly only one post has been altered, and that post has the distinction of being the post with an embedded Paypal donation button.

I’ve yanked the blog down for now until I have time to figure out what happened. (and I just got LM back online)

http://fast.info/myspace/

http://slashdot.org/comments.pl?sid=164910&cid=13763325

http://lists.debian.org/debian-devel-announce/2005/05/msg00010.html

However there is a nice wrapper, open-uri that makes it simple to add custom headers, provides loop aware redirect following, etc. And it provides a super slick drop in replacement for the Kernel#open method, so that you can open either a local file, or a remote URL….

Danger Will Robinson! Danger

At this point, alarm bells are going off in the heads’ of the PHP programmers in the audience, who are thinking to themselves,

“Wow, someone went to the trouble of making Ruby act PHP-like! Down to replicating one of the most commonly exploited security holes!”

Sincerest forms of flattery aside, that seems like a really bad idea. Admittedly you have to explicitly require 'open-uri' in order to activate the feature, howev er as the best of the Ruby HTTP clients (I’ve found to date) that seems like a decent bet in many web apps, and once you’ve done that all future calls to open can be hijacked to download remote files.

Now, this being Ruby, there is probably some clever solution involving de-aliasing the open method which makes all these problems go away. Still this seems like an opportunity for the PHP community, with its near infinite experience with having web apps exploited, to teach the Ruby community something. Overloading your core file open semantic to transparently open remote resources is a bad idea, full stop.