User: Password:
|
|
Subscribe / Log in / New account

A serious PostgreSQL security fix

A serious PostgreSQL security fix

Posted Apr 4, 2013 15:08 UTC (Thu) by FranTaylor (guest, #80190)
Parent article: A serious PostgreSQL security fix

> This is as true, or more true, of other database systems as it is of PostgreSQL.

PRETTY CLASSY, taking pot shots at other database vendors while simultaneously eating crow.


(Log in to post comments)

A serious PostgreSQL security fix

Posted Apr 4, 2013 15:34 UTC (Thu) by dskoll (subscriber, #1630) [Link]

Yes, the This is as true... sentence was gratuitous.

Overall, though, I think the Pg team handled this pretty well. It's a bone-headedly stupid bug, but sh*t happens even to the best of us. Now I realize the Pg developers are only human rather than super-human. :)

Can you tell I really like PostgreSQL?

A serious PostgreSQL security fix

Posted Apr 4, 2013 15:47 UTC (Thu) by ortalo (subscriber, #4654) [Link]

I do like PostgreSQL (a lot) too. However, such a recommendation more or less means: do not trust RDBMS implementations for security in their database software.
(Not even mentioning database applications security - usually not even relying on database-level user ids.)
Well, if your data does not deserve security, does it really deserve a RDMBS? I'd rather the Pg team *simply* acknowledge that they are sometimes doing mistakes and handling them responsibly (as they did). That makes them more trustable and differentiates them a lot from other RDBMS implementations (esp. proprietary ones).
On the contratry such comments do not make them more trustable in the eye of actual security conscious users. IMHO, database administrators should first find what is good for the host system security by themselves - not following random advice from the Internet (even if coming from the RDBMS developpers themselves).

A serious PostgreSQL security fix

Posted Apr 4, 2013 15:52 UTC (Thu) by dskoll (subscriber, #1630) [Link]

However, such a recommendation more or less means: do not trust RDBMS implementations for security in their database software.

I don't read it that way. Rather, I interpret it as: "Defense in depth is a good idea."

A serious PostgreSQL security fix

Posted Apr 4, 2013 18:20 UTC (Thu) by alogghe (subscriber, #6661) [Link]

Agreed. Restricting connections to a specific network is DBA 101.

You are just bad if you aren't doing that already.

Restricting RDBMS network access

Posted Apr 5, 2013 12:05 UTC (Fri) by tialaramex (subscriber, #21167) [Link]

Sadly it's made harder than it really needs to be. For example, we have a bunch of MySQL servers that are actually only used by Java processes running on the same machines. There's no need for these MySQL servers to be accessible over the network at all and we could disable that altogether. Except it seems the Java MySQL connector doesn't _do_ Unix sockets, so they have to talk TCP/IP anyway and we're obliged to explicitly firewall the machines off to get where we ought to be from a security POV.

I see that MySQL's TLS/SSL functionality default to "disabled" too. So out of the box you're going to be tempted to do unencrypted, unauthenticated TCP/IP query sessions over the Internet.

Restricting RDBMS network access

Posted Apr 5, 2013 12:14 UTC (Fri) by dskoll (subscriber, #1630) [Link]

Except it seems the Java MySQL connector doesn't _do_ Unix sockets, so they have to talk TCP/IP anyway

On Debian at any rate, PostgreSQL listens on a TCP socket, but it's bound to 127.0.0.1 by default. Why can't MySQL do the same thing?

Restricting RDBMS network access

Posted Apr 5, 2013 12:48 UTC (Fri) by anselm (subscriber, #2796) [Link]

MySQL can do this in principle, but it's not completely trivial. You need to specify the host by IP address (127.0.0.1); if you just put »localhost« the client library will go for the Unix-domain socket even though it looks as if it is using TCP/IP.

The other problem is that the MySQL server will listen to either all of its host's IP addresses or else one single IP address. This means that if you configure it to listen on 127.0.0.1 you don't get to specify another address, e.g., of an internal »bridged« network for virtual machines. This is admittedly a minor inconvenience but still a hassle to work around.

Restricting RDBMS network access

Posted Apr 5, 2013 17:59 UTC (Fri) by dskoll (subscriber, #1630) [Link]

You need to specify the host by IP address (127.0.0.1); if you just put »localhost« the client library will go for the Unix-domain socket even though it looks as if it is using TCP/IP

Not the Java library, surely, which only does TCP sockets?

The other problem is that the MySQL server will listen to either all of its host's IP addresses or else one single IP address.

Well yes, that is a defect. But if MySQL already supports listening on two sockets (TCP and UNIX-domain) I can't imagine it would be that hard to modify it to support a list of bind addresses.

Restricting RDBMS network access

Posted Apr 5, 2013 17:05 UTC (Fri) by butlerm (guest, #13312) [Link]

> Except it seems the Java MySQL connector doesn't _do_ Unix sockets, so they have to talk TCP/IP anyway

That really isn't MySQL's fault. Java doesn't support Unix sockets, and they don't want to, on portability grounds. Several years back they removed support for reading environment variables for the same reason. It is a least common denominator thing.

Restricting connections? Always :-).

Posted Apr 7, 2013 9:40 UTC (Sun) by walex (subscriber, #69836) [Link]

«Restricting connections to a specific network is DBA 101.»

That's one of the most universally true statements ever:

* Restricting connections to HTTP server port 80 and port 443 to a specific network is webadmin 101.

* Restricting connections to DNS server port 53 to a specific network is hostmaster 101.

And so on! Let's call this Mordac's Rule.

Not allowing the end users to access a DBMS at all, or only indirectly via a front-end application or web UI can be supported by the following arguments:

* Not providing a service is an excellent security idea. The disconnected computer is more "secure", and the powered off one is even more "secure".

* Providing a service via a front-end is much more "secure" than providing it via the base tool itself: because experience shows dramatically how much more "secure" PHP/... based application or web UI front-ends are than their DBMS back-ends.

* Regardless of the above points, insisting that all DBMS instance access be via front-ends and then only allowing those front-ends to connect to DBMS instances means delegating accountability for security issues to the front-end owners, and can be a career-security enhancing measure too for the DBMS owners, not merely enhancing overall system security by protecting a weak DBMS with a strong front-end.

:-) :-) :-)

Restricting connections? Always :-).

Posted Apr 8, 2013 13:26 UTC (Mon) by ortalo (subscriber, #4654) [Link]

Yep, but this is business 101 (equivalence with career 101).

At security 101, now I teach that an incorrect security measure is worse than no security measure at all. (Demo.hint: every security measure has a cost...)

However, business 201 reacted promptly by adjusting their security requirements to match the mechanisms chosen in first year. I never understood why they did not take advantage of the productivity enhancement offer? (Maybe because, in the end, they know how to treat security the same ways as documentation...)

Restricting connections? Always :-).

Posted Apr 9, 2013 1:24 UTC (Tue) by dskoll (subscriber, #1630) [Link]

Providing a service via a front-end is much more "secure" than providing it via the base tool itself:

Well of course it isn't. But allowing access via a front-end and direct database access is by definition less secure than only allowing the front-end because there's a larger attack surface to exploit.

A serious PostgreSQL security fix

Posted Apr 5, 2013 13:24 UTC (Fri) by FranTaylor (guest, #80190) [Link]

How do you interpret the "more true" part other than "they are even worse than we are"?

A serious PostgreSQL security fix

Posted Apr 8, 2013 13:39 UTC (Mon) by ortalo (subscriber, #4654) [Link]

We understood the same but I did not comment especially on that part; I find that part pretty inelegant...

A serious PostgreSQL security fix

Posted Apr 5, 2013 16:36 UTC (Fri) by drag (subscriber, #31333) [Link]

> I do like PostgreSQL (a lot) too. However, such a recommendation more or less means: do not trust RDBMS implementations for security in their database software.

Given the history of RDBMS software security I think this is a very accurate statement.

A serious PostgreSQL security fix

Posted Apr 5, 2013 16:48 UTC (Fri) by andresfreund (subscriber, #69562) [Link]

There, I corrected it for you:
> Given the history of software security I think this is a very accurate statement.

;)

A serious PostgreSQL security fix

Posted Apr 8, 2013 13:34 UTC (Mon) by ortalo (subscriber, #4654) [Link]

Maybe today. But I'd expect the PostgreSQL team to highlight an ambition to reorient that trajectory.
After all, databases is where there is the most need about data security and where there is no serious competitor with such an ambition.
Don't they call that a "quick win" at business 101? ;-)

A serious PostgreSQL security fix

Posted Apr 8, 2013 8:25 UTC (Mon) by nix (subscriber, #2304) [Link]

Well, if your data does not deserve security, does it really deserve a RDMBS?
Since RDBMS's are about the model used to access the data rather than its sensitivity, this question is less rhetorical than non sequitorial.

A serious PostgreSQL security fix

Posted Apr 8, 2013 13:59 UTC (Mon) by ortalo (subscriber, #4654) [Link]

First a warning, my english/french dictionnary has not been able to translate your last word so I am still speculating on your last word meaning. (If you can enlighten me...)

What I meant (you probably caught it) is that if your data is worth the modeling effort as well as the investment in tooling to actually implement that model in a software engine; it is probably also worth a few cents of thinking about its security needs as it seems to me it is very probable that it has some.

Furthermore, it seems to me that permissions and access rights are also pretty suitable to database modeling (and latest efforts in database features seem to support that view - look at SQL GRANT or latest candidate patches - especially in PostgreSQL).

So, all in all, the reason for not investing in RDBMS data security are currently pretty much twofold IMHO:
1- lack of funding to do that work: well that's another story and not specific to databases;
2- fear that the unsecurity of the RDBMS engine itself would undermine such an investment anyway.

I am just trying to fight that second item. Not all RDBMS engines exhibits so many vulnerabilities. (Well, maybe, but nothing so desperate as to give up on 1 all the time...)

A serious PostgreSQL security fix

Posted Apr 8, 2013 16:46 UTC (Mon) by patrick_g (subscriber, #44470) [Link]

> First a warning, my english/french dictionnary has not been able to translate your last word so I am still speculating on your last word meaning.

Because it's in latin !
http://en.wikipedia.org/wiki/Non_sequitur_%28logic%29

A serious PostgreSQL security fix

Posted Apr 10, 2013 19:30 UTC (Wed) by nix (subscriber, #2304) [Link]

That all makes sense -- however, there are a *lot* of systems out there which run huge old relational databases with, ahem, incrementally evolved data models shall we say, which often lump everyone into the same security bucket (so anyone who can access the DB programmatically can do anything) and implement all access restrictions in frontend code, or if you're very lucky might have two layers of security and no more.

This is not theoretical: every single thing I ever worked on in the City of London had one of these "security" models (oh, just to be more amusing, in some of them the access control was governed by passwords hardwired into source code and thus could not be changed). Security was provided by physical security for the machines, sometimes, and by a firm belief that big banks were invulnerable and checkbox security audits flawless on the other.

A serious PostgreSQL security fix

Posted Apr 11, 2013 16:02 UTC (Thu) by ortalo (subscriber, #4654) [Link]

"incrementally evolved data models": thanks for the late Thursday laugh!
This designation idea is pretty well found. The evolutionary process often progresses via trial and error (well, maybe this is not the next viable mutant, but it is certainly more resistant than initially thought...).

Certainly, this is not a theoretical situation. A workable path out of such a situation would be a nice gift from the open source database community to all database users, and it would certainly not benefit only to security. But I am still wondering how to do that while avoiding an initial whole species extinction (and its associated cohort of griefs).

A serious PostgreSQL security fix

Posted Apr 4, 2013 15:49 UTC (Thu) by cesarb (subscriber, #6266) [Link]

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.

A serious PostgreSQL security fix

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 (subscriber, #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]

It doesn't?

A serious PostgreSQL security fix

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 (subscriber, #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.

A serious PostgreSQL security fix

Posted Apr 4, 2013 20:32 UTC (Thu) by geofft (subscriber, #59789) [Link]

Sorry, I don't read that as a pot shot -- it's just a clarification on standard expectations for the severity of a security flaw. Otherwise the complaint would be "PRETTY CLASSY, not owning up to a design flaw in Postgres."

A serious PostgreSQL security fix

Posted Apr 4, 2013 22:41 UTC (Thu) by price (guest, #59790) [Link]

The "good general rule" comment is the clarification you describe.

Saying other unnamed database systems are worse -- in that they may have more of exactly the kind of flaw the PostgreSQL developers had here -- is unhelpful and makes them sound childish and defensive. Red Hat doesn't warn about Windows security in an RHSA.

A serious PostgreSQL security fix

Posted Apr 5, 2013 8:18 UTC (Fri) by mbanck (subscriber, #9035) [Link]

That comment was taken from the FAQ corresponding to the security alert, not the alert itself.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds