Absolutely. Remember the MySQL authentication bypass vulnerability¹, where a blank password would succeed to authenticate 1/255th of the time? This reminds me of that.
I agree. Postgres is one of the most well thought out DBs I've ever used. They are slow to add features but when they do, they are done right with lot's of attention to detail. Everyone makes mistakes.
The exploit does not actually destroy the files. It allows appending data to the files making the server crash. The file could be recovered by simply removing the junk data added to it.
From the FAQ:
> Persistent Denial of Service: an unauthenticated attacker may use this vulnerability to cause PostgreSQL error messages to be appended to targeted files in the PostgreSQL data directory on the server. Files corrupted in this way may cause the database server to crash, and to refuse to restart. The database server can be fixed either by editing the files and removing the garbage text, or restoring from backup.
Doesn't matter if they can figure it out or not. The data isn't lost, which is the salient point there. There is the potential for datafile corruption, but that is not the same as data corruption or data loss. All your bits are still there and can be recovered by someone with the right expertise.
I am not sure, but a couple of things which would make it possible are.
1) PostgreSQL does generally report which file was corrupted.
2) The PostgreSQL log output rarely looks similar to regular data, so it should be obvious to anyone looking what is wrong if they do look at the contents of the file.
And most importantly they can always contact a PostgreSQL expert who could repair it.
However this does not prevent any of your employees or other users of systems with access to use spipped from committing this attack. You still need a client somewhere and the server is still vulnerable.
Allowing remote connections from any IP to your database, like heroku apparently does, sounds kind of crazy to me. I can't believe they do it. But limiting and encrypting that access just limits, and does not eliminate your vulnerability to this bug.
---
Just to be really clear: Say your corporate blog stores it’s data in your main Postgres instance. As blogging engines tend to, it has a bug, and hackers succeed in using that to get access to your blog’s server. Even if you are using spiped to connect the 2 boxes they still have the ability to mess with your main database, on some other, probably much better secured, box. This bug is ugly.
Just because the attack vector looks simple doesn't mean the bug was obvious.