8 ms·
PostgreSQL 9.2.4, 9.1.9, 9.0.13 and 8.4.17 released
- facorreia 14y ago"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."
- deleted 14y ago[deleted]
- 16s 14y agoDebian has it. I assume Ubuntu does as well... at least for the 8.4 version. --- PostgreSQL 8.4.17 on x86_64-pc-linux-gnu, compiled by GCC gcc-4.4.real (Debian 4.4.5-8) 4.4.5, 64-bit
- vacri 14y agoWe have two Ubuntu 11.10 servers (decommissioning soon!) that previously contained 9.1.3 and have just had this 9.1.9 version updated from the repos.
- Roarster 14y agoIt worked for me on Ubunutu - maybe it takes a bit of time to get around to all of the mirrors.
- phillmv 14y agoYou are correct, and now I have egg on my face: http://www.ubuntu.com/usn/usn-1789-1/ http://www.ubuntu.com/usn/usn-1789-1/ I was going purely by the changelog in: http://packages.ubuntu.com/precise/database/postgresql-9.1 http://packages.ubuntu.com/precise/database/postgresql-9.1 http://packages.ubuntu.com/precise-updates/postgresql-9.1 http://packages.ubuntu.com/precise-updates/postgresql-9.1
- icebraining 14y agoUbuntu 12.04 already has the new package version of 9.1. Your mirror may be outdated (we use the Portuguese default).
- nodata 14y agoThis is terrible advice. Installing another postgres binary from a different source is likely going to cause you headaches. And it's not necessary - vendors such as Red Hat and Debian are fast with security updates. Given that Red Hat helped them apply for the CVE the non-version-9 fixes should be out PDQ. You can keep an eye on it here: https://access.redhat.com/security/cve/ https://access.redhat.com/security/cve/
- phillmv 14y agoIt worked just fine but seeing as I was wrong I have deleted the post.
- deleted 14y ago[deleted]
- dkulchenko 14y agoSo if I have no databases that start with "-", I'm not vulnerable? Didn't quite understand what they meant by that.
- sgift 14y agoJust 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 14y ago/* Is this all it takes? */ PQconnectdb("host=127.0.0.1 dbname=-exploit user=postgres password=postgres port=5432");
- jeltz 14y agoYes, 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.
- jsaxton86 14y agoFrom the FAQ originally shared by edwinvlieg, you are still vulnerable: The vulnerability allows users to use a command-line switch for a PostgreSQL connection intended for single-user recovery mode while PostgreSQL is running in normal, multiuser mode. This can be used to harm the server.
- masklinn 14y agoNope. Looking at the release notes: > Fix insecure parsing of server command-line switches (Mitsumasa Kondo, Kyotaro Horiguchi) So I assume command-line switch parsing is somehow involved in parsing the connection string (probably because the same connection strings can be used from API and from CLI?), I guess a database name with a leading `-` can be interpreted as a switch and execute corrupting commands. edit: according to the dedicated FAQ: > The vulnerability allows users to use a command-line switch for a PostgreSQL connection intended for single-user recovery mode while PostgreSQL is running in normal, multiuser mode. This can be used to harm the server.
- octo_t 14y agoThis 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.
- r4vik 14y agodefense in depth though, users shouldn't be able to craft connection requests to begin with
- deleted 14y ago[deleted]
- SoftwareMaven 14y agoThen how would a user use the db? Not every use of a database is behind a web application.
- icebraining 14y agoWell, once could use something like spiped[1], which would add a very large roadblock to any attacker. [1]: http://www.tarsnap.com/spiped.html http://www.tarsnap.com/spiped.html
- nmcfarl 14y agoThis 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.
- edwinvlieg 14y agoMore information about the security release can also be found in the special FAQ: http://www.postgresql.org/support/security/faq/2013-04-04/ http://www.postgresql.org/support/security/faq/2013-04-04/
- Bootvis 14y agoI'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 ;)
- mark_l_watson 14y agoI would like an answer to this, quickly, also. I am scheduled to leave on a 6 hour hike in one hour - I have time to update if I have to. I only permit localhost connections.
- talkingquickly 14y agoFrom the FAQ: Who is most at risk: "Any system that allows unrestricted access to the PostgreSQL network port, such as users running PostgreSQL on a public cloud, is especially vulnerable. Users whose servers are only accessible on protected internal networks, or who have effective firewalling or other network access restrictions, are less vulnerable." So looks like it's low risk but they're not willing to say no risk.
- vidarh 14y agoThe reason they are not willing to say no risk is presumably that if you don't upgrade, then any other security vulnerability that allows an attacker to trigger a network connection with a suitable payload to port 5432 (or any other ports you may have Postgres on) on your hosts could still be harmful. That means anything that gives local shell as any user that run normal tools, but potentially also a lot of other things. E.g. any software that can be tricked to try to connect to a local address/port pair and send a suitable string. That dramatically escalates any minor little hole that might otherwise not be a risk for you. (That's a reminder to always verify before trusting any hostname/IP a user passes you that it's not a local address or address you have privileged access to, and to also consider internally firewalling connections between your various hosts down to just what you need)
- Intermernet 14y ago
- gingerlime 14y ago"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 14y agoI 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.
- mryan 14y agoIt certainly seems feasible with the use of VPC and Security Groups. At the very least I think they should offer an option that only you to restrict access so only your dynos have access to the postgres port.
- thibaut_barrere 14y agoI'd love to use it with any EC2 installation (EngineYard, stock EC2 etc). If only they could limit access to EC2 security groups, it would be amazing.
- mryan 14y agoThat would be great. Security Groups work across accounts, so Heroku (or whoever) could let you provide your account ID and Security Group name, then authorise access from this group.
- ipsin 14y agoI'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 14y agoI 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.
- sophacles 14y agoNot really, any big project has people going over every commit to see what changed. Any commits that are associated with a security release are particularly scrutinized. Within an hour of release there would already be people talking about the vulnerability, as well as example code for triggering it. Full disclosure is better, because even if people can't do an upgrade, they can choose to block ports at firewalls, turn off databases, and other mitigation methods immediately, as they are allowed to. Hiding the information just weakens the defender position, not the attacker position. Secrecy in implementation is not security, it is just stupidity.
- keypusher 14y agoTake a lesson from open source, security through obscurity does not work. Better to be fully transparent and honest about the flaws and their fixes, and get the word out there so that people update their boxes quickly.
- mkopinsky 14y ago
- timdorr 14y agoThe commit that fixes it with a few more details: http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a6e0cd7b76c04acc8c8f868a3bcd0f9ff13e16c8 http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitd... 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 14y agoI'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 "-".
- calpaterson 14y agoUbuntu repos already seem to have the fix
- instakill 14y agoShould one update the local postgres version? Any write ups on how exactly to go about it?
- selenamarie 14y agoYes. http://www.postgresql.org/docs/9.2/static/upgrading.html 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.
- instakill 14y agoShould one update the local postgres version? Any write ups on how exactly to go about it?
- simon_kun 14y agoIt'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/ http://www.ubuntu.com/usn/usn-1789-1/
- martinced 14y ago"...containing a database name that begins with '-'..." And some people are laughing at me when I establish guidelines mandating (and enforcing in build scripts) very script rules as to precisely which subset of ASCII is allowed in filenames / identifiers / etc. in our codebase and in the builds we're producing.
- joevandyk 14y agoSorta 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.