CyberWire Daily - A fine pearl gone rusty. [Research Saturday]

Episode Date: November 8, 2025

Tal Peleg, Senior Product Manager, and Coby Abrams, Cyber Security Researcher of Varonis, discussing their work and findings on Rusty Pearl - Remote Code Execution in Postgres Instances. The flaw could allow attackers to execute arbitrary commands on a database server’s operating system, leading to potential data theft, destruction, or lateral movement across networks. While the vulnerability existed in PostgreSQL, Amazon RDS and Aurora were not affected, thanks to built-in protections like SELinux and AWS’s automated threat detection. Still, the research underscores the importance of patching and configuration hygiene in managed database environments. The research can be found here: ⁠⁠⁠⁠Rusty Pearl: Remote Code Execution in Postgres Instances Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyberwire Network, powered by N2K. At TALIS, they know cybersecurity can be tough and you can't protect everything, but with TALIS, you can secure what matters most. With TALIS's industry-leading platforms, you can protect critical applications, data and identities, anywhere and at scale with the highest RR. That's why the most trusted brands and largest banks, retailers, and health care companies in the world rely on TALIS to protect what matters most. Applications, data, and identity. That's TALIS.

T-H-A-L-E-S. Learn more at talusgroup.com slash cyber. Hello, everyone, and welcome to the CyberWires Research Saturday. I'm Dave Bittner, and this is our weekly conversation with researchers and analysts tracking down the threats and vulnerabilities, solving some of the hard problems and protecting ourselves in our rapidly evolving cyberspace. Thanks for joining us. So Rusty Burles is actually

just from the languages that the vulnerability uses, right? The vulnerability is in two language extensions in Postgres, and those language extensions are rust and pearl. So if you're imagining, you can either imagine, like, you know, a rusty pearl kind of like, think Pirates of the Caribbean, or you can imagine the language extensions, the different syntaxes and whatnot. Our guest today are Tal Pellig, senior product manager and Kobe Abrams, Cybersecurity researcher at Veronis.

The research we're discussing is titled Rusty Pearl, Remote Code Execution in Postgres instances. Tal, could you walk us through what remote code execution vulnerabilities mean when it comes to Postgres and what that means for organizations? Sure. So at Postgres database, usually you can execute queries on them. Sometimes you have a web application or some other thing. That's running a query on the data that you put in your database. But that database is hosted on some system. And actually, what a remote code execution, in this case, what it let us do is actually run commands on the underlying system. So let's go through the journey of discovery here. But what led you down this path of exploration? So I was looking at a ticketing service for just understanding how to secure it in our platform and also trying to look for vulnerabilities since these are less explored areas. Most people, most companies look at maybe file storage or,

virtual machines, containers, workloads. And we thought, well, ticketing systems, they have all the stuff that's happening inside the company. People are sending information to one another, maybe about customers, maybe these contain sensitive data, maybe a customer is asking a question, and their question contains some sort of sensitive data. So this place is a treasure trove of sensitive information.

And so I was looking at one of these ticketing systems, and I found a SQL injection. And it was a pretty major SQL injection. And I thought, well, what would happen if I was an attacker? What impact could I have done? And so I set up a Postgres instance on AWS RDS, which is where this ticketing system was hosting its own database. And I just wanted to see what image. I could do with just a database. And so what I noticed is that AWS provides us

with an administrative user, but not a super user. So a super user in a database is able to control the entire database, change settings, even run commands on the system. But this user is not a super user, and they cannot run commands on the system, they cannot open sockets, they can't access files on the system, apart from very, very specific, files. And so what I was trying to do is find a way to escape that and either

escalate privileges to a to a super user or in some other way front commands on the system. Well, take us down that path. How did you go at this question that you'd asked yourself? So I started by looking at extensions. And extensions are a place that are sometimes not tested as heavily. So the database itself is open source. Lots of people have been looking at it. It exists since the, I don't know, since when it exists for a long time. Postgres is one of the more well-known databases,

and hopefully that means it's pretty secure. But third-party extensions can be less rigorously tested, not tested in all the same environments that the database was tested in, maybe interactions between different extensions, since they're usually not tested together, all of the different combinations that you can make. So I was looking at extensions. one extension that had a vulnerability for accessing files is a logging extension, something that I've noticed, but someone already disclosed it before I was able to.

But I continued looking at extensions, and I was thinking, okay, functions, triggers, maybe something that I can cause the super user to run in order to bring me higher privileges. So I was looking at functions, I was looking at extensions. I thought, well, there are language extensions. And then one that caught my eye is Pearl, since Pearl exists in the Postgres repo.

So it's an official language. It's also open source. It probably exists in lots of Postgres installations. And so it would be pretty impactful to find something there. And also, Pearl is from the 80s. So there's a lot of code written in Pearl. That's before security was really, or code security was really popular. People didn't really think about all the vulnerabilities and privacy and data security.

So I was looking at Pearl. And Pearl has an interface to, to manage environment variables. And managing environment variables is one of the things that only a super user should be able to do. So I thought well, maybe this interface, which is

