Episode 784 transcript

FLOSS-784

Jonathan: This is Floss Weekly, episode 784, recorded Wednesday, May 22nd. I'll buy you a poutine. Hey, this week Dan Lynch joins me and we talk with Francois Proulx about Poutine. That's an open source project from Boost Security. It is a code analysis tool looking for security problems in your GitHub and GitLab CI actions.

Things like leaking secrets or cash poisoning, or maybe even something worse than that, you don't want to miss it. So stay tuned.

Hey everybody. Welcome. It is time for floss weekly. That's a show about free Libre and open source software. I'm your host, Jonathan Bennett, and we've got, we've got Dan, the man, method, Dan, the, the one and the only with us today the original Linux outlaw, is that, is that right? Dan, I call you that sometimes that's accurate, isn't it?

Dan: I like to think so. I'm not entirely sure, to be honest. I'm sure there's a lot of other much older Linux outlaws than me who would, who would claim, would claim that. But yeah, I'm going to claim it. Why not? Nobody else did.

Now the real question, I suppose,

Jonathan: is have you ever actually been an outlaw?

Dan: Have I ever been an outlaw?

Only speeding offenses really in the car. I've, I've been, I've been on a few speed awareness courses for the for the local police, but only a couple. In 20 years. That's not bad. That's not bad. That's not too bad.

Jonathan: Well, we've got a we've got a fun show today. We're going to talk with Francis Pruhl about, about a project called Poutine, which, that is a, that is a Canadian it's kind of a Canadian junk food.

Is it a junk food? Maybe it's not a junk food. But it's, it's a particular type of food that is, apparently very messy to eat. And so that's sort of the play on words. Poutine is about figuring out a particularly messy security problem. And this is a project done by Boost Security, and they just recently announced it and made it open source.

And I thought it was neat. So I was, I was excited to be able to talk to him about this. Is, is this something you've gotten a chance to look into yet, Dan?

Dan: Only today. I've been doing my research today after you helpfully sent me some pointers. I've been on reading some reading some stuff about this.

I suppose the real question is, have you ever had poutine itself? Cause I have the the food. I mean, it's really good. It's very interesting. The unfortunate thing

Jonathan: is that it is now on my I cannot eat that list. I recently got diagnosed with Hashimoto's, which is a thyroid problem. And one of the most common solutions is going gluten free.

So I am going down that road to see if that's going to help. And yeah, so there's a lot of, there's a lot of junk food that I used to enjoy. That's like, I can't have that anymore because it's trying to kill me.

Dan: You need to find new ones. I'm sure you'll find new ones.

Jonathan: Oh, I'm sure I'm sure all right.

Well, let's let's not dally any longer We have the man himself rather than continuing to take guesses at what the project is about let's bring Francois on and welcome to the show, sir Thank you. Thanks for having me. Yeah, it's great to have you here. So, tell, first off, did I pronounce it right? Is it, is it poutine?

I am, I'm very ignorant when it comes to that particular bit of Canadian culture. Yeah,

Francois: that, that's how most, like, English speaking people pronounce it, poutine, but in French it's So a little softer on the

Jonathan: ending. Okay. And then give us kind of the overview of the, as we like to call it, the 30, 000 foot view, what, what is this, what, what's the problem that we're trying to solve with Putin?

Francois: Yes. So really it's in the category of security vulnerability scanner. So it's what some may call like a static code analysis scanner that is going to look typically at source code, but more specifically manifest, like typically they would be written in YAML. And it would be stored on GitHub or other get repos, not just get, but and.

Those yaml manifest would define build pipelines. The ones we currently support, it's GitHub actions. If you're familiar with that, or also on GitLab the GitLab pipelines. So they would define the the way to build a certain software and eventually package and publish to some kind of registry and we're, with poutine, we're looking at security vulnerabilities in those So we can get into the details of that.

Jonathan: Yeah. What is what, what does one of those security problems look like? Like what's, what's sort of the the category of issue that people run into with their GitHub and GitLab pipelines? So

Francois: first, like, let's kind of set the stage a little bit. So there are kind of two broad kind of types of issues.

If we look at open source projects where everything is visible, like including the build pipeline. So typically on GitHub, you know, you can discover not just the code, but the way it's built. That is definitely an area where the attacker can as, as is the case for the actual source code, find vulnerabilities, but potentially like unknown vulnerabilities, zero days.

Right. When it's like an enterprise setting, like a internal source code where. And an external attacker would not see the build pipeline or the code would be more like, you know, insider threat scenarios. But in the case of open source projects, you can see even the dependencies that this project is pulling in, how it's built, and really the scenario that the classic scenario is, if you're familiar with GitHub, like, you know, pull requests the, the, the term that we use typically to address like Most common type of problem.

It's called Pwn request. Like that, that is effectively a pull request from a fork that is specifically targeting a vulnerable workflow. And the way to do that would be either through the actual files that are modified in the pull request. So let's say the contributor, a malicious contributor is sending a patch.

Let's say, and that is a real example, let's just updating the readme. All right, readme. md, it's a markdown file, apparently just a text file. But if it so happens that the build pipeline is gonna do like a linting, you know, formatting, just to make sure everything is, is is, is by the book. That is running code, like you know, linter or whatever.

on untrusted data. In that case, just a markdown file. Most cases, it's pretty safe, but some tools have little known kind of dangerous features that can be exploited by the attacker to run some remote code execution. That is one example. The other way is also through all other kind of inputs that the attacker has control.

Let's say the title of the pull request. Or the body of the description of the pull request or the comments that common comments, threads you see or the basically there are a number of things that if you're an User on github you can influence and the build pipeline will consume it Also, even the git branch name the git branch name.

