[ceejayoz]

I don't think you have to have a database starting with - for the bug to work.

[jonknee]

No, but thankfully you do need postgres to be accessible remotely.

[achillean]

Which is not an uncommon situation actually. I've only started surveying the Internet for PostgreSQL for a bit more than a day and I've already discovered more than a hundred thousand (168,031) remotely-accessible PostgreSQL instances: http://www.shodanhq.com/search?q=port%3A5432

[krg]

I'm surprised this is so common. I've never set up any database accessible to the public-- I've already got to worry about securing the public-facing web server, why add another vector for attack?

[siddboots]

Even without being publically accessible, it's a DBA's nightmare scenario. There are plenty of corporate data warehousing environments in which many hundreds of employees have direct access to the database. This exploit would allow any of those employees to drop tables without exposing their credentials.

[selenamarie]

In one case, a large service provider is specifically providing that kind of database access to their customers.

And to be fair: http://www.shodanhq.com/search?q=mysql

[achillean]

You get a lot more results if you search for the service/ port directly! http://www.shodanhq.com/search?q=port%3A3306

[syncsynchalt]

Or you'll need such a weird design that user input is translated to database names.

I suspect that's why they weren't able to tell people that if your db port is secure you're safe.

[rosser]

Or have a Bad Guy in your network...

[jonknee]

I firewall all traffic so not only is psql not open remotely (the users are tied to hosts), but the traffic never even makes it there unless you are coming from an authorized machine. It would take a really bad guy on the network to cause trouble here and at that point the database is not my biggest concern.