Python Tarfile Vulnerability – Doug McKee, Trellix

This is texturong TV. The great pleasure being joined by Doug McKee Doug is principal engineering director of vulnerability research with trellix. Welcome Doug.

Thanks for having me. It's pleasure to be here. It's great to have you we're gonna talk about some interesting stuff python of course always gets my attention.

But first, why don't you introduce yourself to us a little bit about you and also a little bit about traffic. Absolutely. So you've already got the name down.

So Doug McKee and I'm a principal engineer and the director of vulnerability research here at tralex might my team has basically two main responsibilities we do zero day research which is looking for never discovered before bugs in both software and hardware. And then we also do end-day research, which is mostly what we're talking about today minutes, which is vulnerabilities have been released in the past and how they're currently affecting the industry. And so we focus and those main two areas.

Perfect. I think we're going to talk about one that's been around for a little about a little while. So you a Python's always a great topic for me.

One of my favorite languages to develop in sort of the Swiss army knife. I think you know you Pearl used to be that way. I think pythons a little bit more.

Our current utility knife, but tell us a little bit about the research you did what you discovered. Yeah, absolutely. So it's kind of an interesting story the way it turns out.

I as I said, we do a lot of zero day research as well and one of my great researchers on my team Kazmir Schultz was working on a zero day project and he stumbled across a vulnerability and in the project he was working on and he brought it to me. He's like, hey, I found this new zero day. I was like fantastic.

That's what we do. Right but we have this very thorough vetting process when we find something, you know, make sure that it is new how it affects the product and things like that. And so we started going through that validation and came back a little bit later and said actually this is extremely old it's not new at all.

And so that was really interesting for us to see a vulnerability like this in such a you know, a big space where we thought that you know, this particular product wouldn't have a vulnerability like this. So we started investing like how did he get here? Why is he here?

Why are we discovering these things and I've got an OS and which stands for open source intelligence expert on my team Charles McFarland. I kind of tossed it over his way. And said, hey, could you just kind of pull this thread a little bit like what?

What do you what do you see if you start researching this? And we were kind of astonished at the results that we found which is that this cve which is a tar it's in a tar file module of python and it allows for a path traversal attack. It's been around since 2007.

So it's about 15 years old. So it's again this is not new. We're not cleaning.

We found something new and we started looking at how prevalent is it in the open source Community because that's what we have access to right like we can't start looking closer community and we found that you know, as you said pythons one of your favorite languages with Swiss army knife out there. Well guess what the industry finds that things the same way and we found hundreds of thousands of projects online on GitHub that are using the talk file module, but even more disturbing about 60% of those are vulnerable to this vulnerability. And so this was something that we thought that wow, this is that big of an imprint then we should probably kind of publicize this information and do our part in the industry to try to help secure this type of a supply chain vulnerability so oftentimes and there was this existing in the cve was already existing or did you have to file and create a it was been around to just never been identified and filed before that's a great question.

So cve numbers are generated the year in which they're filed. So this has a 2007 identifier. So we are not responsible trellis did not file for the CBE if we would have it to have a 122 identifier great and just to confirm for folks.

We're talking about cve 2007 4559. So if you don't work it up follow along so, you know, there's lots of reasons why a vulnerability might not get fixed. Sometimes it's fixed in the software but people and update it right sometimes it's there and you know, it's just not been exploited in a way that it's been a big enough problem that people go about fixing it, even though we might think it is or it's you know, the way you use the software install the software.

It's very difficult to exploit if you got to that place of being able to Traverse the Traver The directory the file path and get to something and you know grab the goods if you will, but it's you know, it's really difficult to do because of other factors of how requirements configured do any of those apply here or is this just been sitting here kind of nascent, you know, somebody filed it and you know on a Friday night after a a good healthy amount of lager lager and everybody kind of forgot about it Saturday morning. But those are a lot of good points and I think there's probably a lot of factors here among those that apply to this situation. I'll start with addressing, you know, is it super difficult to exploit and that's why we haven't paid attention to it.

You know, if you take a look at the research that we've done we've actually shown it's extremely simple to exploit and to leverage this vulnerability and that's and that's why we're actually talking about and trying to bring awareness to it is because the Simplicity of exploding now, I will make sure that I'm explicitly clear that it's different how you would exploit this vulnerability in every single project or application like it's not a one-size at all. So there are some cases that maybe it is more difficult or not accessible but there's definitely many applications whereas extremely easy to exploit and you can see some of those we've created demo videos the demonstrate that on our website. I believe that's why hasn't been addressed nobody if they do exploit it if it is exploited.

Is it a is it a Provisions escalation? Is it execute code? What can be done once somebody exploits it that that's a great question.

So we actually put this in what we call the arbitrary right class of vulnerabilities. It allows an attacker to write anywhere on the file system as a result of this so that can lead to code execution. Right?

It doesn't have to it really depends on the rest of the environment and the rest of the precautions in place. But we do see that this type of arbitrary right to the file system can very often lead to code execution and therefore complete system compromise. But again, I'll preface that by saying it's different for every single instance of this vulnerability and it would be prudent for vendors and for the open source Community to see what applies to them right?

I don't want to overhype something. Great now is there cash for this or it hasn't been? So, you know, this is released 15 years ago the python Community took about seven years to start discussing it on on their forms and they're like a lot of times in open source communities.

There's not always a consensus on the right way to do something if it's a problem how it should be fixed. Right? So the they actually started working on what they called the safe tar module which would allowed developers option to not have this vulnerability in their code.