You'd be surprised That it can contain like arbitrary bash commands or JavaScript commands. It's long enough and it accepts enough characters. There are some restrictions, but it's more than enough. And we've seen in the wild just malicious git branch names.

Jonathan: Okay, let me, let me give you a softball question.

I, I sort of know the answer to this, but here, here's a, here's a softball for you to get further into this. I thought Git runs all of your workflow stuff in their hosted virtual machines. Doesn't that completely solve all of these security problems?

Francois: So, I think you're referring to GitHub actions. So GitHub actions.

Yes, they are indeed. By default, the GitHub actions run in ephemeral throwaway virtual machines that are created on demand right at the, the, when, when a workflow is being triggered, they actually, even in the workflow, you have what they call jobs and each job is going to be a completely Independent ephemeral virtual machine but then inside of that, typically you would be referring to secrets.

For instance, to push to NPM, PyPy, Docker Hub, or whatever. So as part of the, the, the execution in the end, you're injected. It gets injected some secrets that could allow an attacker to pivot to something. Like let's say secrets to connect to AWS, to, to run some testing. If you're developing some kind of tool that would run in a cloud.

In the runtime, in the memory of the runner, even if it's ephemeral, it would get high powered in some cases, like sensitive credentials.

Jonathan: So that's, that's really the kind of the problem space that Poutine is aimed at. Someone can get arbitrary code execution in some, in some projects, I will add in some projects, the way the build system is set up, you sort of have arbitrary build or arbitrary code execution by default, because you know, there may be a build script.

That just runs bash code and you can send in a pull request that changes the build scripts. I mean, in some cases that's trivial. It's what I assume what poutine does is it looks for these problems and tries to what give you a warning that says, Hey, the way this is set up, it's trivial for someone to steal your secrets.

Exactly.

Francois: So typically the, the way get, get, get an action, namely was designed, it was designed. With that scenario in mind first hand because GitHub from the beginning always had pull requests with accepting requests from forks Right, so that's just by by its definition accepting untrusted code from someone someone So they designed by default that this would run in a sandbox where no secrets are accessible But, in some cases, you need secrets.

For instance, imagine you're processing the incoming data, and as a maintainer, you, you want to, to lower your toil of just, like, accepting, like, the contributions maybe come at a specific format, and that they, they meet just the guideline of the project. And in that case, then you might want to reply automatically with a comment saying, Sorry, we are not accepting your contribution until you Address XYZ.

But for that, the, the script will need some credentials to push the comment back in the flow, and in some cases, even update, you know files or push artifacts. So it really comes down to limiting the amount of secrets visible to kind of risky workflows. Those that, that you need access to some secrets.

But if you really need that, then yeah, you need to not process arbitrary code effectively.

Jonathan: There's a, there's another kind of class of potential problem. And I'm, I'm real curious cause I've, I've been working on this in a project that I'm involved in. We wanted to be able to do arm and arm 64 builds.

Well, as you probably know, that means self hosted runners on raspberry pies or something similar. And. I have been working over the past couple of weeks on trying to figure out a way to actually do that safely. And the, the solution that I've come up with so far is with the self hosted runners, you can do a, you can set it up with an ephemeral tag.

And then what I'm doing is I'm running those inside of Docker images. But I know that like Docker images are not the same level of of safety as something like a virtual machine is. I'm, I'm curious, does, is Putin aware of like this side of the problem, doing self hosted runners?

Francois: Absolutely. So we have a, we have a rule that will flag the usage of.

Self hosted runners, which trigger which accept on pull requests. And what's interesting there is that because unlike the, the, the sort of hosted runners, which are designed to be fully ephemeral, like fully like cleaned up and there's no sharing and fully isolated between each run. In that case, you're responsible for making sure everything is fully isolated and there is no leakage between each job.

Because if you have two like jobs that run in parallel concurrently on something you host, there could be cross cross job kind of pollution or sort of exfiltration leakage of data. So and yeah, we do flag scenarios where you're combining accepting pull requests. With that and that adds even more like more risk because you're you're on your own.

Jonathan: Yeah No, it's it's a it's kind of a scary thing to set up and I've I've been I've been kind of slowly working my way Through trying to think through this Now I'm curious does poutine Does it actually send in pull requests to try to test some of this stuff or is it just looking at configurations?

Francois: No, at the moment it's fully static.

It's a static code analysis tool that works. It can work fully offline. In fact, like it doesn't emit any network request except for interacting with Git, so you could get clone everything. In a directory and disconnect from the internet and run poutine. So like at the moment, we're not pulling any vulnerability database or whatever.

It is in the road map to add that as a kind of opt in feature where you would be like, you know, dash dash. Allow synchronizing kind of vulnerability database at the moment. We have that kind of baked in offline. Many of the rules are purely static code analysis like to detect those problems. So they don't even need a vulnerability database.

But yeah, so to answer your question, no, we are not. Doing any kind of active exploitation validation purely based on inspecting the code, finding the code patterns that are risky.

Jonathan: It seems like there could be it's just, just looking at the problem from the outside and what little I know about poutine there, there could be some possibilities there where you might want it to be able to generate a I guess that's tricky.

If you want it to generate an active payload, then you kind of move into this area where Putin becomes a red hat tool. Or excuse me yeah, a red team. Wow, I just, I mixed my metaphors. Black hat, red team. But it becomes a red team tool. Maybe that's not what you as a security company want.

Francois: No, exactly.

We, we're really, we've really designed it in a way that is gonna help it. People who typically are responsible for writing those workflows to, to detect problems quickly, efficiently, and, and, and learn from the, like, we've also provide some kind of training, like guidance and like like best practice kind of bad, bad examples, good examples to, for, for people to, to improve and in that regard, yeah, it is not designed as a red team to To showcase that.

That being said, we have a different project that we call Messi Poutine, if you want to get into that, which is all about Allowing as kind of a sandbox for capture the flag where people can have fun exploiting things that we've designed to be Vulnerable and we, we built that really as a way to test poutine.

So we point put into that GitHub, literally a GitHub organization called messy poutine, and it's all about finding as many flags, vulnerable things in there. There are some that. At the moment, Putin is unable to find, I know them like, and you can play the game kind of to find those. And we want to improve the tool to detect as many as possible going forward.

Dan: So Francois, I am curious about why you decided to release this as open source. What's the advantage of that for you guys?

Francois: Yeah. So we're, we're, you know, a commercial or a vendor. We, we, we build a security product. For commercial product as part of that, we. Automate provisioning a number of open source tools already to name one, like Sam grep, for instance, or trivy or gripe, things like that or Chekhov.

So there was a number of open source tools that we help to orchestrate and aggregate the results, and then we add our, all of our kind of secret sauce on top of that, and that was on the one hand, kind of interesting. Give back to the community because we've been benefiting from a lot of open source tools ourselves.

And we wanted to bring something where we saw there was a gap, right? There was something that was not yet in the open source and even in commercial, there was like, there's kind of a gap in that area at the moment. And we thought that the, the, this type of problem, when we started to look at it at scale, because that's how it really started, it started more like as a hackathon project.

We, we knew this type of problem existed. We were finding it kind of purely manually, just by pure chance, like happening to see something like, Oh, that's exploitable. So we wanted to kind of automate that seeing just how big the problem is at scale. And we started this project that we call package supply, which is indexing millions of open source projects.

And finding this type of problem at scale. So also finding transitive kind of attack path that is not directly targeting one project, but like vulnerable workflows that are downstream of, of you know, say sensitive project. And at some point when we had that started to do a lot of responsible disclosures to many projects we wanted.

To bring that to the masses, like to help people fix their workflows and find those things easily. So that's, that's how we, we came up with, with, with poutine as a sort of a sister project, this bigger kind of package supply, which I spoke at the open source security foundations conference last month about that project.

And that was our way to give back to the community.

Dan: That's excellent. I was curious about how many people are interacting with it. Community wise, what's the response been like? Have you had a lot of bug reports or interaction?

Francois: Yeah. So it's been just about a month that it's open source now. And I think we're quite pleased, but with the, the, the number of interactions, like stars and like people like chatting about it, like, and you kind of getting interested in it.

So it's, yeah, I think we're getting. Very good interest by people that I think should, should know it exists. But we want to spread the word even more. And thanks to, to you, like hopefully we'll, we'll get up to more people that can benefit from learning, even learning. Like it's, I think it's first and foremost about awareness.

Like many people I talk to that have been doing a pen testing, like red team exercise for years. They're completely unaware of this class of vulnerability. Many people, you know, talk about top 10 and like very classic type of SQL injection, cross site scripting, et cetera, et cetera, that that's a very, very mature type of, you know, area.

Like there's tons of tools. The know how is, is, is very well, well advanced by now, but when it comes to vulnerabilities and build pipelines, that is still an area that is a bit Up for grabs.

Jonathan: And you got to think if, if red team professionals don't even know about it, then your run of the mill open source project on GitHub has no clue about it.

Francois: Yeah. I mean, and that, that goes back to this what we call package supply that was about in like doing, evaluating the sheer scale of that problem at scale, like millions of projects. And as I said, I've, we've reported a number of, of problems to open source projects in some cases. Some projects that were downloaded millions of times a day, not to name them in very critical infrastructure kind of pieces.

Like so it is a real problem.

Dan: Yeah. You mentioned in your I read your blog when you announcing the release of, of poutine and, you mentioned in there that it seems like maybe the things that you found so far feel a bit like they might be the tip of the iceberg. Do you think the industry has been kind of sleeping a bit on this as a potential problem or, or do you think it's just not been in people's minds or, or so?

Francois: Yeah, I, I think, I think most people have been focusing a lot on making sure. The code that they're producing, what, what they're delivering as an artifact, be it an open source or commercial is secure so they can, you know, they do their best, but like the build pipeline has always been seen more like as a, a means to an end, right?

Like you need to do it to automate certain things, to compile, to run tests, linting, and all that. But ultimately a lot of times, like even the, the build time components, like they, they're not seen in in the final artifact. So. Many people never thought this was much of a problem, but when you start to add you know, you've all seen this kind of the, the, the sheer complexity in terms of dependencies, you know, transitive dependencies of most current, like in a software nowadays, and you apply that to the build, the pipeline is the same thing.

So the, the complexity and the problems we're trying to tackle. When it comes to the code itself they apply equally to the build pipeline.

Dan: It's interesting because people really don't, as you said, there are people don't think about the pipeline. The only thing about the end product and the code that's going to come out of it, or the source code that people are looking at, we don't necessarily think so much about how that gets transformed through these pipelines and can end up in, you know, any kind of state, I suppose.

I was reading. Earlier about the chain guard vulnerability that you guys discovered. I read that little blog post about fascinating story. Can you tell us a little bit more about that? About the story? Yes.

Francois: Yes. Yes. So we discovered that like, as we were developing this, this tool We were pointing it at the stuff that we're using.

