Semi_Hemi_Demigod@lemmy.world
on 13 Aug 2024 12:52
nextcollapse
Time-of-check Time-of-use (TOCTOU) race condition in pg_dump in PostgreSQL allows an object creator to execute arbitrary SQL functions as the user running pg_dump, which is often a superuser.
And this, my friends, is why you create a separate user to do the backups with read-only privileges.
sun_is_ra@sh.itjust.works
on 13 Aug 2024 12:55
collapse
First thanks for the official link from postgresql
race condition in pg_dump in PostgreSQL allows an object creator to execute arbitrary SQL functions as the user running pg_dump, which is often a superuser
This is serious.
Suppose I - the attacker - create a table somewhere in your DB then I will create a function that drops all tables in the whole database. Now if I try to execute that function, it would fail because I don’t have permission to do so.
So what do I do? I know a script runs as postgres superuser to do full DB backup daily. I use this vulnerability to trick the script into executing my function. Now my function is running in superuser mode.
So, presumably you need to have permission to create the table in the first place, which already strictly limits the scope, or am I missing something?
bamboo@lemmy.blahaj.zone
on 13 Aug 2024 13:15
collapse
My understanding of the sentence is that if pg_dump is executed with privileged permissions, the arbitrary SQL function run at the same time will also run with those permissions. So if you have a nightly cron which does pg_dump with the superuser permission, then it’s possible for someone to run a SQL statement to create a stored procedure using that superuser permission.
So how does that SQL statement make it into the database in the first place?
bamboo@lemmy.blahaj.zone
on 13 Aug 2024 16:26
collapse
I’d imagine that would depend on the deployment and environment. Chaining exploits is not unheard of. Maybe a lazy dev figured it’s easier to stop a devastating SQL injection by just restricting the permissions of the client connecting. Or maybe you have an intern with malicious intentions to destroy your company, but you only gave them read access to the database so you assume they can’t drop tables.
Basically taking the Swiss Cheese Model approach, there may be security gaps in the front line but as long as subsequent lines of defense don’t also have big holes, the risk is minimized.
threaded - newest
So, the bug requires that the attacker can execute pg_dump to compromise the database?
So, they need to have access to the database already, and to pg_dump, presumably on the host?
Why does this have a severity of 8.8?
Why are you linking to some random site and not the postgresql announcement here:
www.postgresql.org/support/…/CVE-2024-7348/
And this, my friends, is why you create a separate user to do the backups with read-only privileges.
First thanks for the official link from postgresql
This is serious.
Suppose I - the attacker - create a table somewhere in your DB then I will create a function that drops all tables in the whole database. Now if I try to execute that function, it would fail because I don’t have permission to do so. So what do I do? I know a script runs as postgres superuser to do full DB backup daily. I use this vulnerability to trick the script into executing my function. Now my function is running in superuser mode.
So, presumably you need to have permission to create the table in the first place, which already strictly limits the scope, or am I missing something?
My understanding of the sentence is that if
pg_dumpis executed with privileged permissions, the arbitrary SQL function run at the same time will also run with those permissions. So if you have a nightly cron which doespg_dumpwith the superuser permission, then it’s possible for someone to run a SQL statement to create a stored procedure using that superuser permission.So how does that SQL statement make it into the database in the first place?
I’d imagine that would depend on the deployment and environment. Chaining exploits is not unheard of. Maybe a lazy dev figured it’s easier to stop a devastating SQL injection by just restricting the permissions of the client connecting. Or maybe you have an intern with malicious intentions to destroy your company, but you only gave them read access to the database so you assume they can’t drop tables.
Basically taking the Swiss Cheese Model approach, there may be security gaps in the front line but as long as subsequent lines of defense don’t also have big holes, the risk is minimized.