The blog post briefly touches on this, but it's been fixed for more than a year, its just that some linux distros are very slow to get updates (read debian-stable).
Initially I thought this was a new vulnerability.
> I find it irresponsible of the developers and distributors of Redis and memcached to provide default configurations that lack any authentication. Yes, I understand the reasoning that they should only be used only on "trusted internal networks". The problem is that very few internal networks, in practice, are much safer than the internet. We can't continue to make the same bad assumptions of a decade ago and expect security to improve. Even an unauthenticated service listening on localhost is risky these days. It wouldn't be hard to add an auto-generated, random password to these services during installation. That is, if the developers of these services took security seriously.
Also this:
> Notified Python Security that full details of issue would be published due to inaction on their part. [After half a year of inaction]
If you've never reported a security bug before this is generally par for the course for situations like this. Now with obvious holes like heartbleed, everyone understands the stakes really quickly and it gets patched fast. But for these types of problems where it's a multistage attack there is just a complete lack of resources to fix this type of thing.
4 comments
[ 4.3 ms ] story [ 20.3 ms ] thread> I find it irresponsible of the developers and distributors of Redis and memcached to provide default configurations that lack any authentication. Yes, I understand the reasoning that they should only be used only on "trusted internal networks". The problem is that very few internal networks, in practice, are much safer than the internet. We can't continue to make the same bad assumptions of a decade ago and expect security to improve. Even an unauthenticated service listening on localhost is risky these days. It wouldn't be hard to add an auto-generated, random password to these services during installation. That is, if the developers of these services took security seriously.
Also this:
> Notified Python Security that full details of issue would be published due to inaction on their part. [After half a year of inaction]
If you've never reported a security bug before this is generally par for the course for situations like this. Now with obvious holes like heartbleed, everyone understands the stakes really quickly and it gets patched fast. But for these types of problems where it's a multistage attack there is just a complete lack of resources to fix this type of thing.