Well, it’s good to be back. Where was I? Well, the last two posts were posted while I was traveling on Vacation! My wife and I had a wonderful time, and taking a break let me think of all sorts of new ideas for both the Blog and the Brand. But more on that later.
My wife and I started our travel back last Friday. However, as I was packing up, I got a curious notification from LinkedIn. I had been tagged in a post – that itself wasn’t too much of an anomaly. But it’s what the post said that caught my attention. It was from Jens Kisters from APTIS, and it was asking whether a new vulnerability found in log4j impacted Atlassian products.
Well, I was up early, and I had a few minutes. This was a massive new bug that hackers had found, and the news was growing by the day. So today, I want to look at what is log4j, CVE-2021-44228, and what it means for your Atlassian Instances.
What is log4j?
So, here’s a simple premise: You should not reinvent the wheel. If something is good enough to serve the purpose, use it instead of making a new version. This premise holds for Software engineering, too.
Log4j is a package that people writing software in Java can include in their builds, and it handles all the logging for the project. So if you need something printed to a log file, call the functions, and boom! It’s there.
The fact that someone else is worried about maintaining it as things change and evolve makes its inclusion pretty popular. You have enough to do when building a project; not worrying about this little detail is appealing. That’s why we are finding that it’s seemingly used everywhere. Some projects found using it include Minecraft: Java Edition, iCloud, Steam, and Twitter. Here’s where it hits home: Atlassian Products also uses a version of this, which spawned the question above.
I was looking through my repositories, and while I don’t have any Java Projects yet, I found I had included a port called Log4js in my NodeJS Discord bot. Thankfully, this bug didn’t impact that particular package…yet.
Alright, what is CVE-2021-44228
CVE-2021-44228 is a bug recently found in Log4J, and what it does is allow an attacker to run any code they want on your server, remotely and without authentication. I covered this a few months ago when Atlassian had found the same kind of vulnerability in Confluence.
But think about it: They can do whatever they want if they can get code to run. Play a prank by changing some files? Sure! Set up a crypto miner? Why not! Open a backdoor? Totally possible. Run a ransomware attack? It’s already happening. As far as bugs go, this type is a hacker’s dream. No matter what they want to do, this vulnerability lets them do that by executing arbitrary code. That’s why this bug has been colloquially called Log4shell.
Then we take that and consider my previous point: Log4j is seemingly everywhere. That means that there is now a lot of packages that include it that are now vulnerable. I heard one security researching call this a holy grail find, and I can see why. This kind of inherited vulnerability is called an upstream attack. Finding a bug in a package that is included in a bunch of other packages multiplies the effects of the bug. That is why this flaw is what everyone in I.T. is talking about.
So, how does this impact Atlassian?
Atlassian has released two separate statements about Log4Shell. As they both detail Atlassian Cloud and Atlassian On-Premise offerings, we will too. If you would like to read the statements for yourself, here they are:
- Multiple Products Security Advisory – Log4j Vulnerable To Remote Code Execution – CVE-2021-44228
- FAQ for CVE-2021-44228
So, what do they have to say? Let’s dig into this:
Atlassian Cloud
This is likely the most satisfying answer but also the most curious. Atlassian states that the bug has been mitigated in all cloud instances and is no longer a concern. No, really:
This vulnerability has been mitigated for all Atlassian cloud products previously using vulnerable versions of Log4j. To date, our analysis has not identified compromise of Atlassian systems or customer data prior to the patching of these systems. Atlassian customers are not vulnerable, and no action is required.
Atlassian
This statement tells me a few things: This bug was present on their Cloud instances. That is quite interesting compared to what they had to say on their On-Premise instance – which we’ll get to in a bit. It also tells me some Software Engineers, QA, and P.M.s worked through the weekend to fix it – as until yesterday, these documents instead said that they were “Evaluating” the impact of this bug.
It also tells me that while the cloud products also run in Java, they are making much more backend improvements and fixing technical debt – moves they are not making on Atlassian DC. This is interesting – but, maybe I’m reading too much into it.
But the tl;dr here is that if you are on Jira Cloud, Confluence Cloud, or Bitbucket Cloud, your instances are safe from this bug.
Atlassian Server and Data Center
The main takeaway is that the version of Log4J used by the On-Premise instances is too old to be affected by this bug. Let that sink in for a minute. The version used is so out-of-date that it’s not impacted by a bug that affects the rest of the internet. That…is quite the statement and not necessarily a good one. When people say Atlassian is ignoring their on-prem offerings, this is what they mean.
Now let’s be clear – because I know Atlassian will call me out if I don’t mention this. Atlassian forked Log4j on version 1.2.17 – before the bug was introduced – and has been maintaining that fork since. So, it’s not as if they had just included the package and never updated it. Instead, they opted to take what was offered and maintain it themselves – something you can do. But it still doesn’t look good.
However, while the Server and D.C. versions of their products are not affected by CVE-2021-44228, they did identify a possible configuration change that Admins can make that would make them vulnerable. So to make this version of Log4j vulnerable, you have to have made all three of these changes (and I’m copy/pasting from Atlassian here):
- The JMS Appender is configured in the application’s Log4j configuration
- The javax.jms API is included in the application’s CLASSPATH
- The JMS Appender has been configured with a JNDI lookup to a third party. Note: this can only be done by a trusted user modifying the application’s configuration, or by trusted code setting a property at runtime
The way I read the advisory, you would have had to make all three of these changes to have the vulnerability appear – so undoing any of the configuration changes should mitigate the risk.
Update 2021/12/17: Atlassian has updated its security advisory around CVE-2021-44228. It now contains the following two bits of information about Bitbucket Server and Data Center (and again, I quote Atlassian verbatim):
- Prerequisite software, Elasticsearch, used by Bitbucket Server & Data Center may be vulnerable to CVE-2021-44228
- Some Bitbucket versions included an unused log4j-core component which has been removed in the latest update.
The advisory goes on to specify what versions of Bitbucket Server/DC and Elasticsearch are vulnerable, and what you need to do to mitigate it. If you are running a local Bitbucket instance, please be sure to read it.
Marketplace Apps
I’d be negligent if I didn’t mention the Marketplace Apps. For Cloud products, the framework provided by Atlassian for Apps means they are not vulnerable to this attack. However, Atlassian continues to review third-party apps to make sure they are not vulnerable to this or other known exploits.
For Data Center and Server Apps, Atlassian is working with the Marketplace Partners to ensure they are not vulnerable. Where Atlassian discovers vulnerable Apps, they give them an “expedited deadline” to fix the problem or be removed from the marketplace. Most Apps use the built-in Java APIs provided by Atlassian, so their apps would only be vulnerable if Atlassian’s products were. But for those that include Log4j themselves, it’s “fix it fast or don’t even bother.”
Final thoughts
So, that’s how Log4j is impacting the Atlassian space. I’ve seen this question come up repeatedly. So hopefully, putting this out there will help people clear some things up.
Before I go, I wanted to announce something here. I’m going to be started a weekly stream on Twitch & Youtube on Wednesday afternoons (5 PM Eastern, 2 Pacific) to answer questions, talk about the latest post, and whatever else comes up. Today, for the first stream, I’m even going to be doing a live unboxing event. Appfire sent me a package, and won’t tell me what’s in it, so we’ll find out together. You can find me on Twitch and on Youtube.
You can also find me on Social Media links by clicking on my Linktree. So be sure to follow me on your platform of choice – I’m committing myself to be more active on all the platforms. So you’ll get updates, news, and whatever I find interesting from the Atlassian Ecosystem!
You can also subscribe directly to the Blog. Just fill out the form at the bottom of the post, and whenever I publish a new post, you’ll get it as an email!
But until next time, my name is Rodney, asking, “Have you updated your Jira issues today?”
The Jira Guy 