
PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released - edwinvlieg
http://www.postgresql.org/about/news/1456/
======
timdorr
The commit that fixes it with a few more details:
[http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitd...](http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a6e0cd7b76c04acc8c8f868a3bcd0f9ff13e16c8)

    
    
        An oversight in commit e710b65c1c56ca7b91f662c63d37ff2e72862a94 allowed
        database names beginning with "-" to be treated as though they were secure
        command-line switches; and this switch processing occurs before client
        authentication, so that even an unprivileged remote attacker could exploit
        the bug, needing only connectivity to the postmaster's port.  Assorted
        exploits for this are possible, some requiring a valid database login,
        some not.  The worst known problem is that the "-r" switch can be invoked
        to redirect the process's stderr output, so that subsequent error messages
        will be appended to any file the server can write.  This can for example be
        used to corrupt the server's configuration files, so that it will fail when
        next restarted.  Complete destruction of database tables is also possible.
    
        Fix by keeping the database name extracted from a startup packet fully
        separate from command-line switches, as had already been done with the
        user name field.
        
        The Postgres project thanks Mitsumasa Kondo for discovering this bug,
        Kyotaro Horiguchi for drafting the fix, and Noah Misch for recognizing
        the full extent of the danger.
        
        Security: CVE-2013-1899

~~~
ashray
I'm really happy that the PostgreSQL team was able to fix this so quickly and
it does appear to be a massive security issue. However, on the flip side, in
13+ years of web development work, I've never really seen a database name
beginning with "-".

~~~
ceejayoz
I don't think you have to have a database starting with - for the bug to work.

~~~
jonknee
No, but thankfully you do need postgres to be accessible remotely.

~~~
achillean
Which is not an uncommon situation actually. I've only started surveying the
Internet for PostgreSQL for a bit more than a day and I've already discovered
more than a hundred thousand (168,031) remotely-accessible PostgreSQL
instances: <http://www.shodanhq.com/search?q=port%3A5432>

~~~
krg
I'm surprised this is so common. I've never set up any database accessible to
the public-- I've already got to worry about securing the public-facing web
server, why add another vector for attack?

~~~
selenamarie
In one case, a large service provider is specifically providing that kind of
database access to their customers.

And to be fair: <http://www.shodanhq.com/search?q=mysql>

~~~
achillean
You get a lot more results if you search for the service/ port directly!
<http://www.shodanhq.com/search?q=port%3A3306>

------
gingerlime
_"Heroku was given access to updated source code which patched the
vulnerability at the same time as other packagers. Because Heroku was
especially vulnerable, the PostgreSQL Core Team worked with them both to
secure their infrastructure and to use their deployment as a test-bed for the
security patches, in order to verify that the security update did not break
any application functionality. Heroku has a history both of working closely
with community developers, and of testing experimental features in their
PostgreSQL service."_

I believe all the heroku hosted postgresql servers are externally accessible
and there's no way to filter access by IP.

Of course hindsight is always 20:20, but perhaps it's a good idea for heroku
to consider adding some basic (optional) firewall layer to allow customers to
control who can connect to the hosted db?

Disclaimer: I'm not a heroku customer. I did however consider moving our pg's
over to them a little while ago.

~~~
thibaut_barrere
I would definitely pay Heroku a bit more to restrict access of a Heroku PG
instance to a given EC2 security group.

I couldn't find a PG hosting provider with more useful features than Heroku -
with that, it would be a killer option.

~~~
fdr
Well, I'll tell you why it is not implemented that way. I hope the restriction
can be lifted some day. I am a member of the Heroku staff related to the
matters at hand.

The problem is the sheer number of Heroku Runtime machines which are located
in a smattering of IP space, and rapidly and accurately propagating the
firewall rules required for tight network access control as applications churn
around in there...even then, there have been some reports of voluminous
firewall rules causing obscure problems. Of course: the world is an obscure
place and yet we can deal with it in time. Such a thing could be hardened I'm
sure, but the amount of bookkeeping required is a bit terrifying, and
experience suggests that will not go entirely smoothly or be easy to find bugs
in. At the time this was reasoned out (maybe about two years ago?), it wasn't
even widely known that Heroku offered any data storage service of
significance. Early days.

So, the simple approach is to enable access from the entire Heroku Runtime
layer. But who can put applications there? Anybody on the Internet. That's why
the 'ingress' feature to poke a temporary hole in the database firewall was
dropped as too marginal given the fairly severe inconvenience of it all -- it
had the feel of a weird Heroku-ism, especially in light of the lack of attacks
using unauthenticated clients on Postgres, until this date. In addition, what
about all the other addons? There would need to be an API, and because of the
nature of what it is doing (poking holes before beginning, say, TLS
negotiation which requires even more round trips and is slow enough as it is)
it would need to be stable, fast, accurate, and all that other good stuff,
lest all addons effectively be rendered offline all at once.

Other more application-level approaches are possible (like tunneling all
connections to a local unix socket, or something), but that's but a little
strange, because it requires code injection of strange stuff into the running
container, makes your URLs look funny, and so on. This model has been
experimented with by some of my colleagues and staff of other, similar firms,
and definitely has its attractive sides. Nevertheless, one of the general
guidelines in our implementation choices is to not be too weird for someone
moving on or off the service. These approaches are also not in and of
themselves immune to DoS or security problems...they need careful auditing.
Maybe another look is indicated. And again: what about every other addon? What
about your local computer? Are you going to install some weird agent, open
source or no, from every such addon?

My personal favorite pie in the sky option right now would be cordon off a
slice of contiguous, publicly addressable (but not publicly _accessible_ ) IP
space so that firewall rules could remain compact and slower changing, and
also involve your local computer: imagine being able to VPN to two or three
such networks simultaneously, because their addressing does not alias at all.
But this is still in the realm of fantasy, and and probably would require
looking at IPv6 to be able to segment the address space in a sane manner,
which compounds another layer of stuff that can be buggy, even in such mundane
details as address parsing.

So....there's some rambling, but I thought it perhaps useful to talk about
some of the challenges here to motivate the discussion.

~~~
fulafel
you can do the IP space thing with IPv6.

~~~
fdr
I think you petered at at the end of my wall of text ;)

But seriously, I'm glad that I was not totally off base in letting my mind
drift to IPv6. Thanks.

------
edwinvlieg
More information about the security release can also be found in the special
FAQ:

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

------
ipsin
I'm a little confused about their release strategy. Perhaps someone can
explain it to me.

They took their repositories private to secretly develop the bug fix. Then
they released the fixed versions along with what seem to be enough details to
trigger the bug for anyone who hasn't patched.

Sure the patch contains the same information in source form, but if they'd
gone light on details while saying "seriously, go get this", there'd probably
be fewer curious vandals trying to delete your database while you're reading
HN.

~~~
mryan
I like to know exactly why I'm updating my database before I apply any
patches. I doubt they could have been sufficiently light on the details, while
still giving admins enough information to decide whether or not to upgrade.

"Apply this patch, don't worry what it does, just do it" is not something I
want to hear from my database vendor :-)

Had the repos remained public, this detailed information would have been
available to a lot more people, a lot sooner. Temporarily "going dark" to work
on the patch seems like an acceptable compromise.

------
facorreia
"This update fixes a high-exposure security vulnerability in versions 9.0 and
later. All users of the affected versions are strongly urged to apply the
update immediately."

------
simon_kun
It's testament to Canonical that Ubuntu 8.04 LTS still gets security patches
backported to 8.3. If you (still) have servers running Hardy, it's 'apt-get
upgrade' time: <http://www.ubuntu.com/usn/usn-1789-1/>

------
Bootvis
I'm not an expert so I'll ask here:

Is there an attack vector if you run PostgreSQL locally, no untrusted users
are able to create connection strings and do not allow remote access?

It seems to be no but I prefer to be sure ;)

~~~
rmc
To be sure, you should upgrade. Why do you not want to upgrade?

~~~
protomyth
[not gp post, but this is a normal situation]

Because some folks need to go through a long, drawn out process to upgrade
internal software and might already have some place in the pipeline to put the
upgrade so it will get tested with everything else.

If its a security issue for your current installation, you go now and hope,
but if it can wait for a release then you do that.

~~~
DrJokepu
It seems to me that even large, overly bureaucratic corporations need a
process in place that allows deploying critical security updates in a
reasonably expedient manner. Is this uncommon?

~~~
mkopinsky
Well, it's only a critical security update if it affects your installation. If
there's a way to protect without a quick rush software upgrade, you may as
well wait until the next scheduled software upgrade.

~~~
vidarh
Exactly. We were prepared for a "quick rush" but when the details were
released we did a combination of nmap to look for any accidentally exposed
Postgres installs + adding explicit firewall rules to reject all traffic on
the related ports (all of them should be rejected by default rules anyway, but
we wanted to ensure none of the ports had been accidentally opened up) "just
in case", and at that point we felt we could take a slower, more measured roll
out of the upgrade. In 5 minutes we were "in the clear" and could breathe a
sigh of relief.

It's still important to apply the udates, as I wrote elsewhere, because it's
one more way someone can mess you up badly if they have managed to penetrate
other parts of our systems, but upgrades no matter how seemingly safe can also
cause problems (fore example I test upgraded one VM that refused to come back
up again afterwards - not Postgres' fault, but a config change someone had
clearly not tested properly).

But in this case, knowing we have blocked the main attack vector means we can
take the time to take a copy of each database VM we run, test apply the
upgrade and verify everything works correctly before applying it live, instead
of rushing it out.

------
calpaterson
Ubuntu repos already seem to have the fix

------
joevandyk
Sorta surprised I don't see people complaining that this release contained
other changes besides the security fix.

Lots of folks complained about that (unintended) ActiveRecord change in Rails
during the last security update.

------
dkulchenko
So if I have no databases that start with "-", I'm not vulnerable? Didn't
quite understand what they meant by that.

~~~
sgift
Just from the quote cited by octo_t I would read that you are still
vulnerable: A malicious database user could craft a _connection string_ which
contains a database name starting with -. There's no hint that the database
has to exist on your server for this to work, so I would read it could be a
complete bogus request and still damage your files.

~~~
qompiler
/* Is this all it takes? */

PQconnectdb("host=127.0.0.1 dbname=-exploit user=postgres password=postgres
port=5432");

~~~
jeltz
Yes, but that wouldn't do anything harmful. Something like dbname="-r
/var/lib/postgresql/9.1/main/pg_clog/0000" would be required to cause any
harm. I have not tested it in practice but that should cause the server to
overwrite the file with log output.

EDIT: They are not overwritten but just appended to.

------
instakill
Should one update the local postgres version? Any write ups on how exactly to
go about it?

~~~
selenamarie
Yes. <http://www.postgresql.org/docs/9.2/static/upgrading.html> , second
paragraph:

 _PostgreSQL major versions are represented by the first two digit groups of
the version number, e.g., 8.4. PostgreSQL minor versions are represented by
the third group of version digits, e.g., 8.4.2 is the second minor release of
8.4. Minor releases never change the internal storage format and are always
compatible with earlier and later minor releases of the same major version
number, e.g., 8.4.2 is compatible with 8.4, 8.4.1 and 8.4.6. To update between
compatible versions, you simply replace the executables while the server is
down and restart the server. The data directory remains unchanged — minor
upgrades are that simple._

------
octo_t
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.

~~~
phillmv
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.

~~~
gcr
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...](http://thehackernews.com/2012/06/cve-2012-2122-serious-mysql.html)

