34
you are viewing a single comment's thread
view the rest of the comments
[-] vk6flab@lemmy.radio 13 points 3 months ago

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:

https://www.postgresql.org/support/security/CVE-2024-7348/

[-] Semi_Hemi_Demigod@lemmy.world 7 points 3 months ago

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 7 points 3 months ago

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.

[-] vk6flab@lemmy.radio 2 points 3 months ago

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 3 points 3 months ago

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.

[-] vk6flab@lemmy.radio 4 points 3 months ago

So how does that SQL statement make it into the database in the first place?

[-] bamboo@lemmy.blahaj.zone 2 points 3 months ago

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.

this post was submitted on 13 Aug 2024
34 points (100.0% liked)

Cybersecurity

5754 readers
108 users here now

c/cybersecurity is a community centered on the cybersecurity and information security profession. You can come here to discuss news, post something interesting, or just chat with others.

THE RULES

Instance Rules

Community Rules

If you ask someone to hack your "friends" socials you're just going to get banned so don't do that.

Learn about hacking

Hack the Box

Try Hack Me

Pico Capture the flag

Other security-related communities !databreaches@lemmy.zip !netsec@lemmy.world !cybersecurity@lemmy.capebreton.social !securitynews@infosec.pub !netsec@links.hackliberty.org !cybersecurity@infosec.pub !pulse_of_truth@infosec.pub

Notable mention to !cybersecuritymemes@lemmy.world

founded 1 year ago
MODERATORS