34
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 13 Aug 2024
34 points (100.0% liked)
Cybersecurity
5754 readers
91 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
- Be respectful. Everyone should feel welcome here.
- No bigotry - including racism, sexism, ableism, homophobia, transphobia, or xenophobia.
- No Ads / Spamming.
- No pornography.
Community Rules
- Idk, keep it semi-professional?
- Nothing illegal. We're all ethical here.
- Rules will be added/redefined as necessary.
If you ask someone to hack your "friends" socials you're just going to get banned so don't do that.
Learn about hacking
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
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.