And that that poll request was submitted to the python project many years ago, but it never got integrated into the main code base and there's a lot of discussion around like is this a desired feature that should be left for certain Corner cases that may be needed to be used by developers or is this actually a problem and you know, that's that's everyone's got their own opinion on that. And I also think that it changes over time, right the present time do to the way python has become so Popular and the way that it's integrated as part of the main supply chain to a lot of Frameworks and applications. It's a much bigger deal today than it would have been 15 years ago.

Right. We're also seems to be a little bit of inconsistency in the python Community about how they handle these type of issues. So something you might be familiar with is a ZIP file, for example, and of course python handles zip files.

Well, it's interesting is if you look at the zip file module, well, they actually handle this issue securely that they don't have this problem. But in the tar file, there's arguments that that's argument that they maybe should leave it as a feature type thing. So there is no official patch from python the safe time module thread was sort of abandoned if you will they did put a warning on their website and their documentation stating that this is a security issue if not handle properly.

So they basically have transferred the risk to developers and that's that's kind of how the community has handled the issue. Yeah, I guess a measure all the Deets of it but it sounds like you can't gearing consensus about how to fix it. And sometimes fixing it has consequences to other things, right?

It might absolutely how formats or code you've already got or you gotta go back and change a bunch of other things. I don't know and I think the other thing to mention here is that if it was fixed today in the python code, you know, it doesn't necessarily mean it would get propagated to all the applications that are vulnerable right like we have that problem from a patching perspective no matter what form of patching we're using so it doesn't instantly fix the problem. No, not at all.

I mean it may never be fixed in some a lot of code that lives out there right we can talk about Windows or whatever if we want to be. Well not just Windows all systems have that issue? You know, that's you're forced up great.

So so let's talk about what's next. What do you what do you do with this if you kind of okay, we put it out there. We're trying to build awareness be good corporate citizens and and Report responsibly, you know with is all Good vulnerability research should do what's left to do.

Just if you've done as much as you can you got to move on or you got more that's gonna happen. We're definitely gonna keep pushing on issues like this and keep investigating similar issues as well on my team and that's part of our Charters to like move the needle forward and security right? We're always once it better the industry as a whole.

So when we saw this problem, I personally hate like raising the flag on an issue and not providing a solution. I don't feel like that always helps. Right and our goal here is to always try to make everything stronger.

And so what we've done is we've released a script on our public GitHub which will identify if your social code base is vulnerable to this vulnerability and what we believe is the probability of successful exploitation of the vulnerability now that doesn't fix the problem but it does provide you a very easy method to quickly discern. How are you affected because like we see with a lot of supply chain vulnerabilities, sometimes that's the hardest question to answer are you affected how are you? Fact it should I care and that's going to be different in every single situation.

So we've provided that to the community. We've actually already seen a great number of people downloading and utilizing that script in the last couple days. So that's really encouraging to us.

But then we we don't like to stop there. We want to take things one step further and of course we can't do much for closed Source Community, but in the open source Community we can help by submitting pool requests to as many of the repositories that we found our vulnerable as possible. So over here in the next couple days and weeks to come Charlie will be submitting pool requests to those projects with a suggested patch to as many as we can to hopefully get integrated and help reduce the attack service for this vulnerability.

Very good. Does this fit into sort of a broader strategy for you for your products and things in terms of vulnerability scanning their capabilities that you offer to customers for, you know for the Forefront profit part of your business. All of our research always has a place and the larger organization, you know and the concept of xdr, right?

We're trying to make sure that our customers are fed with the most up-to-date vulnerability intelligence and making sure they understand what the threats are and what they need to do. So we will definitely we are definitely putting this Research into our products as well to ensure that there's a product that protection in place that our customers will be able to be alerted at this type of issue is exploited in the future. You know, one of the points you brought up earlier in the conversation is sometimes we don't consider things important based on if it's being exploited in the wild, right and so I often get asked and I'll just kind of trump the question by giving you the answer, you know, is this being exploited in the world currently and to the best of our knowledge we don't have any information stating that is being exploited today.

Well, I would like to bring up the point that you can only find what you're looking for. And if this has been in the supply chain for 15 years and security Vendors haven't necessarily been aware of it. Haven't been able to write the correct detections or we aren't looking at that type of intelligence.

Then we really don't have a great pulse on whether it's been exploited and hopefully by bringing awareness to this trellis and other security vendors can help ensure that we are aware if it is an issue and how big of an issue that is. Well, you're the researcher I'm not but you know some of these issues vulnerabilities when you can the vulnerability itself, let you cover your own tracks that can also make it extremely difficult to I absolutely right assistant. Yeah.

Yeah now we can make it. Look. Oh nice and clean and properly may not be So well, thanks so much Doug appreciate you come on, and you know, if anything new pops of help us with some awareness.

There's a lot of Open Source not to anything. You don't know a lot of Open Source projects more every day. And you know, no one right and wants to write unsecure code.

There's no developers who wake up and say I'm just feeling kind of a key today. I'm going to write some bad code. Oh, we don't do that.

So, you know, this is a good part of our ecosystem to help each other and appreciate your working and research on this. Absolutely working folks find out more about trelix and some things that you offer. Of course, like everybody else.

We've got our website and on our website. We've actually published several blogs about this specific topic. If you're interested in the nitty-gritty technical details, my lead researcher Chas has a technical blog that kind of breaks down so you can have a great understanding of how this phone really works and what you need to do to protect yourself as a Charles.

My osint expert also has broken down how we've gathered our data in case you're curious and want to really dive into the numbers suggest you review that as well. And of course as we've mentioned on our publicly facing GitHub page, we have that script that you can download to help ensure that your code base and organization is as protected as possible. Fantastic.

Thanks. Again, Doug, Doug McKee who's with trellix and think your research team as well? Thank you so much for having me on you bet.