I prefer pf actually :)

Indeed, i've had confirmation from a number of other security people about encountering memcacheds internal to organisations, and your points are all valid for internal installations. The external-facing instances we found are not explained by assuming the internal network is trusted, hence the point about developers taking an increasing network-security role.

There's a deeper issue at play here as it relates to shifting apps and platforms away from your own hardware/networks. Developers are now often responsible for deploying apps onto cloud systems where they don't have experience with network-security or the tools for protecting network-based services, and this is an obvious difference from the traditional network/app split that occurs in most corporates. It doesn't help that memcached (by default) binds to * but they do make this pretty clear (also, remote enumeration of the cache is genuinely a debug feature).

Man pages help, but when the defaults don't aid developers we need to a rethink both of the software (memcached) and the systems were it's not running securely (cloud platforms).

eh... this presentation was more an "in-person" thing than meant for later perusing.

that said, i'll stick to "firewall" next time.

In terms of the vendors identified, Bit.ly, GoWalla and Pbs were notified. Bit.ly and GoWalla repaired the flaws within minutes. I am not aware of Pbs repairing the issue. This talk seems to have struck a chord which I can't really explain (suggestions welcome). Yes, exposing your memcached's is bad (the talk shows just how bad), but it's not a clever find to discover them. [fd: that's my name on the slides]