a magic variable in the function, would let me modify environment variables. And it turned out to be true. So I was able to set environment variables. And then I was looking for

some way I could use those environment variables in order to run code. And I looked specifically at extensions that were allowed in AWS-R-D-S-O-R-D-S-O-R-A. Or A-W-S-O-R-A. And I actually wasn't able to find anything. And I put that aside for a little while,

and then I got Kobe up on the team. Kobe, do you want to jump in here and describe your contributions? So when Tal told me that he has this primitive, I was really excited. It sounds really cool. But Postgres kind of makes it difficult to execute code using environment variables because as an extension, when you create a new process as an extension in Postgres,

you actually have an API that Postgres gives you to, create that process and you're not creating it as a child of your own. So it's not taking those environment variables that you've edited in Perl and then creating the process with them, which makes it difficult because the processes that you're now creating have their own environment variables that aren't edited. So what we looked for was an extension that creates processes directly without using this API, right? So it's doing something that it's not really supposed to do. And what we found was that P.L. Rust, which is a fairly new extension, actually creates processes directly when it's compiling the Rust function. So that was pretty cool. And once we were able to find that, we found, so basically we found that there was a little bit of validation.

There is a denialist that denies certain environment variables from being edited while Rust is compiling, while PL Rust, the extension is compiling your function. And we were able to find an environment variable that wasn't in that denialist that was able to be used to execute code. So it was pretty cool, especially seeing it work when we were – I was kind of skeptical that we were going to be able to at this point. And suddenly you see the command running. So it's pretty fun. Yeah, I suspect, I mean, that must – for both of you, there must be a gratifying kind of aha moment. Right. We even took it a little bit far. So we saw we were able to execute code on our own Postgres instance in a container.

And so we thought, well, let's see if this thing works on the cloud on AWS. We'll be right back. What happens when cybercrime becomes? comes as easy as shopping online. SpyCloud's Trevor Hillagos joined Dave Bittner on the CyberWire Daily to explain how a wave of cybercrime enablement services are lowering the barrier to entry and making sophisticated attacks available to anyone. I think it's a pretty good general term that describes kind of an umbrella of tools

and services that I would kind of tag as criminal or criminal adjacent. Instead of having, you know, sort of the smaller pool of high sophistication actors that are able to kind of carry out these really vast and costly cyber attacks, you know, we see that being given to much lower sophistication, lower tech folks that are, you know, a much lower barrier to entry to get into this field. The person that's buying access to this, they basically need a phone and a Bitcoin wallet. Make sure you hear this full conversation and learn how the underground economy is reshaping cyber risk. Visit explore.thecyberwire.com slash spy cloud. That's explore. Thecyberwire.com slash spy cloud. At TALIS, they know cybersecurity can be tough and you can't protect everything.

But with TALIS, you can secure what matters most. With TALIS's industry-leading platforms, you can protect critical applications, data, and identities, anywhere and at scale with the highest ROI. That's why the most trusted brands and largest banks, retailers, and healthcare companies in the world rely on TALIS to protect what matters most. Applications, data, and identity. That's TALIS. T-H-A-L-E-S.

Learn more at TALIS Group.com slash cyber. That's annoying. What? You're a muffler. You don't hear it? Oh, I don't even notice it. I usually drown it out with the radio.

How's this? Oh, yeah. Way better. Save on insurance by switching to Bell Air Direct and use the money to fix your car. Bel Air Direct. Insurance Simplified. Conditions apply. So we did want to check this out on AWS.

We were kind of wondering, we went and we read all of the different disclaimers that Amazon put out, trying to figure out if we were allowed to it all. And it was a bit of a gray area, but we decided to go for it anyways. And, of course, we did it on Thursday, like just before the weekend. kind of in the evening and ended up causing, causing some issues because we were unavailable after that. And AWS were trying to contact us and they're getting in touch with our bosses and they're trying to call us. They actually sent me a LinkedIn message. Like they were very adamant on finding out who exactly was running code on their RDS instances.

So I guess the good news is AWS detected. it. The bad news for you all is that they knew it was you, right? Well, it could be bad, but it's also pretty good because actually we got a nice collaboration out of it. So they were being very responsive. They were, they thought we were researchers since Vernon as a security company. And we do do security research on AWS, and we do protect our customers, AWS environments. So they know what we do, and they saw that the account was called something with the word research in it.

But still running code, it was actually a holiday or just before a holiday, and it was right before the weekend. And so they were a little bit unsure of whether it was a legitimate research or maybe someone compromising the environment. yeah that's interesting i mean everybody in security gets i think a little on edge when we come up on a long holiday weekend right history has taught us to be extra vigilant yes for sure so what did what was aWS's response here you you had this positive interaction with them what ultimately did they do to protect their managed databases so within a very short amount of time from us running code

they were able to block our access completely. They put the database in a stage, in a mode that we couldn't continue running code. They also reached out to us to make sure that we were actually researchers. So they were really good. And once we got in touch with them and contacted them, they helped us, because it's a third-party vulnerability, right? It's not really a vulnerability with AWS. it's more Postgresible in the reality.

