yesterday at 9:14 PM
Correct me if I'm wrong, but those all look like sql exploits. Don't those already require some sort of authenticated remote access. They are security issues, but calling them remote code exploitation make them seem more dangerous than they are.
These seem more like privilege escalation, you have access through a database account and use that to gain full access to the whole server. So an issue for multi-tenant databases mostly.
yesterday at 10:10 PM
You can do authentication and authorization inside sql. For example you could have something like
CREATE ROLE initial LOGIN NOINHERIT NOCREATEDB NOCREATEROLE NOSUPERUSER;
SET LOCAL ROLE someuser;
yesterday at 10:39 PM
that requires additional privelages plus login.. I agree with the pp, sensationalism
yesterday at 9:26 PM
ppl host open Postgres instances, one I can think of is https://postpass.geofabrik.de/ where you can query OpenStreetMap data in a Postgres instance exposed over plain HTTP API
yesterday at 10:55 PM
Wow, that is... I would have never believed in such a thing.
yesterday at 9:19 PM
It's RCE even if it's not pre-auth.
yesterday at 8:47 PM
I would call this more of a privilege escalation attack than RCE.
yesterday at 11:32 PM
Wow, in my mind this is beyond “code smell” and into code reek!
According to the article, Postgres has an internal Datum that might be a pointer or not a pointer. Okay, this is already a bit risky.
Datum comes along with a small-integer type id. That id is stored separately, presumably for efficiency? Maybe you have lots of Datums and one id and you do this for efficiency. Okay, as long as there is a clear story for why the id stays correctly bound to the datum. The “internal” thing where a bogus AST will cause type confusion makes me think the story here isn’t great.
But then I learn that the type id is something that the code looks up in a system table in the database. I’m speechless. This is the kind of thing that can’t be represented in any safe language because the indication of whether a value is a pointer isn’t even in application memory.
Eww. Maybe the AIs can exhaustively enumerate every code path that might get it wrong and rule them all out in a particular release. Maybe there’s even a Lean program that can verify it. But this is still the kind of design that is wrong by construction and is only okay if every single detail avoids the giant foot-cannon.
today at 12:07 AM
its an abstraction in the software architecture
today at 12:07 AM
> This is the kind of thing that can’t be represented in any safe language because the indication of whether a value is a pointer isn’t even in application memory.
Welcome to the wonderful world of high performance low level optimization.
Storing type ids everywhere would double the size small fields and quadruple tiny ones like booleans. It’s also not necessary for most persisted data as you know the columns for a table.
Smaller representation makes reading and writing faster, and it also makes more data fit in memory.
yesterday at 9:26 PM
yesterday at 7:56 PM
Thanks for actually sharing your path to the zero-day. The context and story helps
yesterday at 8:28 PM
Is this exploitable? If it is, this is very serious and if this is an unpatched disclosure millions of Businesses around the world will be affected.
yesterday at 8:39 PM
Yes, once you have logged in on a primary.
yesterday at 8:46 PM
Isn't that only true if "millions of businesses" choose to hang their PG port out on the Internet with "allow 0/0"? In the spirit of being constructive, https://www.shodan.io/search?query=postgresql shows 516,000 which is definitely not none but pretty far from millions and based on skimming the results pretty far from the businesses part, too
yesterday at 9:02 PM
I would consider it a more useful lateral movement vector inside an existing org than anything else. Lots and lots of old postgress with weak acls inside networks.
yesterday at 6:22 PM
[flagged]
yesterday at 8:13 PM
[flagged]
yesterday at 8:44 PM
Amazing write-up. A great look at DB internals and your thought process.