Hacker News Reader

Comment by octo_t | Hacker News Reader

This is the main vulnerability I presume

> A connection request containing a database name that begins with "-" may be crafted to damage or destroy files within a server's data directory

I just. No words.

View on HN

Getting this stuff right is hard. Don't be a hater.

Just because the attack vector looks simple doesn't mean the bug was obvious.

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.

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.

1: http://thehackernews.com/2012/06/cve-2012-2122-serious-mysql...

If you have never released software with a security hole, it is because you have never released software.

Very smart and conscientious people can mess things up here. Shaming serves no purpose.

The FAQ makes no mention of this massive data loss possibility which seems a bit odd…

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.

You actually expect most users to figure that out? Especially if corrupted with stuff that looks vaguely like regular postgres data...

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.

defense in depth though, users shouldn't be able to craft connection requests to begin with

Then how would a user use the db? Not every use of a database is behind a web application.

Well, once could use something like spiped[1], which would add a very large roadblock to any attacker.

[1]: http://www.tarsnap.com/spiped.html

This is perfectly compatible with Postgres.

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.

Reply on news.ycombinator.com