So it's, it's a lot about developing a level of, of of of assurance that the things that we're consuming to build our product we're picking the right, like, you know trustworthy components and chain guard is doing an amazing job, like great containers, like secure by design and all that.

Like with very low number of CVEs. But we're looking at their build pipelines and we found one such example that was exploitable to the type of problem that I described earlier. But in that case, what was a bit more interesting is that we stopped short of the kind of end goal, like the article I think you're referring to was,

A near miss incident.

In the sense that we got very close to the ultimate goal, which was to showcase to, to demonstrate that we could exploit and backdoor and like compromise and a component that itself themselves were using in the build pipeline of something that is like their mission critical, like, you know, Docker container machinery and we stopped short of just like the, the One thing where, in fact, it was almost like it was a feature, not a security feature of GitHub action that prevented us from, you know, closing the gap and that feature was made like by GitHub action to prevent recursive kind of infinite loop.

So it was not meant as a security. Like mitigation. But because like effectively a workflow using the default credentials cannot kind of trigger another workflow. Like that prevented us from kind of closing the gap with the way the attack was set up But it doesn't mean there are other scenarios where the credentials have the right permissions and you could have done that So that's like a more advanced use case, but in in fact like just A month ago a fellow competing research team, like like it's his name is Adnan.

And he basically, he, he, he managed to find an alternative way to, to achieve the same goal. So it was very creative in that case, he found that the caching mechanism and get of action. Could be could lead to some kind of cash poisoning where like you could basically add some vulnerable version of, in that case, the go tool chain.

That would be used in another workflow and like effectively the, you would have a, you'd be using a poisoned cached tool chain.

Dan: Wow. I was yeah, I was curious about whether, when we talked about the fact that it's open source and the benefits of that, and you're on GitHub yourself. So. Putin is on, he's on GitHub.

I was curious. I have a bit of mischievous question. Do you accept pull requests or have you had pull requests? Is that a danger? Because Putin itself, it seems to me would be a desirable, a desirable target for people possibly.

Francois: Yeah, I think it really comes down and I think that that is why we build this messy poutine project is to really educate people that there is a, there is a way to accept contributions from pull requests in a perfectly safe way.

It's just that when you start to kind of go beyond the default scenario that is supported by default, you want to do some things that are a little bit like more like and more interactive. That's when you start to pull some credentials and and then the whole like least privileged kind of principle applies where you don't want to put all your eggs in the same basket in that workflow that you know is a risky workflow that is.

You know, touching credentials, that one, you may want to separate it completely from the, the compile, enter, and like eventually release flow.

Jonathan: So you, you, you run poutine against the poutine repo from time to time?

Francois: Yeah, we've got like poutine on poutine pop,

Jonathan: yeah. So in thinking through this it seems like kind of the, the worst case scenario that a security problem on one of these one of these sort of builds throughout the pipeline, the worst case scenario would be something like the XZ backdoor, where someone could sneak something like that in using pull request.

And I'm just curious, what's the, like, what's the worst thing that we've seen that's happened with kind of this style of vulnerability? Has there been, you know, the, the, the XZ level of problem?

Francois: I mean, I would be, I would be shocked that it's not been already the case and no one knows about it because every since, since I've been focusing our research on that area every single day, I I'm, I'm shocked to see how easy, like how, how many low hanging fruits are still out there, even on.

Very reputable mission critical piece of open source software that are maintained by not to name them name, pick, pick a name of a big open source contributor and I have concrete examples of. Vulnerable workflows that either I've reported they've been fixed or that I'm in the middle of having, you know, having them fix.

So it's, it's, we, we would be fools to think that attackers are not leveraging that already. And to that point, I've built some proof of concepts like to demonstrate that to some of those in the case of responsible disclosure. Sure. Kind of a nightmare scenario example that was inspired by some of those things we've seen in real world.

And I showcase that like in the last conference talks, like I have kind of a video explaining all that and you can really see that it can be made. Extremely like fully scripted that the whole attack runs within just a few seconds and the attacker can clean up their tracks like the cover as many traces as possible so that what is left in the pull request appears completely.

Like innocuous but in the end, the attack has fully succeeded and it can be made in a very sneaky way. So just as much as, you know, XZ was more of a social engineering game. This could easily be combined with something fully scripted, automated, that would. be part of the whole operation.

Jonathan: To, to kind of drill down into that a little bit more one of the, one of the sneakiest things about XZ was that it wasn't an outside contributor.

Well, he started as an outside contributor, but then he kind of worked his way into the core team. And so this is, this is what we would call an insider threat. And I'm curious, what, what can we do? And is there anything that Putin can help with? To sort of protect from that insider threat.

Francois: Yeah, that's a much bigger problem.

And I, and I think Putin is the only way that I see that Putin could help in the scenario of like an insider threat would be. Imagine a scenario where the insider malicious co contributor is purposely making the workflow vulnerable in a subtle way, right? Like, like just like, Oh, look, I'm improving the GitHub action workflow.

Let me do this. Like it's going to be useful. And they know, knowingly add the vulnerability, which. Could potentially be detected by puts in, but puts in, you know, it's not perfect. And there are ways to write the vulnerability in a way that would not be detected. So in theory, someone using it to discover those kind of like vulnerable workflows that were added as a backdoor like just waiting to be used.

That could be useful. Because again, there's tons of low hanging fruits out there. So were they, were they maliciously added? Most likely not, but they're present and they could be leveraged by someone with malicious intent. For insider threats, I have another article for those who are interested that is all about addressing insider threats in open source projects.

