I read that more as warning users of other database systems to not get complacent just because they were not hit this time. For instance, another database system had a bug where authentication could be bypassed with a few hundred attempts under certain conditions; a third database system had a hardcoded login and password which was only discovered after it had been open sourced; and so on. Not allowing connections from untrusted systems to the database port makes it harder to exploit bugs like these.
Posted Apr 4, 2013 15:57 UTC (Thu) by cesarb (subscriber, #6266)
[Link]
And how could I have forgotten this one? Yet another database system had a bug which was used to create a fast-propagating worm, which crashed parts of the Internet simply due to propagating too fast.
A serious PostgreSQL security fix
Posted Apr 4, 2013 22:46 UTC (Thu) by dlang (✭ supporter ✭, #313)
[Link]
> Yet another database system had a bug which was used to create a fast-propagating worm, which crashed parts of the Internet simply due to propagating too fast.
This one is especially important to note because this result indicated that many people DO have their databases directly accessible from the Internet.
This means that the comment earlier
> Agreed. Restricting connections to a specific network is DBA 101.
>
> You are just bad if you aren't doing that already.
misses the point.
It may be DBA 101, but so many people are doing it wrong that a DB exploit was able to crash parts of the Internet
A serious PostgreSQL security fix
Posted Apr 8, 2013 14:19 UTC (Mon) by ortalo (subscriber, #4654)
[Link]
What about setting priorities on defence in depth for devel 101 also?
I mean, now that the kernel is secure enough, why not focus on the database engine?
Sounds to me a less moving target than the web browser or the javascript engine.
And there is much more valuable data inside: why bother about the credit card number when you can directly write in the ledger...?
A serious PostgreSQL security fix
Posted Apr 8, 2013 15:16 UTC (Mon) by spender (subscriber, #23067)
[Link]
> I mean, now that the kernel is secure enough, why not focus on the database engine?
Thank you for the Monday morning laugh :)
-Brad
A serious PostgreSQL security fix
Posted Apr 7, 2013 5:31 UTC (Sun) by gdt (subscriber, #6284)
[Link]
And yet Postgres could have used TLS with client and server certificates. Which would have avoided this attack, even for Internet-visible ports. So it really is throwing stones in a glass house.
A serious PostgreSQL security fix
Posted Apr 7, 2013 9:32 UTC (Sun) by cortana (subscriber, #24596)
[Link]
Posted Apr 7, 2013 12:53 UTC (Sun) by gdt (subscriber, #6284)
[Link]
I didn't mean "support" so much as "requires". My apologies for not expressing my thought more clearly.
A serious PostgreSQL security fix
Posted Apr 7, 2013 13:59 UTC (Sun) by cesarb (subscriber, #6266)
[Link]
AFAIK, the authentication is per-database, which means it has to read the database name from the client before authenticating, even if you are using certificates.
The bug in question involved the client sending an invalid database name.
Oops.
A serious PostgreSQL security fix
Posted Apr 7, 2013 22:40 UTC (Sun) by hummassa (subscriber, #307)
[Link]
IIRC correctly my SSL/TLS, the authentication (and the start of encrypting the whole session) comes before anything else. I suppose when the client asks for connection to a database, he is already autheticated via his cert (and the dbms can check if he can effectively connect to *that* particular db).
TLS authorization
Posted Apr 8, 2013 12:44 UTC (Mon) by tialaramex (subscriber, #21167)
[Link]
I don't know specifically about PostgreSQL but generally when you have a single SSL endpoint you make all the "authorization" decisions later, after the SSL handshake is done and you're "secure".
So very likely you can connect to any TLS-supporting PostgreSQL server with proof that you're "A Badman <evil@example.com>" and the server will go try to access the database to determine whether this "A Badman" person is authorized. With this particular bug, that's already too late.
In principle the server _could_ round up all the rules for authorization for all the databases, and then do early reject for connections that don't match, but that would be a lot of extra work to handle a slow path case, and (unless you know about this bug) there's no reason to approach it that way.
A serious PostgreSQL security fix
Posted Apr 7, 2013 23:31 UTC (Sun) by dlang (✭ supporter ✭, #313)
[Link]
SSL/TLS authentication has a very high overhead. Postgresql supports SSL/TLS authentication, but it also supports many other types of authentication so that you can choose what one is the best fit for your needs.
