postgresql

0day advisory alloydb aurora authentication clickhouse cve cyber django exploit extension hacking hll hyperloglog logpoint metasploit middleware neondb paas postgis postgres postgresql product security supabase vulnerability

  • Part 2/6 | Breaking the Postgres Superuser Guardrails: Attacking Security-Hardening Extensions |Systemic Risks in the Managed PostgreSQL Industry

    Part 2/6 | Breaking the Postgres Superuser Guardrails: Attacking Security-Hardening Extensions |Systemic Risks in the Managed PostgreSQL Industry

    It’s been a month since I published the first part of this research, and interest from the Postgres community has been higher than I expected. Most vendors I contacted were shy to respond, so the Databricks team’s blog post Collaboration makes us all stronger was one of the first examples of a vendor publicly sharing their side of the story.

    In the past four weeks, I spoke with managers of managed Postgres services, security engineers, and red teamers who look for new threats in the services they offer. Here’s what I learned from those conversations:

    • None of them had monitoring in place for the shared-buffer-based superuser backdoor technique I described in my first article.
    • Risks from extensions are just as serious as having a zero-day in PostgreSQL core, but no one seems to be focusing on them.
    • Security hardening extensions are meant to stop hackers from attacking the underlying infrastructure and to keep users from misconfiguring their setup.

    My initial plan was actually write about PostgreSQL core vulnerabilities but the coordinated work with the vendors takes longer than I expected. As the time flies and given that I only have a 40-minute talk at PGCONF.EU, there’s simply no way I’ll be able to cover everything I gathered in a single session. So I want to share all the things I wont be able to cover at the talk here as a blog post.

    In this article you will see the vulnerabilities I have found on PostgreSQL vendors’ security hardening extensions and the broader threat model discussion.

    (more…)
  • Part 1/6 | Systemic Risks in the Managed PostgreSQL Industry: Extension Risks Are Real! Exploiting PostGis Memory Corruption Bug at NeonDB, SupaBase and Many More

    Part 1/6 | Systemic Risks in the Managed PostgreSQL Industry: Extension Risks Are Real! Exploiting PostGis Memory Corruption Bug at NeonDB, SupaBase and Many More

    Back in April, I was talking with our system and software engineering teams at PRODAFT about the possibilities of using a managed database service. Due to the nature of our business, we simply cannot start using managed services right away. I told my team, “Alright, I will have a look at a few companies and let’s see how we can start using—more like trusting—these services,” and left the meeting.

    I have a somewhat unconventional approach to vendor selection. Before we seriously consider adopting new open-source projects, I give myself a research window and read the source, which unsurprisingly almost always ends up with me reporting a critical vulnerability to the vendors[1][2]. Old habits die hard.

    A few weeks later, I finally had time to try out different vendors to understand this industry better. Yes, we have been using PostgreSQL ever since I founded Prodaft with my partners more than a decade ago, but I have not reviewed the industry or how they provide those services, especially from a cybersecurity perspective.

    On a lovely Monday morning, a few hours into reading source code and trying things out, I had to tweet the following post because I found a chain of issues that let me reach different customers’ production databases.

    (more…)