And that is a much more. Complicated topic and then it, it comes down to, you know, some code review, like having like not just ideally, like not just one main maintainer and like having multiple, like more than one person approving code changes. But as we've seen in XZ, it can be done in such a sneaky way that it, it passes, you know, community scrutiny.

Jonathan: One of the, and this is sort of a tangent, but one of the things that really, really interested me about the XZ story is part of the problem was hand built tarballs. And so if that project had instead used GitHub built tarballs, The whole attack would not, it could have been pulled off, but not in the same way that it was pulled off.

And so it really fascinated me. You know, we talk about reproducible builds, but reproducible tarball builds is sort of important too. And that seems like that is at least a parallel thought to what Poutine is working on.

Francois: Yes. And, and to that note I called out one, something very similar to that, like literally two weeks before the whole XZ thing, I wrote this article about insider threats, an open source project.

And at the end, if you go to that article at the end, I specifically call out what I wouldn't say it's a vulnerability, but it's a weakness or like a poor choice of the, and designed by GitHub on GitHub's part when it comes to the release. Kind of and the GitHub, like the release part, which where, where Exe kind of put this tarball, right?

Anyone that has write access to repo, like you just have a contributor that has normal write access. You may use branch protection to prevent them from merging code in the main branch. Right.

Speaker 4: Right.

Francois: But simply having write access allows you to modify release artifacts. So, so there is no specific role called release.

Admin or release editor. Anyone with right access can literally, I like, just, just try it at home. Let's create, create a repo, create a release, create another user that you invite just as a right access person. Even if you kind of make it, it's not an admin and all that they will be able to go and edit.

And upload another artifact. In that case, the xxi, the Tarbell like literally can override and it leaves no trace. There is nothing in the audit log of GitHub to, to, to see, to see that it was tempered with.

Jonathan: Have, have you been able to get a hold of any of the security engineers at GitHub to talk through some of the various things?

Yeah.

Francois: Ma, ma, many, yes. Many times. Including, like two days ago, I, I met with someone in person at the conference last month, so. Yes, I've been in talk with several people at GitHub, you know, talking about a number of ideas that I have to improve at many, many, many levels. And they, they, they tell me that they're working on a number of initiatives, but yeah, there's, there's a lot of work to fix that.

Jonathan: Yeah, I do have a question from the chat room. I want to I want to get to because I think it's fascinating. It's from Ken McDonald. He says, I see your documentation represents references and open source vulnerability database that's hosted at osv. dev. Is that database maintained by GitHub or boost or you guys?

What's what's the what's the OSV?

Francois: Oh, OSV is the open source vulnerability database maintained by Google. So it's a osv. dev project. Like you can find it. I think it's kind of a sister project to the deps. dev. If you're familiar with that other Google project that is kind of tracking the dependencies, the dependency graph of open source projects.

So OSV is really attracting CVEs and there's a subset of it that is looking at GitHub actions. Namely and we effectively, because at the moment, the number of CVEs for GitHub actions is so small, literally less than 20. We just, we just pulled it offline. It's part of the Poutine binary itself. You can find it, let's just a JSON like file.

Cause it's so small at the moment. So we don't even need to kind of go fetch some kind of vulnerability database updated every day because there's so few. But we know for a fact that there's plenty more to find. We, we find, we find new ones maybe not every day, but like, especially GitHub actions that workflows depend on that are vulnerable.

I have many yet to be reported yet to be

Jonathan: fixed. One of the other things that interested me is you guys are not with With Poutine, it's not limited to GitHub. There's also GitLab support and is, is there Azure support as well? Or is that coming?

Francois: Yeah, at the moment we support GitLab pipelines and we do have plans to support CircleCI, Azure Pipelines and Jenkins and all that, maybe in different way, but at least like Azure Pipeline is a low hanging fruit because it's really the predecessor.

It's kind of the parent. Of GitHub action, like, you know, when Microsoft acquired GitHub, they, they brought this and that is kind of the underpinning of GitHub action GitLab pipeline. It's interesting because, you know, when we went and wanted to support it in poutine, we wanted to find the equivalent vulnerability class.

As the rules we were already supporting for GitHub, and there's a fundamental difference in the way GitLab pipeline are processed when accepting Pull requests, or in that case, they call it merge requests in GitLab, right? Accepting merge requests from forks by default, they always run in a different context, which does not have access to secrets.

So very similar to GitHub Action, what they call like pull requests in GitHub Action versus pull requests target. So it's as if GitLab by default does not have any way to expose the secrets when accepting contribution from a fork. But you're just one click away from saying, run it in the sensitive context.

So in that case, it's a bit more like a social engineering. Like you may want to hide it in a big talk. PR with like hundreds of files and just one small line, like the exit did, you know, this kind of space this extra white space at the beginning that changed the whole behavior of the, the bash script.

So it could be very sneaky and someone say, yeah, it looks fine. Let's run it in the guild pipeline with the sensitive context. So,

Jonathan: yeah. One of the, one of the other differences that comes to mind is with GitLab, particularly if you're hosting GitLab yourself. You're not running all of that inside virtual machines.

That's going to be pro I would assume what in a Docker image or something similar. And so there's, there's, you know, kind of another, um, another potential problem where you can, you can escape the, whatever jail it is, you know, it's, it's going to be something like a CH root jail or a Docker image using namespaces and depending upon how that's set up, those are, those are escapable,

Francois: absolutely, absolutely.

So, yeah. You mentioned earlier, like self hosted runners that brings that, that, that puts a lot of responsibility on whomever is maintaining those runners to make sure they're fully airtight and nothing is being leaked between each run, because if one run is poisoned and then you kind of sudo and backdoor the kind of environment around, then whatever follows.

