In this episode, we're joined by Damien McKenna to talk about open source security and how that has changed over the years in Drupal core as well as in newer versions of Drupal. Damien directs internal initiatives that strengthen Mediacurrent’s commitment to open-source principles, collaboration, and sharing knowledge to strengthen the Drupal community and is regularly ranked as one of the ten most active contributors on drupal.org.
Episode Transcript
Mark Shropshire: Hi, I'm Mark Shropshire and with me is my cohost Mario Hernandez. We are very excited about this episode of the Open Waters podcast as we welcome Damien McKenna, a prolific Drupal contributor and community leader. We will be talking about open source security, specifically the ins and outs of Drupal security.
Mario Hernandez: Thanks, Shrop. Thank you very much, everyone, for joining us and a special thanks to Damien for joining us today to talk about security and contribution to the Drupal project. So Damien, before we get started into the technical aspects of your role, why don't you tell us a little bit about your role on Mediacurrent and your involvement in open source?
Damien McKenna: Thank you for having me. So I've been involved in Drupal since 2007, but open source as a whole, since around about 2000. I got into it because I had been building my own websites that expanded into building custom content management systems, and I realized I couldn't be the only person who wanted to have a simple CMS to manage their site's content or their clients' content. Discovered hey, there's a whole bunch of people who were uploading complete open source, complete PHP projects, as they were at the time to the net on SourceForge. I can just download it and customize it how I need.
Over the years, I saw a number of patterns emerge with open source communities. A big one was that for any given software project, if it didn't have a security team put together fairly early on, they would need one fairly soon. I saw so many projects that didn't have decent security practices and they eventually ran into a major security problem and had to scramble together the processes to deal with it properly. So I've been very glad that Drupal started their security team fairly early on, and it has been continuing ever since. So at Mediacurrent, I juggle both being a backend developer and project lead along with I lead, cat herd, on some internal initiatives around open source offer and contributing. We try to have a contrib first process so that we are contributing back improvements and things to open source communities and software when it's suitable rather than leading projects to have to maintain more and more custom code and documentation and things.
Mario: I'm gonna go with a follow-up question on that because that's very important what you just said there, Damien, the contribute first. So does that mean when you are tasked with analyzing the project that you about to work on, do you figure out ways in which maybe through this project you can contribute to the Drupal project or the open source in general? Or how does that work?
Damien: Exactly. So there are lots of different situations where it comes up. One example was a few years ago, one of our clients needed to have, requested documentation on how to set up their site to be able to pull in tweets from their Twitter account. And it was just when Twitter had changed the API process. So you used to be able to just pull an RSS feed of the tweets and they changed it to needing to set up a developer account and this custom application in their system.
And it was a bit elaborate and you had to do it from the account that was pulling the tweets because of security best practices. You didn't want to be sharing around these passwords for everybody to log into your Twitter account and accidentally post some screenshot of a picture of a meal out or being with some friends accidentally to a business account. So we put together documentation on how to go through the steps with screenshots and everything, but instead of putting it into a document and sending that to them, we uploaded it to the documentation section for the project that was being used to pull down the tweets so that everybody could then have the same documentation. It was the same amount of work, it was just putting it in one place versus another. So the client appreciated it, they had all of the details they needed, and then everybody else in the world who ran into the same situation then could benefit from the same work.
Shrop: Yeah. That, that's, that's a fantastic example. I mean, I know you have a lot of examples of contrib first, Damien and, personally you're a mentor to me and I appreciate all the guidance you've given me over the years and continue to on how to work in open source overall, but also in the Drupal community. And so I just want to say that I appreciate you and everybody else that does that for the community. It's, it's really great. So I want to jump a little bit into your involvement with the Drupal security team and I think that's an interesting aspect here, since we're talking about open source security today, what's it like being on the Drupal security team and then from a day-to-day standpoint? I know there's lots of things that you have to embargo til advisories come out, but you know what you know, what's it like day day-to-day, what's it look like?
Damien: Sure. So we have different processes that we've, for the most part, documented on drupal.org/security-team. There's lots of details in there, but we have a team of, I forget if it's 20 or 30 so odd people, and one step, I guess, an initial starting point is that we take turns being the initial point of contact. And as it happens, I'm on duty for the next two weeks, so timely. What that means is when somebody opens a security issue for a project, module, theme, or even Drupal core, that we're the first person to respond to that, to review what is submitted, and try and do a little bit of analysis on maybe the person just had one of the settings misconfigured. Maybe they have the PHP module enabled and they're inadvertently letting anybody write PHP code on their website.
Not that that has ever happened, but we do an initial bit of triage on the issues that are opened and then get the maintainers involved, presuming that it requires it, presuming it's a legitimate issue. And then try to guide the conversation between the maintainers and the person who reported the issue and potentially anybody else who's pulled into the conversation. So we might have an issue that is focused on the control module, but it might say affect core or affect somebody in the backdrop community as well, because there's a lot of overlap between the two. Occasionally there might be an identical issue for a similar module, and we try to get conversation focused on moving towards a solid, reliable fix, and then work with the maintainers to prep for release. We also have a mailing list where people can post questions to.
And that is often used as a step towards then having a proper issue in our security issue queue. So then it's, whoever's on duty then is the first person to respond to questions when they come in.
Shrop: How many of those do you think you get in a given week?
Damien: On average, not too many new ones each week. One thing that I found is that sometimes you'll have, especially in the contrib world, somebody will spot...Hey, there's this one situation where this module leaves a security vulnerability open or vector open, and they'll go and check some other modules that have, say, similar functionality or some similar approaches and then they'll, they might discover, say five modules have basically the same bug. But that doesn't happen very often.
Mario: What would you say is the most common security and the Drupal open-source work?
Damien: So the most common one is cross-site scripting, and this is going back to, at least a few years ago, there was an article published on Wiley by Greg Knaddison who wrote the book Cracking Drupal, and he went through and cataloged at all and cross-site scripting was the most common by a good margin where basically the output from a field or some data input was not being properly filtered during display, o that would leave it open for somebody to, say, throw in some JavaScript that would then get executed when the page was viewed. And so that one comes up quite often, and there are some relatively simple means of fixing those bugs. Biggest issue I found is forgetting where in your code something might be filtered already by the time you get it at this one piece.
So sometimes you've got a settings form and it might be available to people who aren't administrators, and you might forget to filter the output because somebody who's an administrator to the site is kind of assumed that they're not going to cause problems for that site. Generally, as a company, employees, don't go bananas and start throwing filing cabinets around. Likewise, they tend not to start throwing in a really bad JavaScript into a site for the purposes of stealing data, et cetera. It's technically possible, I'm sure it has happened, but tends not to happen. So when you're writing code or writing code for a site or for a project, or for a module, you might forget in this one situation, I'm outputting a variable or a configuration object or something and you might forget to filter that one time because when you're testing it, you never try throwing in JavaScript because what silly person would do that? But from the point of view of trying to keep it secure, you need to cover for the situations where somebody might want to do that.
Shrop: If you can execute JavaScript on a site, it's pretty powerful.
Damien: Yes. It's not as bad these days, because Drupal Core and eight and nine don't have the PHP module in core anymore. It was a lot more dangerous when the PHP module was in core because there were so many situations where people inadvertently had that available to all text fields including, say, a comment box for submitting a comment to the webmaster or owners. Yeah.
Shrop: Oh, wow. Yeah, you can think of all kinds of terrible situations that could come with that. Like just reading the settings file in PHP or something. Well switching gears just a bit, because I'm always interested in this and, as you know, in our teams at Mediacurrent, we, we have discussions, we have a security channel in Slack where we discuss when a security advisory comes out, we're always wanting to read it and dissect it as a team and figure out like, all right, what are our next steps for those? Are there mitigations and things like that? I'd love to hear from your standpoint, Damien, in your expertise around this, tell us a bit about those Drupal security advisories and the details they contain. And I mean, just curious about, you know, that coverage for that. I know it's well-documented but there is a lot of information in these advisories, right?
Damien: So there's always a balance between giving enough information and giving too much because you don't want to give people who want to write scripts to attack sites step-by-step instructions on how to do that. You just want to kind of give enough clues that people who are maintaining sites can tell whether or not this is going to affect them right now, and that they need to update right now ahead of anything else they're doing versus, say, it can be just included in the next scheduled deployment.
That could be a week or three from when it comes out. The security advisories will try to give some at least hints on what causes the vulnerability and then, if there are any available, some details on how it can be mitigated. So sometimes it'll be the security problem only happens if you turn off these options or if the person does not have a particular permission. So we'll indicate in the advisory any workarounds that might exist. Oftentimes there won't be obvious workarounds that are feasible, so the only step is to just update the module or theme or whatever it is, or core. We used to do one security advisory per project per week. So per week that there was a security update. So if there were multiple vulnerabilities, they would all be lumped into one security advisory. That policy was changed so that every individual security issue gets its own advisory. And that was to fit with industry standards because Drupal was, I think, just about the only major project still doing it that way.
Shrop: But from my standpoint, it's made it easier for me to comprehend what's going on. I can, you know, read one focus on it. All right. How does that apply mitigations? Are there any, and then you just move on to the next one. And so that's been great from my standpoint.
Mario: Switching gears a little bit here, Damien. So we know that with the release schedule that Drupal has in place, you know, there's a lot of benefits and people have seen things improve, you know, once the new release schedule was implemented. But can you tell us how these release schedule has helped with security, with the Drupal project?
Damien: The schedule has really helped from the point of view of having a plan or a schedule ahead of time that, you know on certain days of the month or certain months of the year, you're going to have security updates available.
Damien: So every Wednesday, starting by the simple thing of all of the security releases are done on Wednesdays. Almost always. There can be some occasional out of schedule updates when there's, say, a third-party library or something that has an update, and we have to scramble to do a core update on a different day, but almost always they're on Wednesdays. And then the core updates are done on one day and contrib updates. So one day a month, there's a window for core to have security updates, and if there isn't one on that day, then there won't be that month. Again, unless there's some or some other issue with a third-party library. And so site maintainers or site owners have a bit of relief knowing that there isn't, almost isn't, going to be a major security release dropping any time of the week, any time of the day, so they can rest easy and just go about their normal business the rest of the week, the rest of the month, and just be able to plan Wednesday afternoon, timezone depending, they will have to do some security updates.
Mario: Good. So what's the story with the Drupal eight reaching end of life? What's, what's going on there?
Damien: Well, it's a standard thing that, or it always has been a standard thing that when a new major release of Drupal core comes out, that the previous release goes into kind of a security updates only mode and then the version before that is marked as end of life so that there won't be any more security updates on that, and pretty much at that point, the community stops maintaining core and contributed modules and themes for that version. In practice, (it) historically meant when triple seven came out, that Drupal five was no longer given security updates and support. When Drupal eight came out, I think it was like eight years after Drupal seven, sorry, after Drupal six had been released, they gave and, if I remember correctly, they gave an extra six months of support just to help bridge the gap of time for sites to upgrade because the development cycle from seven to eight had been so long.
But then, when Drupal nine came out, Drupal seven was still around and still had support. When Drupal 9 came out, the majority of Drupal sites were still on Drupal 7. I forget if it was like two thirds or so of the sites in the world that were on Drupal were still using Drupal seven. So we couldn't just say no Drupal seven is not going to have anymore support, io it was given extra support. Then the plan is that Drupal Ten is going to be released next year, and so there's the knock on effect of you need time to upgrade from core version to core version. And so Drupal eight will be, we'll reach end of life this year. The nice thing is that upgrading from eight to nine is a very, very simple process, especially in comparison to previous sites or previous versions.
We've done some upgrades where a site was fully up to date on contrib modules and was able to be upgraded to from eight to nine with just a few hours of work, and most of that was just poking at Composer to get the right combination of dependencies.
Mario: You're saying that Drupal seven's end of life is actually going to happen after Drupal eight's end of life, yes?
Damien: Yes. So Drupal eight's end of life is tied to the dependencies it has, and its dependencies will run out this year. So I think, it's the big dependency that is causing it is Composer.
Shrop: I think Symphony symphony is part of it, too.
Damien: Composer, symphony. Yes.
Mario: So these end of life decisions are made mainly based on those dependencies, in the case of Drupal seven, it was probably because of the, the adoption that Drupal seven has had gotten, yeah?
Damien: The reason for continuing to support Drupal seven was because of the volume of sites out there that had not upgraded yet and because there wasn't the technical requirement. The dependencies for Drupal seven were still continuing for longer. Drupal seven had fewer third-party dependencies than Drupal eight. So it's easier to say, yes, we're just going to continue it.
Mario: And the future that as the dependencies get shorter and shorter, right, that the actual analyze for future versions may even become shorter than what they are now, perhaps, especially if the upgrade path is such, that is seamless there becomes time where it's just a matter of upgrade and the next installing the next update. And now you're in the next version.
Damien: Yeah. So, keeping a site up to date with the latest version of core, for the major release that you're using, and then keeping all of the contrib module updates, will ultimately mean that it doesn't matter if it's six months or three years between major versions, if it's up to date and you keep it current, it should be a relatively straightforward process. So Drupal eight will hit its end of life this November. Drupal seven has an extra year of support to November '22. So there will be more time for sites to finish upgrading to Drupal nine at that point.
Shrop: I'm glad you mentioned that. They'll just, that'll be the recommended path, just to go straight to nine. You, you won't even have to go through eight at that point, or actually even today, you'd want to go, I think (Drupal) ten is in June, June next year. Yeah. So, so it's moving fast, but it, and I'm glad you mentioned that, Damien, that the upgrade paths are smoother, and that doesn't mean a complex site could have some complications and if you haven't kept things up to date, but from any of us who've been in the community a long time, it, you really don't have to approach it like we're going to build a new site and then migrate all the content. Now it's like actually true upgrades and there's migration paths and it's really great.
Damien: Yeah. So it's more of a traditional once you get onto Drupal eight, plus it's more of an upgrade rather than a rebuild. That's the last major upgrade. Yeah.
Shrop: So get up, get on the new Drupal train then, and I think train is a good visual representation that the community's used to illustrate the end of life for some of these, the train tracks end at a certain point, you want to be on the train track that keeps moving forward. Damien, what kinds of Drupal security resources do you think folks listening should know about?
Damien: So the most important one, I would say, is the security advisory newsletter that everybody can subscribe to off of their profile on Drupal.org. There's just a nice, if I remember correctly, a nice checkbox for that. The security advisories are also available through an RSS feed, and they're also published on Twitter through the website. There are separate feeds for core, contrib, and public service announcements.
So depending on how you like to get your security updates, do all three. Then there's also, as mentioned before, documentation on the security team's processes, and under the Drupal eight documentation, there are pages that describe best practices for writing secure code. So you can avoid security problems while you're building the site rather than dealing with them later. There are a number of books out there, most notably the Cracking Drupal book by Greg Knaddison mentioned earlier. It was written before Drupal eight came out, so it's a bit out of date, but the general practices are still reasonable. And for every function it mentions, you can find the equivalent Drupal eight or nine replacement through documentation online.
Shrop: Well, Damien, we really appreciate your your time on the podcast today and for coming on and talking about, you know, specifically Drupal security, but also, you know, a lot of these concepts, like you were mentioning about Greg's Cracking Drupal book, you know, security is evergreen, it does change over time, there's maybe new things, of course, we learn about securing our systems, but some of those old things are still out there like cross-site scripting. They just are probably going to be for a long time.
Mario: They don't go away.
Shrop: Yeah, exactly.
Mario: Well, Damien, thanks again for joining us today and sharing with us your expertise when it comes to security and the Drupal project. I also personally want to thank you for always being available and helping us with any security or contrib questions that we have. You recently helped me contribute to a project, and that was pretty rewarding to be able to do that.
Damien: You're very welcome.
Shrop: Thanks for listening. You can find us at mediacurrent.com/podcast and subscribe with your favorite podcast app. If you enjoyed this episode, share it with your friends and tag @Mediacurrent on Twitter. For more resources on open source technology, web design, and web strategy. Visit us at mediacurrent.com.
Resources
- Damien Drupal.org Profile
- Find Damien on Twitter
- Drupal Security
- Drupal's Security Advisory Policy page