101–105 of 105 posts
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 ;)
To be sure, you should upgrade. Why do you not want to upgrade?
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.
Lots of folks complained about that (unintended) ActiveRecord change in Rails during the last security update.
Earlier quoted context omitted.
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
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?
Earlier quoted context omitted.
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?
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.
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.