Is not to be trusted so and that in that space, in fact, like we've seen, we've seen like big projects, namely those who kind of need the self hosted runners because like Gen AI, like LLM, like projects, open source projects, they need like big machines with GPUs. And to save costs, like they kind of manage their cluster of GPUs on say AWS.

So there, there's been a number of disclosures, not by my team, but by other teams doing the research where there were hosts. Self hosted runners on those open big LLM projects where you could basically poison the runner,

Jonathan: you know There's a I mentioned earlier, but there's a there's a scenario that's way simpler than that You know way way less budget involved and that is if you need arm or arm 64 builds You do not get arm runners on GitHub, at least not for free.

So for small projects, there's a, there's a real desire for some of us, at least to do our own GitHub runners to be able to do arm builds. I, I may, I may try to get ahold of you offline outside of this discussion because I'm, I'm trying to work through, I mentioned this earlier, I'm trying to work through how to set that up securely and maybe put a guide out on it and.

It would be nice to get a sanity check on that before I tell people how to fix it. So, like, I

Francois: can, I can quickly tell you, like, the way most people do it, like, in a securely, not, but not optimal way is with QMU. So they use QMU to emulate ARM on the GitHub free hosted runner. So it's, it's, it's a lot slower, but it works.

So that's a safe way to do it to say, like run a compile on ARM.

Jonathan: Yeah, yeah. I suppose that's true. Okay. So I, I assume that you're kind of constantly folding your discoveries back into poutine because it's, it's kind of one of those deals where you can only find the problems that you know are problems.

And there's this whole infinity stretches before you with the, with the number of different ways that get hub and get lab actions can be broken. And so is that just kind of a. Constant process of, oh, we found, we found another bad pattern. Let's add this into poutine.

Francois: Yeah, I've very much so, but it's always the, the back and forth between false positive and false negative, any kind of scanner looking for code patterns effectively that are vulnerable, like, If you add something, you may run the risk of, of finding things that are not a problem by like, like as an accident, like you, maybe a pattern that's a bit too broad or vice versa, you're a bit too conservative.

You're not finding the things that when you as a human just look at it, it's like, Oh my God, it's obviously exploitable, but I, I never thought of that code pattern and so, yeah, we, we do go back from time to time and improve that, but then like the more you add, there's performance consideration. So it's.

But we do learn quite a bit with that machinery that I, I call like package supply. That is like the big kind of large scale analysis machinery we have there. We have the ability to quickly run like kind of sniff test. Like sometimes I I see something that just by observing it, like manual inspection looks scary.

Like, I'm like, Hmm, that's almost, almost exploitable. And then I can generalize the pattern and apply like with the. Machiner to scan it and I crossed a million projects and within a few seconds, I can come back and see, yeah, in fact, that one was not exploitable, but then there are 5, 000 projects that appear to be very close to it, so it might require more like effort to manually validate it.

Jonathan: Yeah. Interesting. Dan, did you want to jump in with a couple?

Dan: Sure. Yeah. So I was reading up about another project that you guys released open source called living off the pipeline, which is a great name, by the way. What is that and how does it relate to Poutine?

Francois: Yeah. Living up the pipeline. It relates in the sense that as we were doing more and more of those responsible disclosures, we started to find.

Common patterns namely when you're accepting contributions from work and you want to run tests, for instance, right? What are tests? Like, you know, PyTest or whatever. Any kind of test, test tool, effectively, it's a binary that will take source code, execute it, as in the context that those are tests. But then, if the tests are modified by a contributor, they literally are PyTest.

You know, code execution by design, nothing, nothing more. So that, that is kind of an obvious scenario, like, and that is maybe too obvious, but there are many tools that are, that contain like little known features that most people don't even know about if they don't, you know, read the documentation in full that are dangerous, like mainly a number of.

Even security tools have kind of power user features to configure them with plugins, for instance. I'm not going to name some because you can go and find in the living of the pipeline project. And you'll find that some security tools, you can configure the behavior with simply adding a file like dot, you know, dot the name of the file that shall not be named, dot yaml.

And you can specify a plugin and the plugin can literally be arbitrary bash stripped or something. So then you run the tool thinking that it's just going to like, let's imagine puts in, have that feature, but that puts in like, we specifically design. With that scenario in mind, because we knew that other tools have made that mistake so that we can safely run puts in like even on untrusted code.

But like, in that case, if you can modify and add a malicious plugin on the fly, then yeah, it's a problem. So there are a number of examples you can find that. So it's really about. Creating an inventory of tools that CLIs, namely, that have features that are kind of foot guns, right? Like

Dan: Yeah. So I was curious, we've already mentioned messy poutine, which is your capture the flag kind of project, if you like. But I want to talk a little bit more about that. If anyone listening to this is interested in maybe trying that. How would they go about that? And can you just tell us a little bit more about how they would get involved in that sort?

Francois: Yeah. So they would simply need a GitHub user account. They can create a different one if they want. In fact, I would, I would maybe in that case, it's not so much important, but you can have different personas kind of but in that case, this is really a victim project. It's meant to be. an exploitable kind of goat project.

If you're, you know, in the web, web app kind of traditional thing, like you have vulnerable web apps just for practicing education. So yeah, you just go to github. com slash messy poutine in one word, and you will find a number of repos and GitHub action workflows, and they're kind of like by levels, like level zero, one, two, three, some of them have I can interactions, but maybe one, one workflow might trigger another workflow as a side effect.

