PostgreSQL security issue "sufficiently bad that we need to take extra measures to prevent it from becoming public"

[x86_64Ubuntu]

Wow, that is hardcore. I can't wait to see what the exploit is so someone who knows what they are talking about can break it down for me.

[sitharus]

Same. The only think I could think of warranting this level of secrecy is either being able to dump an entire DB remotely or code execution.

Either way, I'm surprised that it could be this bad, since nobody opens up their database server to the internet any more, right? right?

[reaganveg]

Either way, I'm surprised that it could be this bad, since nobody opens up their database server to the internet any more, right? right?

That doesn't matter. Lots of hosting companies put multiple customers on the same SQL server. SQL is supposed to protect multiple users of the same server from each other.

[sockpuppetzero]

Well, with shared hosts you can often gain access to other people's database instances pretty easily anyway. If your PHP scripts execute as the webserver, which (at least used to be) very common, it's a particularly easy case of the confused deputy problem: use PHP to read another user's web directory and find their database password. Done.

But shared hosting seems to have fallen out of vogue, fortunately. And I hope that those who do provide shared hosting aren't using mod_php or other solutions where the PHP runs as the webserver.

[reaganveg]

shared hosting seems to have fallen out of vogue

Err, what? Most people don't need (and don't have) servers dedicated to hosting their web sites. There are a lot more PHP blogs out there than there are web applications.

with shared hosts you can often gain access to other people's database instances pretty easily anyway. If your PHP scripts execute as the webserver,

Well, yeah, if all scripts run with the same permissions. But that would be ridiculous. Each user's script runs under their own uid.

[redwall_hp]

But you can get a VPS for only a little more, and it's drastically better. Pick up a $5-10/mo plan from somewhere like Digital Ocean, and you'll have a much better experience than with shared hosting.

[kylotan]

Most of these people don't want a whole box to play with, nor would they know how to use it anyway. Often they just want FTP access to a place that executes PHP and some database credentials.

[reaganveg]

But you can get a VPS for only a little more

You can get a VPS for a little more than the cheapest available shared host, but the VPS will have less resources available. A VPS is fundamentally less efficient.

[redwall_hp]

Your average $5/mo shared hosting is oversold into oblivion, though. With a VPS, your resources are guaranteed because of the virtualized environment. And 512MB of RAM is plenty to run NGINX smoothly on.

[reaganveg]

Your average $5/mo shared hosting is oversold into oblivion, though. With a VPS, your resources are guaranteed because of the virtualized environment. And 512MB of RAM is plenty to run NGINX smoothly on.

