• Onno (VK6FLAB)
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    1
    ·
    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
      link
      fedilink
      English
      arrow-up
      3
      ·
      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.

      • Onno (VK6FLAB)
        link
        fedilink
        English
        arrow-up
        4
        ·
        3 months ago

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

        • bamboo@lemmy.blahaj.zone
          link
          fedilink
          English
          arrow-up
          2
          ·
          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.