So you start to play with it, like open pull requests. Like maybe put something fishy in the title, in the body of the pull request. I'm just giving hints. Imagine some kind of bash commands maybe it's all right. Like you can kind of play with that. And the goal being to, to get the flag, you need to exfiltrate those secrets, which are only visible if you get remote code execution in the context of the runner.

In some cases. They are as easy as they've been put as environment variables. So if you get remote code execution, you dump the environment variables, then you get the flag. In other cases, it's much more complex because you need to do a memory dump, like dump the memory of the process to get those secrets.

Other cases, you need like much more advanced Like multi stage attack. There is even one that's a self hosted runner. If you want to practice Jonathan there is one that is a self hosted runner thing, which I designed as a host, a self hosted runner on top of a hosted runner. So it's like a recursive thing.

Anyway,

Dan: excellent. So I was, I wanted to ask you being someone who's been involved in security and and in open source for a lot of years. What kind of changes have you seen over the years as the job changed a lot as the kind of, you know, new threats and new solutions arise. So that was one part of the question.

The other bit, which is a really difficult bit of the question, which I won't blame you for skipping over is, do you have any predictions for the future of where all this is kind of going with this? These threats and vulnerabilities and things.

Francois: It's not the end of the year.

Speaker 5: Like, yeah, we don't do a prediction.

Francois: No, but yeah, I think the industry, you know, since I started my career, I, I've been involved, my, my first open source project was 20 years ago. Like, before the podcast, I went on and found my first message on a mailing list in 2004 with an OpenWrt project that was like a, yeah, Wi Fi dog, a captive portal that we were doing back then.

Yeah. As if by

Dan: magic, I happen to have a, a very old ,

Francois: oh my God. Like I remember, remember those guys short, shortening, shortening the pins and all that to like reset it and like, yeah. Yeah. Mm-Hmm. , that's fun. But yeah, I guess, you know, I, again, I mentioned that ask top 10, there's like the average developer working at an average shop, like writing code.

Is gonna be forced to do some kind of OS top 10 training, even if it's like pre cam boring training That is not very useful. But at the very least I think you can safely assume that most developers have at least heard what's an SQL injection, cross site scripting, et cetera. So it becomes so, and there's just more like secure framework with secure by design, React is kind of, you know, preventing cross site scripting by design, things like that.

So and ORM is preventing SQL injection by design, et cetera. So it's just, the industry is getting more mature for those lowing fruits. But it leaves the door like the attackers just are moving on to the next weakest link in that case, the supply chain is, is the new weakest link in the chain, literally, because it's getting harder to even as an attacker to not get caught.

Like there's, you know, more and more seems like you know, dumping a lot, lots of logs with web application, firewalls, et cetera, et cetera. But meanwhile, You know, build pipelines are just not as monitored in terms of their behavior, what's happening in there is, is some kind of malicious, like abnormal behavior.

So I don't know the other part prediction. Well, I think the prediction is that the. We're just starting to scrap the surface. Like as I said, I'm amazed at how many lowing fruits there are, but sometimes I catch no, not lowing fruits, but they're, they still require me, let's say 15 minutes to get past the non obvious part, but like.

You know,

Jonathan: like, yeah, interesting. Okay. So I've got a project. This, this is not a, not a contrived scenario. This is being big, being pretty transparent here. I've got a project that I suspect has problems and I want to run Putin against it to kind of get a handle on what the problems are. What's the recommended way to do that?

Francois: Yeah. So basically Putin, you can just. Get it, find it on github, boost security io slash poutine. You can run it as a docker container or with homebrew on mac or or you can build it like build it from source yourself with the, with go, and then you just need a read only token to get hub or get lab.

I would advise like to create a, like an on purpose, like just read only token just for that, that that, that use case and you point it to either the GitHub organization and it will discover all the repos. And that are public in that case. But if it's a token that has a visibility into private repos, you can do just as much, so it will automatically discover the repos and iterate one by one.

It will do a shallow git clone in a temporary directory. So it's very much batteries included, like, like the, the, the level of effort to get from installing puts in, or like just running it as a Docker container and finding. Obvious lowing fruits is very, very low. Because you just pointed to like the GitHub repo itself or the entire organization to scan the whole thing and return results within minutes.

I designed it with testing on large organizations like Microsoft organization has like 5, 000 repos or and. It takes about 15 minutes on 5, 000 repos to return like the, the list of results. So it's like, cause we do like shallow clone with just pulling the YAML. So And that's very efficient.

Jonathan: That's great.

Along with that, if I find something that is a real vulnerability, would you guys like to hear about it? Do you have like a form somewhere where people can say, I found this thing and it saved our bacon, thanks.

Francois: To report. You mean like if you've found something in someone else's thing or like in your own and you kind of fix it and like in my own.

And I want to,

Jonathan: I want to tell you guys,

Francois: thank you. Like, is there a tip jar somewhere

Jonathan: or something like that?

Francois: No, not, not at the moment. It's but yeah, we don't have any kind of Patreon or kind of get up and sponsor thing yet.

Speaker 4: But

Speaker 5: at the moment, But like, if you, if you come to Montreal, I'll buy you a poutine or you can buy me a poutine, thank me.

And I'll, you know,

Jonathan: I turn a favor with

Speaker 5: a beer

Jonathan: or whatever. Sounds great. It does boost security offer this as part of their services. Like, is there a, Hey, I want you guys to run poutine once a week against all of my repos. Is that, is that sort of a service that's offered or maybe that you're thinking about?