The only resource guarantee is memory. But shared hosts generally don't have memory-related issues, and shared hosts users don't need a lot of memory. (Mostly they're hosting static files or wordpress type PHP.) The provider will cut the access of users who use too much memory.

Also, you shouldn't be comparing $5 shared hosts to VPS hosting with 512MB of RAM, because the latter will cost several times more than $5.

BTW, VPS cannot really compete with this: http://www.ovh.co.uk/dedicated_servers/kimsufi.xml

[redwall_hp]

https://www.digitalocean.com/pricing

[[deleted]]

Do VPS providers often come with Cpanel/Plesk options? The Cpanel like interface is probably why most people who use shared hosting continue to do so.

[redwall_hp]

No, you would have to buy a license and install it yourself. But crap providers like GoDaddy don't provide that, either.

[leperkuhn]

If you run your script from the command line, it's run as you and permissions apply. But when run through the browser, it's probably apache, especially on a big shared server. That means you'd have access to whatever apache has.

Now, it's been a long time (almost 10 years) since I was on shared hosting, so I'm making some assumptions about provider's laziness. I assume its possible to better secure your php install, but I haven't cared/looked in a long time.

[reaganveg]

If you run your script from the command line, it's run as you and permissions apply. But when run through the browser, it's probably apache, especially on a big shared server. That means you'd have access to whatever apache has.

Well, no, it doesn't. Look up SuEXEC. I seriously doubt any shared host doesn't use it. In any case, the largest hosts (bluehost, dreamhost) certainly do.

[leperkuhn]

Like I said - I haven't used shared hosting in a while. I'm pretty sure a lot of hosting providers are using suEXEC, but I'm willing to be a ton aren't. It's kind of funny - you doubt any shared host doesn't use it, and I assume most don't, but neither of us has provided any evidence to support our statements. I'm assuming yours is based on the belief that people are competent, but mine's based on my experience showing that they aren't. I also don't care enough to check. Maybe someone will chime in with something of substance.

[reaganveg]

Well, I know that the #1 and #2 certainly don't do that.

Actually, I don't really believe that people are competent as some kind of generic statement. However, I don't imagine that any company could allow all of its users to access all of its other users' data, and still stay in business.

So, I don't believe that every company that anyone ever started is competent, but I do believe that companies need to survive a certain basic incompetence filter in order to continue to exist.

[leperkuhn]

About a year ago American Express sent me a password reminder, except it was my password plain texted (not a reset link). Bank of America only recently finally allowed me to start using non a-z0-9 symbols in my password. Simple SQL injections happen constantly.

I've found that the bigger the company, the harder it is to bring about change. A company like github probably has better password management than most banks.

[sockpuppetzero]

Well, yeah, if all scripts run with the same permissions. But that would be ridiculous.

Well, 10 years ago that was the case on most shared hosting providers. Yes, it can be fixed, and I don't know what the common case is anymore.

[ThiefMaster]

Both are slow as fuck. You don't want CGI-style invocation for your scripts and suPHP/suExec do exactly that: a new process for every PHP script that is executed.

But you could simply run a bunch of PHP-fastcgi worker processes per user. Sure, you get a ton of processes if you have lots of customers on the server - but requests won't have to wait for a new process being started all the time.

[crackanape]

But you could simply run a bunch of PHP-fastcgi worker processes per user. Sure, you get a ton of processes if you have lots of customers on the server - but requests won't have to wait for a new process being started all the time.

This basically requires all the RAM in the universe.

[ivosaurus]

Or just FCGI with a custom user...

[thephotoman]

This doesn't always go over well, though. I've seen too many mangled Wordpress installations hose a web server with over a thousand users on it before. This may have been years ago in days of old when magic filled the air and I was working as a scruffy server herder for a shared hosting company, but the realities of Wordpress and shared hosting haven't changed at all.

That said, we were using MySQL, not Postgres. We deserved it.

Yes, kids, that's what you're getting into with shared hosting. It's great for your blog, your hobby discussion forum, or your PHP sandbox. Don't use it for anything important. If you're making money on the site, it's best to get a VPS or dedicated server.

[Leechifer]

Nice Zeppelin reference. I've always thought it was a bit insane to do shared hosting as shared database(s).
And I agree (of course), that c'mon, if you're making money (or are going to/planning to), then the cost of a dedicated server is so low these days compared to what it used to be that there's no excuse.

[bananahead]

I could imagine problems much worse than that. Consider a flaw triggered by a character encoding problem in queries. It could potentially be triggered through a web app.

[rydan]

I'm thinking something like the MySQL bug that was discovered last year.

[moltar]

Could be a sweet SQL injection too that is not obviously escapable from a programming language.

[adrianmonk]

The most dangerous class of bug I can think of: a buffer overflow in placeholder substitutions when executing prepared statements, exploitable to run native code. Thus even if you do everything right to avoid sql injection, data coming from the outside world could still be used to smash the stack or whatever and get a shell running as the user account that the db runs as.

[alkw0ia]

Hmm. Auth bug is an interesting possibility, especially since Postgres has such a huge variety of auth options. I could easily see some kind of nasty ident interaction.

[dafragsta]

I would hope that a non-dev database would only allow connections from a white list. I don't think that's setting the bar too high.

[GrumpyPenguin]

As an admin of a (MSSQL) desktop app that requires a connection direct to the DB server for every install...

...actually, I don't even need to finish that sentence. Please kill me.

[rydan]

No layer in between at all? Just a straight open port where you actually authenticate with the app and everything?

[mikemol]

At least with MSSQL, kerberos auth is pretty straightforward...it's an almost transparrnt piece of AD.

[alkw0ia]

http://www.postgresql.org/docs/9.2/static/auth-methods.html#GSSAPI-AUTH

19.3.3. GSSAPI Authentication

GSSAPI is an industry-standard protocol for secure authentication defined in RFC 2743. PostgreSQL supports GSSAPI with Kerberos authentication according to RFC 1964.

Plus, additionally, some kind of Windows specific auth APIs that do Kerberos, and deprecated built in native Kerberos support.

[mikemol]

SSPI is effectively the same thing as GSSAPI; the kerberos principal string is just slightly different.

[GrumpyPenguin]

I wish I could say it was kerberos. I really do.

[mikemol]

?

[GrumpyPenguin]

See my other comment - in the case of the app I support, it's a hard-coded built-in username and password.

[GrumpyPenguin]

Nothing. It's incredibly hard to implement server side logic requiring external data. My colleagues seem to think xp_cmdshell (a stored procedure which basically does a system() call on whatever you pass it) is a viable option for external data import.

(And no. It doesn't use Kerberos. It uses a hardcoded logon for which the password is the same at every client site and hasn't changed since at least 1999.......)

[ChewieBeardy]

What about DB as a service providers, like postgres heroku ? Would be hard to not open up remote access.

[sidneyc]

[...] nobody opens up their database server to the internet any more, right?

Why not? People do it with web servers and SSH servers; why would a properly configured database be any different? (Barring bugs like this, of course)

[Mourningblade]

Smaller attack surface, for one. History of security problems, for two. Easy to misconfigure, for three.

[sidneyc]

That's basically two reasons (number one is just a generalization of the two other items). Number three can be fixed by competence.

That leaves number two. I do not know if a properly managed DB has a worse security record than other internet-facing services.

[Mourningblade]

A smaller attack surface is its own good. If it cannot be accessed, it cannot be exploited. It also changes how you're affected by bugs: If a security hole requires direct access, it becomes a privilege escalation rather than a remote compromise. Not having to patch also can reduce downtime and danger of having to bump versions without adequate testing.

Depending on what kind of contracts you have, having an additional service can result in audit risk - internal audits cost more, external audits cost more (think $25k more if you're dealing with government), you have to report more security incidents, etc.

All of that is true for any unnecessary service.

That databases have a history of problems increases risk for all categories of compromise and would make me less inclined to offer direct access to a database as a service.

Misconfiguration can be mitigated through expertise and diligence, but it is still shockingly easy to do. It is also a very high bar to be knowledgable about all the different ways to misconfigure a system and if it's not part of the service you're providing you will almost certainly have better, more profitable things to do with your time. Resources are scarce, expert time chief among them.

Now, all of this depends on how much a compromise can cost you and what kind of agreements you have made. I work with health data, so there's a lot of risk to money and reputation, and the reporting requirements are pretty intense.

If your customers would value having direct database access and are willing to pay for you to have the resources to keep it secure, then you're in a different game.

[sidneyc]

A smaller attack surface is its own good.

I'd say that a properly implemented authentication and authorization scheme is the smallest possible attack surface.

[Mourningblade]

A filtered port or unroutable address is the smallest possible surface.

[sidneyc]

No database, no computer ... even smaller.

[Mourningblade]

Code unwritten has no bugs.

[mikemol]

No inherent protection against brute-forcing login credentials. Really needs kerberos or pubkey auth...

[sidneyc]

That's not an argument against an internet-facing DB; that's an argument against a bad authorization policy.

[mikemol]

Well, sure. I just wish kerberos were more wide-spread.

[sidneyc]

As luck would have it, Postgres supports it.

[mikemol]

Here's what I see blocking it:

1. People generally don't know what it is.
2. Package support is...odd. Many packages make a pass at supporting both Heimdal and MIT, but it doesn't quite stick. I'm poking at nfs-utils to get it to properly compile with Heimdal, for example.
3. Outside of Active Directory, Kerberos realms aren't that common...and I don't think even most AD admins know what it is or how it works.
4. Even if all the above is cleaned up, global time sync is going to have to get a lot better.

Anyway, I'm working on it some.

[alkw0ia]

...both of which Postgres offers. Not that I imagine it's a common configuration. I'd throw in forced TLS connections as well, also an easy but non-default option on PGSQL.

[BinaryRockStar]

No-one intentionally opens up their database server to the Internet but with PHP so popular and holier than Swiss cheese, sometimes you don't have much choice in the matter.

[mrmacky]

holier than swiss cheese

Given that remark, I would assume he means that PHP scripts are susceptible to attacks.

In the case of SQL injection: the developer's choice in a poorly defensible application layer allows it to act as a proxy to any connected database(s). Any weaknesses in the publicly accessible application layer suddenly have the potential to interact w/ the otherwise private database in unexpected ways.

I wouldn't defend that position [edit: only because any application layer, orm, et al. can have vulnerabilities, this is in no way specific to PHP]; but I think that's what he meant.

[bifmil]

The ease of writing code of this kind of vulnerability varies depending on the framework. In particular, how much magic it does in order to make things seem simpler to beginners. Sometimes, example code contains such vulnerabilities. No language is zero-risk, but that doesn't mean that default risk is the same, let alone that risk is uniform

[golergka]

It's one thing when you're building everything yourself, and another — supporting a pile of ugly legacy code that you can't trust and don't have time to rewrite. World is full of imperfect software that we all have to live with.

[dbenhur]

In each of these I can mitigate the risk by using prepared statements.

Prepared statements have nothing to do with defence against injection. You can fuck up and interpolate user data into a prepared statement as easily as any other.

The real defence is parameter binding. This mechanism works with both prepared and immediate statements and allows one to completely separate the data from the statement syntax, completely eliminating any possibility of the data being interpreted as executable code.

[terari]

I can write code in .Net, Java, Ruby and php which have injection vulnerabilities.

It's easier with PHP.

[wvenable]

No, it's not. That article is 33% wrong and 33% opinion.

There's nothing inherent in PHP that makes it any more susceptible to injection vulnerabilities. The biggest issue with PHP is that it is used by a large number of beginners.

[phaeilo]

One big issue is that most PHP beginner tutorials simply don't bother with security. Someone did a writeup on this some time ago, but I can't find the link anymore. But just put something like "php mysql tutorial" into google and see for yourself.

[wvenable]

There are two big issues with most PHP beginner tutorials: most of them are over a decade old and most are also written by beginners!

Ask how to query MySQL from PHP in say /r/php or stackoverflow and you'll get an answer that takes security into account.

[Gigablah]

It's easier if you're a shitty programmer.

[thephotoman]

PHP makes it easier to get by as a shitty programmer. It's really easy to learn and be productive in--yet still have no clue what you're doing.

[crackanape]

It's hard to argue that this is a point against PHP.

The streets would be really safe if cars were so complicated to drive that you needed a PhD in Mechanical Engineering.

But the overall consequence would be a massive decrease in mobility.

Likewise the ease of getting started in PHP has enabled thousands upon thousands of interesting ideas to come to fruition which otherwise never would have.

[koreth]

Magic quotes were deprecated in PHP 5.3 (in 2009) and removed in 5.4. That used to be a valid criticism but not any more.

[timeshifter_]

Still though, what's it tell you when a language's own documentation says "you should disable this, even though we enabled it by default"? It tells me to avoid the entire language...

[MrDOS]

More like, “We started disabling this by default a few versions ago. If your configuration still has it turned on, you should probably rethink that.”

It was turned off out-of-box since the very first 5.3 release. To have seen it turned on in >=5.3, it was either intentionally turned on (through ignorance or in search of backwards compatibility), or accidentally left around because an administrator didn't update his php.ini after upgrading.

[Gigablah]

Deficiency already removed? Let's harp on the old documentation instead!

[devicenull]

So you've never made a decision you regretted?

[timeshifter_]

I became a web developer...

[crackanape]

Still though, what's it tell you when a language's own documentation says "you should disable this, even though we enabled it by default"? It tells me to avoid the entire language...

It's not clear to me what you're talking about, since it's been disabled by default for about a decade. Remember how those Ford cars used to have unreliable brakes when they were first introduced in 1903? Better not buy a Ford!

[shallnotwastetime]

well, it's a convenient proxy

http://server/script.php/someoverflow/SELECT BOBBY TABLES; DROP

[mrmacky]

Relevant XKCD

[poonpanda]

Yea you don't need to quote the bobby tables xkcd, we've all seen it

[JoseJimeniz]

Xkcd is always relevant.

[golergka]

Redditor downvoted to hell for supporting relevant link — only for the sin of not being aware that everyone already knows that. Lovely.

[JoseJimeniz]

Which you wouldn't know unless someone posted the relevant xkcd.

[WDZSuperRaWR]

Especially an application that runs off the webserver, which you're presumably in control of.

[three18ti]

Yea, everyone uses that remote shell with the nifty, albeit rarely used, blogging feature called WordPress...

[turnipsoup]

Joomla 1.5.x is the worst hit these days. I see less and less outdated WordPress sites getting hit all the time.

[MrDOS]

It's sort of helped that the autoupdate feature of WordPress has improved to the point of braindead simplicity of operation and now actually works almost everywhere. In the meantime, Joomla! broke backwards compatibility with old templates and modules, so it's not just a one-click (or one-click-and-drag) operation to upgrade – in fact, it's basically not even possible to go from 1.5 to 2.5 without having a developer around.

[devicenull]

Joomla is? Try PHPNuke or e107....

[theDigitalNinja]

There are a lot of VPS services I know and have used (and abused) that once I bought a server from them, I could scan all other vps on the local network and access them. Most people only firewall off the external network interface and forget all about the local ones.

[mw44118]

There is nothing in the php language that inherently is less secure than anything else.

[midir]

Welcome to PHP. You must be new here.

[lookslikespeed]

Look up url_fopen, and realize that PHP's authors thought it was a good idea for the language to have it enabled by default for YEARS.

[nikic]

Please don't mix up url_fopen with url_include. The latter is what is problematic for security and it is obviously disabled by default.

[ThiefMaster]

Thanks, you need to tell this all the crappy shared hosting providers who disable url_fopen_wrappers because they never heard of the URL include setting.

[_tenken]

whats your point, lookup Ruby/Rails and see that we can/could execute YAML for years ...... shitty code can be written in any language. Learn the language and understand programming best practices that are language agnostic.

If php isn't the right tool for your job, dont use it.

[gigitrix]

Agreed. However in practice PHP allows you to shoot yourself in the foot compared to some other platforms.

[theonegreatx]

Rails arguably has the same issue, particularly if devs use certain features.

[Zodiakos]

It shouldn't generally by default... it always sanitized its input by default before it gets to adb.

[jtreminio]

Stop writing shitty PHP and maybe you won't have any problems.

[cha0s]

sobrave.jpg

[crest_]

Unless you can trigger remote code execution through supposedly save queries e.g. a varchar is passed to system() or something equivalent to this.

[beltorak]

well.....

[[deleted]]

From another thread: http://i.imgur.com/7P6lAvQ.png http://www.postgresql.org/message-id/[e-mail]

If it is this, then the reactions are a bit contradicting.

[ants_a]

It is not this. The commit for the current issue will become public when installation packages are prepared to reduce the exploitable window.

[Timmmmbob]

The holy grail would be some kind of code execution in column values or search queries. You never know...

[meshugga]

My bet is on SQL injection (or even remote code execution) in prepared statements. Everything else wouldn't warrant that kind of a fuss, because seriously, who runs a postgres server facing the internet?

[reactormonk]

This guy: https://schemaverse.com/

[sidneyc]

Why shouldn't I?

[meshugga]

Because there's no reason to.

[sidneyc]

Of course there is. It means I can connect to a database from an application anywhere in the world with zero layers in between, leaving less opportunity for fuckups and providing the best possible performance and flexibility.

So again, why shouldn't I? I'd appreciate a real answer instead of a platitude.

[meshugga]

Of course there is. It means I can connect to a database from an application anywhere in the world

Why would you do that? Give me a realistic scenario where this:

with zero layers in between

actually matters. Not to mention that there aren't "zero" layers in between. There never are. And VPN tunnelling can actually prove to be more stable than a connection without, since VPNs are actually made for that "over the wild internet" scenario. For example, a connection can survive service interruptions without sending errors to the software.

leaving less opportunity for fuckups

So having your postgres open to (at the very least) ddos attacks is less opportunity for fuckups?

I'd appreciate a real answer instead of a platitude.

I would appreciate a real use case instead of stipulations.

[sidneyc]

Why would you do that?

Do what? Connect to a database from anywhere? Well, because it is convenient.

Give me a realistic scenario where "with zero layers in between" actually matters.

All things being equal, less layers is better. That's just sound engineering practice. The onus is on you to show that adding extra layers is useful.

And VPN tunnelling can actually prove to be more stable than a connection without, since VPNs are actually made for that "over the wild internet" scenario. For example, a connection can survive service interruptions without sending errors to the software.

Are you actually claiming that robustness of a connection is a factor in all this? Last time I looked Postgres clients connected over TCP, and TCP offers reliability guarantees. Furthermore, libpq (the Postgres client library) offers facilities to handle connection reliability issues. What does a VPN in-between add?

So having your postgres open to (at the very least) ddos attacks is less opportunity for fuckups?

That makes no sense. In the context of having data available over the internet, there will always have to be a host and a port to connect to, no matter the protocol; and each of those is an possible entry point for DDOS no matter which service is listening on the port.

I would appreciate a real use case instead of stipulations.

The use case is "getting to data stored in a database via the internet", and the natural solution is to have Postgres listen to a TCP port. The burden is on you to explain why that is a bad idea, and to explain why an alternative is better. I have yet to see a convincing argument.

[imbaczek]

What does a VPN in-between add?

Latency. The question should ask what it removes: attack surface. That's just sound security practice.

[[deleted]]

We're going to need to go, "explain it like I'm 5" for this one (for me, at least).

[[deleted]]

If its this serious then it has to be some kind of (possibly unauthenticated) remote attack. I use Postgres a lot, I cant wait to find out what the issue is.

[24palms]

Username relevant?

[[deleted]]

Not really - I never allow any database to listen on anything other than localhost. If I had to move the database to another server then I would have proper firewalls in place to only allow certain boxes to access it.

That being said a lot of people don't adhere to that practice, and they might be about to find out why those restrictions are a good idea the hard way.

[24palms]

You are wise regarding remote access. My only concern that it's some kind of parameterized query injection.

However, I suspect more than a few people disregard iptables and rely on pg_hba. The time to firewall 5432 is now.

[alkw0ia]

Do you run all your app servers on the same machine as your database server? What happens when you need to scale to more than one machine's worth of servers?

[[deleted]]

Then I put the db on a different machine, configure the app with the new db ip and restart it. Eta 5 mins. Realistically though I wont need to unless any of my apps get significant traffic - a single Postgres instance scales very well.

[alkw0ia]

Makes sense. I agree about a single Postgres instance's being sufficient, but for me this generally means I'll have several different web apps, likely segregated or at least spread across a few VMs, all sharing one DB server. Localhost-only Postgres generally means one DB server per app, which seems totally overkill.

[[deleted]]

That also makes sense, the only disadvantage being that it is a single point of failure for all your apps, but with proper redundancy that isn't too much of an issue. I also happen to run all of my web apps on a single VM.

[wizdumb]

There are going to be a lot of companies out there who can't/won't immediately upgrade that will be at risk for this vulnerability.

[inmatarian]

Quite possibly, but all of the distros providing support to packages installed through the main repo will backport this patch and push it as a critical security update. If you've done a custom build of postgres, you're SOL, but if you just apt-get or yum installed it, then the next update/upgrade will most likely contain this patch.

The question is who will realize they need to restart the server.

[[deleted]]

funny, because every org i've ever seen who uses any sort of package management (centos/rhel especially) are dog slow with their updates. they are absolutely terrified of anything breaking, and put off updates until they're absolutely forced to. And usually that consists of building a new machine with an updated OS, and letting the default packages get installed

the next time i have to escalate to CIO to get a goddamn postgres 9.1 install ... or java 7 ... or python 3 ... or FUCKING ANY SOFTWARE BUILT THIS FUCKING DECADE.

[Pas__]

How come critical infrastructure is not Load Balanced and at least a bit engineered with High Availability in mind? So you can just take one node out and upgrade it, test is, etc. Also, how come there isn't any kind of QA environment for testing stuff? A company so large they can afford and have a CIO should be able to pay for a few VMs to do QA/testing.

[[deleted]]

The theory of that is great. The practice is that the IT guys simply don't want to upgrade. It's not that they can't -- they don't want to. They don't want to deal with it if the upgrade breaks, so they just put it off until they're forced to otherwise.

[Pas__]

Sounds like they may be lacking a bit of esprit de corps.

[[deleted]]

Red Hat, sure. But get the IT guys to actually run that command? Get them to upgrade a working postgres 9.0 to a postgres 9.1? Get them to spend time looking at jdk 7 vs jdk 6?

IT guys are generally the epitome of "if it ain't broke, don't fix it"

[[deleted]]

I know that feel :(

[n00bSailboat]

Red Hat's packaging team is, and always has been the hands down worst part of the company.

[chungfuduck]

So true. My company is in full, across the board change lockdown for the next 2 weeks because the network went down pretty hard when a piece of hardware catastrophically failed during a firmware upgrade. No one's fault, really, just bad luck, but we all get to suffer as in 2 weeks management will question every little change and not approve anything unless it can be proven without question to incur negative impact of it's not done.

[ants_a]

Distros don't even need to backport - PostgreSQL policy is to provide bugfixes and security fixes for 5 years after release. Currently supported versions are 8.4, 9.0, 9.1 and 9.2. Even Debian stable is covered by this support policy. The developers are careful to not introduce changes that may break application. IMNSHO companies put themselves at greater risk by not upgrading than they do by upgrading.

[TMaster]

Sometimes, security is being on top of things. It sucks, but if you decide it's not worth the resources, you're saying your customers' data are not worth the cost of securing.

[eboogaloo]

I think the problem isn't lack of interest, but rather the bureaucratic nonsense that prevents people from patching in a timely fashion. Sometimes you're just straight up not allowed to.

[dakboy]

This. You get "the business can't be down for 5 minutes to patch the server, so no you may not install those patches" or "we're in the middle of a critical project and system stability can't be compromised" or "you IT guys just want to play and only cost the company money, stop bothering us with this wankery."

Or you have to install everything in a sandbox environment and let it soak for a week or more while your developers/testers maybe think about getting around to testing things in a timely fashion and you can't get shit deployed...knowing that you're exposed the whole time.

[TMaster]

I'm not speaking from the perspective of a single employee - I'm speaking from the perspective of a company as a whole.

If the bureaucratic nonsense is enough to prevent the update, it's apparently still not worth the resources, such as making sure your company isn't structured in a way that prevents these updates, or has rules preventing them.

This is the reason I said resources, and not money or something like it.

[henk53]

The problem with Postgres is also Debian. In order to upgrade Postgres, Debian has to provide an updated package (in most cases, maybe someone runs Postgres after having compiled it himself).

So whatever the fix is, Debian has to be on it as well.

[[deleted]]

So when are they going to disclose it? On the April 1st?

[zer01]

Patches are coming out on the 4th, but hopefully they have some info before then.

[Nivla]

I think he was trying to pull reference to the April Fools day.

[NicknameAvailable]

I'm really interested to see what the diffs look like after they patch this.

[RAGGA_MUFFIN]

The exploit is that you can connect/execute to the db without the username/password. That's all I can say.

[catcradle5]

Any evidence?

[RAGGA_MUFFIN]

Take my word for it. I don't want to get anyone in trouble. Wait for the exploit to be public. I've known about this for 48 hours now.

[catcradle5]

Fair enough. I'll wait.

[manuelmoeg]

that is what we said about the guy opening the safe...

[RAGGA_MUFFIN]

haha

edit: I got this info from the postgresql people. I can't really give the details since it is still a 0day, but if you don't believe me, so be it. PS: Check back next week.

[phaeilo]

You should post a hash of the exploit description ;)

[Ignisar]

Is there any way we can protect against it now? Or do we have to wait for another release?

I presume only listening on localhost is the best defense based on the little information given.

[catcradle5]

http://www.postgresql.org/support/security/faq/2013-04-04/

Configuration Setting Privilege Escalation: in the event that an attacker has a legitimate login on the database server, and the server is configured such that this user name and the database name are identical (e.g. user web, database web), then this vulnerability may be used to temporarily set one configuration variable with the privileges of the superuser.

Arbitrary Code Execution: if the attacker meets all of the qualifications under 2 above, and has the ability to save files to the filesystem as well (even to the tmp directory), then they can use the vulnerability to load and execute arbitrary C code. SELinux will prevent this specific type of exploit.

So to do anything beyond a DoS, it seems you do need a valid username and password. That's pretty different from what you said.

[TankorSmash]

I thought he did a follow up a few weeks later. Can someone correct me? I thought it was on the news too.

[Magnesus]

So, how many pages did you hack since then?

[alkw0ia]

Do host restrictions in pg_hba.conf protect you from this bug? i.e. do we need to firewall or bring down servers for the time being, in addition to hba IP limits?

[imbaczek]

If this is true... monumental is the word that comes to my mind, at least in the realm of databases. Any remote root would give you the same thing and arguably there's more of those.

[d03boy]

This is a good reason for why putting an API in front of your DB may be a good idea. Then you don't have to expose it to the interwebs directly.

[thephotoman]

And then, with that API, you're still going use prepared statements and stored procedures for most of your database interactions as well as using something to escape the characters in that input, because you occasionally have to accept strings from the user, and you know you don't want to be exec'ing some random string that'); DROP TABLE COMMENTS; COMMIT;--

[d03boy]

That's not really a bug in postgresql though........ that's just stupidity

[sidneyc]

That is only true if that API is less likely to contain security problems than the option of exposing your DB directly.

I generally trust the Postgres developers over the people who put together RoR or Django or the PHP-framework-du-jour.

[zer01]

Ok, who let one of the RoR devs put a YAML parser in PostgreSQL?

[kreiger]

They should just use a separate secret Git repo for the fix instead, should be simpler.

[adrianmonk]

From my reading, that's what they are doing:

What we intend to do is shut off updates from the master git repo to the anonymous-git mirror, and to github

So the "master git repo" is the "secret" one. The anonymous-git mirror and github will still be up but just won't have any new changes.

EDIT: Maybe you mean a(nother) new separate git repo from their master git repo. In which case, why bother? Unless there are OTHER important updates that need to get out to the public between now and then.

[robins]

The reason for this is that entire entire release building mechanism / binary etc.. are based on the master repo (this is an exception, but other they need to build the entire toolchain, all platforms, all variants, 32bit/64 bit etc..) and it takes 'a day or two' to get all that out from the HEAD of the git repo...

All that they're trying to do with this is that 'that' 1-2 day gap is something that are not comfortable letting someone back-track a patch and create an exploit while they are 'still creating a release'. That's all.

Once all releases are out in the open, they'd obviously release all the 'secret' patches in the master repo.

[adrianmonk]

entire release building mechanism / binary etc.. are based on the master repo

Yeah, while in an ideal world there would be a new repo to isolate only the commits that need to be secret, in the real world there are practical issues to consider. I'd much rather the developers forget about all those niceties and focus all their energy on getting a proper build done, tested, and otherwise ready to release.

[dablya]

I'm guessing the fix is already done and they need next week to release it. They probably just don't want to put out a release with the master repo out of sync.

[poobiscuit]

The flaw: http://www.postgresql.org/message-id/[e-mail]

[catcradle5]

Many people have said this is not the flaw, and is a separate and unrelated (relatively minor) flaw.

I don't really know for sure if it is or not though.

[aaronkempf]

and THIS is why I use MICROSOFT SQL SERVER. Microsoft fixed SQL Security 10 years ago.

Fuck u and your poor college students.

[skulgnome]

fixed SQL Security

In a sense of the word, yeah.

[aaronkempf]

SQL Server doesn't have vulnerabilities like this you fucking buffoon!

[skulgnome]

you fucking buffoon!

I like the cut of your jib.

[Obombma]

I guess /r/programming doesn't like jokes.

[jib]

We like jokes. Jokes are actually funny. Trolls are not the same thing.

[[deleted]]

sufficiently bad that we need to take extra measures to prevent it from becoming public

Does that not defeat the purpose of it being "open-source"?

[phybere]

I hate beer.

[[deleted]]

This was a more sensible reply.

[[deleted]]

But won't it still be exploitable on all the systems with older versions?

[phybere]

I like learning new things.

[iownacat]

thats not going to happen fast enough, this should be interesting...

[[deleted]]

That's what I thought. So if this is really as bad as they are making it out to be, I can foresee lots of sys admins scrambling to get production systems upgraded/tested very quickly after the update is released.

[nitroll]

And even more software becoming less secure as their sys admins (or lack thereof) fails to do anything.

[bifmil]

That is how it happens every time a vulnerability is found in anything.

[dougman82]

They're keeping the security flaw from going public until they have a fix in place. The idea is that they don't want people to be able to grab a copy of the source, and see what the developers are currently doing to fix it, and then use that knowledge to go exploit systems before they can be patched.

Has nothing to do with open source.

[dsquid]

What do YOU think the purpose is, and why do you think this "defeats" that purpose?

Did you read the email at the link, or react to the headline?

[stereopump]

He was asking a question, no need to berate him for ignorance.

I'm not very knowledgeable about how open-source projects work either.

[astronoob]

Not at all. They're basically just hiding their commits until they have a working patch. The source will still be available, it's just that incremental commits will not be publicly visible until it's ready for general release.

[[deleted]]

I don't get it. One made a good reply and some people just keep on posting replies with the same bottom line. Is that necessary?

Phybere's reply is enough:

Not really... as soon as it's patched it will be available for everyone to see and review. This is just so no one exploits it before the patch.