Laughing Meme

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.

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.

Some tags I check when trying to figure out who someone is/what their story is: me, friends, work, home, weather, craigslist. Also a quick visual scan for place names.

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

MagpieRSS 0.72 is now available. This release addresses last week’s security advisory by applying the patch I released to the list last week.

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.

In (hopefully) unrelated news, I was just notified that there is a security vulnerability in Snoopy, and hence Magpie. Apparently there is an attack that leverages the fact that Snoopy passes unfiltered arguments to curl that allows for arbitrary code execution. Here is a note I just sent to the mailing list

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.

Someone seems to have successfully modified the content of a post on the Wordpress powered Magpie blog to insert link spam into the content of an existing post. Is there a known vulnerability that allows this? I admit I’ve been remiss in following Wordpress security advisories?

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)

Ruby’s obvious HTTP client library is Net::HTTP (’net/http’), however it feels a little bit awkward to use and lacks nice features like following redirects. If you’re coming from LWP you’ll be disappointed.

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.