They were also really helpful in contacting the Postgres team and making sure that things were fixed quickly and patching it on their servers, asking us to test it, and really just being really responsible about it and helping us to make sure that, you know, everybody's data stays safer, which is all of ours, all of our goals at the end of the day.

Right. And after we talked about this in Vegas, a few weeks ago, we also were able to actually meet the team that responded to this incident. So that was pretty cool too. Oh, that's great. I mean, you two did present at DefCon this year, so it sounds like it was really a positive experience all around.

Yeah, so we were able to present at B-Sides, Las Vegas, and at Def-Con, which was really nice. You know, that experience of speaking at Def-Con and, you know, getting on the big stage, It was really exciting for the both of us. We were a little nervous as first-time speakers, I think. Luckily, it was kind of the end of the day,

and it was a little more low-key, like not such a big talk, but I think it was really great and really exciting. And it was an interesting experience. I really look forward to being able to do it again. Well, congratulations to you both. I'm curious, you know, in terms of solutions here and recommendations for people who are using Postgres,

What sort of practical steps should they be taking, I guess, to lock down these extensions? Is that what we're talking about here? So first of all, I'd say, upgrade at least a minor versions of databases. I know it's a little bit difficult, but it's always a good idea. Use roles, so Postgres,

but also other databases have role-based access controls. Use those to limit who can create extensions, who can access which databases, which tables and everything. And apart from this, Postgres also has a configuration variable allowed extensions that specified which extensions you can install on the database. So if an extension doesn't exist there,

you won't be able to install it if you use that variable. So I would recommend using that variable and only using extensions that you know that you're using. Anything to add, Kobe? Yeah, I think there's also something to be said for the cloud providers side of things in this case. We're not just running code on any database, although this vulnerability works in most Postgres databases that have the two extensions installed. But when you're running code on a cloud provider's back end, right, there are various things that you might be able to do. You might be able to access credentials that shouldn't be accessed.

You might be able to have network access to different tenants. And I think it's really important. This isn't the first time that a vulnerability that allows executing code on database backends has come out. And especially when they can be run on cloud providers, we need to be able to have research, like community research on those backends to figure out if there are credentials that shouldn't be there, if there are network access that shouldn't be allowed,

if there are container escapes that we can implement there. So I think the cloud provider also has a really large amount of, so the cloud provider has a lot of its hack surface there. So, Tal, when it comes to specifically deal, with the cloud? Are there any specific messages you want our listeners to take away from this? All right. So in the cloud, managed databases are managed by the cloud provider, but the data is managed by the cloud customer. So there is a shared responsibility here. And sometimes that's confusing, both to the customer and maybe to the cloud provider. And so you need to be extra

careful and how you manage your data in the cloud. So while problems, issues like this one, a vulnerability in the database itself is something that the cloud provider should manage since the extension is something that the cloud provider provides and doesn't allow the customer to manage themselves, the customer should still be sure. to use the proper security controls,

not let just anyone access their database and not keep their databases private, use role-based access controls, like I said before. Just in general, store the right data and the right places, use maybe rules to mask some of that data and so on. Another thing that exists in the cloud is cloud credentials. So maybe you want your database to access other data stores that are stored in the cloud.

Maybe you want other services to be able to access the database. And those integrations should also be managed carefully because if you have cloud credentials inside of your database, suddenly a simple SQL injection can turn into a complete cloud compromise and lateral movement even between accounts. Well, Kobe, can we touch on the research itself and the lessons that you took away from actually going through this process?

Yeah, sure. So one of the biggest lessons, I think, we learned along the way is that setting your goals when you're researching is really important because otherwise things can get really hectic when you're researching. There are all kinds of different primitives that you can find and attack surfaces

that you can look at. And if you just set your goal, when Tau found the SQL Injection injection. At some point he decided, that's it, I'm going to find remote code execution on Postgres and specifically RDS or Aurora. And, you know, just that goal allows you to be able to kind of weed through the things that are less important and to really focus and have that goal in mind to be able to succeed in the ends. I think that's one of the biggest lessons we've learned. Of course, there are other things like environment variables that are

fun to use and things like that. But the main goal is set your goals before you start researching. Of course, things might change along the way, but having them there is a good idea, I think. Our thanks to Tal Pellig and Kobe Abrams from Veronis for joining us. The research is titled Rusty Pearl Remote Code Execution in Postgres, We'll have a link in the show notes. And that's Research Saturday, brought to you by N2K CyberWire. We'd love to know what you think of this podcast.

Your feedback ensures we deliver the insights that keep you a step ahead in the rapidly changing world of cybersecurity. If you like our show, please share a rating and review in your favorite podcast app. Please also fill out the survey in the show notes or send an email to Cyberwire at N2K.com. This episode was produced by Liz Stokes. We're mixed by Elliot Peltzman and Trey Hester. Our executive producer is Jennifer Ibin.

Peter Kilby is our publisher, and I'm Dave Bittner. Thanks for listening. We'll see you back here next time.