Francois: Absolutely. It is. It is part of our commercial offering. As I said before, our commercial offering is all about automating the orchestration of those static code analysis tools and aggregating the results. And as we did with other open source projects, puts in, it's just one more scanner that we can easily have our customers provision, get the results in one dashboard prioritize the results.

Yeah.

Jonathan: Yeah. Awesome. I was going to ask you to give us a 15 second commercial on what boost security is about, but I think you just did that. So, I have a couple, I have, let's see, three closing questions I always like to ask. Now, you guys have only had this as open source software for about a month now.

So this one may, this one may be a category error. But I'd like to ask, I'd like to ask Projects, what is the weirdest or most surprising thing that you've seen somebody do with the project?

Francois: Well, it's, it's, it's a bit too early maybe to tell. But and I think, well, where it is, I don't, I think when, one area that for those who are interested to want to play with the tool, try it there, there's something we added recently that adds a lot more flexibility.

We made it into like a pluggable architecture in a safe way. Like we designed it in a way that like you can basically configure. Other rules, like you can kind of bring in your own custom rules or edit, modify existing ones. And that could be used in a more creative way by someone saying, you know, like your existing rules, they don't find what I know is a problem, or I want to find.

Like, dangerous code patterns that are just like specific to my project. And it's possible using kind of the rule engine we've designed, like kind of a DSL, sort of that is specific to GitHub Action or GitLab pipeline at the moment, so. Yeah.

Jonathan: Interesting. Alright. And the final two questions that we ask every guest, what is your favorite text editor and scripting language?

Speaker 4: Mm-Hmm? .

Jonathan: Yeah.

Francois: VIM. Yeah. Vi guy. More yeah, never, never understood the emax. Sorry. And yeah, just like, it just, it is, it, it, it, it's already there. When, whenever USFH somewhere, it's very lightweight. And I know how to exit them. It's fine. And, and scripting language. Python, like if we talk to scripting, but I really like go, go, go Lang.

Like a Putin is implemented and go, but more a script, like to like rough, kind of quick and dirty thing. Yeah. Python is kind of go to

Jonathan: All right, excellent. Thank you. Thank you so much for being here and presenting the project. Very, a very neat project. And like I said, I, I, I think I need to run this because I have a feeling that we have, we have some problems.

So I appreciate you coming and telling us all about it.

Speaker 5: Thank you.

Jonathan: All right dan, what do you think? Do you have a Do you have some git or github or gitlab projects that need this?

Dan: Well, I I didn't think I did but no, you know, I probably do I probably do the more I think about it. Yeah, really interesting project.

I think it's great what they're doing and it's an area that's That is definitely growing I think, in security and so on.

Jonathan: Yes. You know, in the last few years, we've seen kind of these supply chain problems really start to be big deals. And I, I imagine, you know, I, it kind of, it interests me.

He says, when we asked it, you know, it, do we see this being a huge problem with an XZ style? He goes, I would be surprised if it's not already, and we just haven't heard about it yet. It's the sort of thing that keeps me up at night. I'm glad, I'm glad there's people that are thinking about this and looking at it.

And I am just, I'm thrilled that they decided to release this as open source. Get, get all of the eyeballs on it. And, you know, I'm sure, you know, If it hasn't happened yet, one of the things that's going to start happening is they'll get additional rules sent in from the community and it'll just, it'll make the project better for everybody.

It's great.

Dan: Definitely, yeah. And well, many, it's, what do they say? It takes a, it takes a village to raise a child. Child or something. I can't get that right now. I've forgotten the forgotten the whole saying but yeah The more people involved the better definitely I would say I

Jonathan: prefer I prefer the the linus torvalds version of that rule Which is giving enough eyeballs.

All bugs are shallow. I like that one. Oh, yeah.

Dan: Yeah That's that's a that would have been a better way of putting it. Yeah, I agree yeah, but it's fascinating project. Definitely.

Jonathan: Yeah. Yeah, it's great. Okay, dan Do you have anything you want to plug?

Dan: Yeah, very quickly. I mentioned it last time I was here, I think, which is a little while ago, but Liverpool make fest, which I helped to organize is a festival of technology and and arts and all kinds of stuff.

Lots of people building robots and. There's a guy making hot air balloons. Who's going to fly hot air balloons inside the building. I don't know if he's got clearance for that, but we'll find out. Health and safety is, is interesting for that event, but if you, if you're in the UK or you can get to the UK in, in July, the sixth is coming up it's in the, it's completely free to come along and attend and, and get involved.

There's workshops, there's all kinds of stuff. It's at liverpoolmakefest. org is the website. And that's the place for people to go in and have a look. And I think that's about it. Yeah.

Jonathan: Dan if somebody wants to follow you on The social media service formerly known as Twitter or Mastodon. Is there a good place to do that?

Dan: Yeah. At Method, Dan is my username, but if you go to dan lynch.org, which is my website, everything's listed on there.

Jonathan: Alright. And

Dan: I even managed to work out how to get a, a Mastodon feed embedded into my website, which Cool. Took a little bit of JavaScript, which I was really proud of, which is probably really insecure

But there we go, , which I'll now have to go and test.

Jonathan: Yeah. Oh, that's fun. All right. Well, you can follow my work over at Hackaday, hackaday. com. We've got the security column that goes live every Friday, which I think this episode of Floss Weekly will probably get a plug in the security column. That'll be fun.

We do not yet have a guest for next week. If you have recommendations or you're from a project and want to be on the show, it's floss at hackaday. com. Just shoot us an email and we will get you scheduled. Yeah. Yeah, other than that, I just want to say thank you to everyone that watches and listens both live and on the download.

We sure appreciate everybody, and we will see you next week on Floss Weekly.