CVE-2021-42574: More information on exploitation and possible consequences

[Thomas Balasch]

Dear Atlassian-Team (and possibly community),

due to multiple reasons we can not update our Jira and Confluence instances right away and need to further evaluate risk and consequences to make a decision on how to proceed. 

As for now I am in desperate need for more information on how the vulnerability can be exploited by a user in Jira or Confluence and consequences this could have in a worst case scenario.

So to give this more context...

What do users have to do to (accidentally) exploit the vulnerability inside Jira Core, Service Management and Confluence?

As mentioned in the FAQ:

"A user must be able to post content in order for these characters, and potentially malicious code, to be introduced."

- What does this mean exactly? Create a issue on the customer portal? Publish or edit an article in Confluence?

And what could be worst possible outcome? Our instance doesn't have access to the internet is therefor only used by employees. The same questions go for Confluence, which also isn't connected to the internet.

Thank you and have a nice weekend!

Best regards,

Thomas

[Daniel Eads · Accepted solution]

Hi @Thomas Balasch ,

Thanks for this question! I'll split the response into two parts based on the information you're looking for.

A user must be able to post content

Any place a user can submit content, they have the ability to paste code containing these bidirectional characters. That includes, but isn't limited to: creating issues, editing pages, adding comments - any place a user can input text, there is the possibility that they can insert these characters.

The potential outcomes

Having Bidi characters or homoglyph characters by themselves does not pose any direct threat as long as we know that these characters are being used for a reason.
However, since these characters are invisible in nature, some of the users while copying a code snippet from the internet, could just do a copy-paste without realizing the content and this could be bringing in malicious content into the system. Though nobody can gain access to the system just by these characters, it is better to know whether these characters exist in the system at all, and that's more or less what our fixed versions do. We highlight the bidi characters whenever added to the application.

For this vulnerability to be exploited, malicious code still needs to be executed by the victim. The attack only enables for an attacker to hide malicious code in existing code bases - not execute it. Hence, our cloud and server products make sure that we make it abundantly visible and obvious to our users if these bidirectional characters exist in any codebase or code blocks, when viewed in our products. However, there is still a possibility of malicious code slipping past human reviewers in an off chance. Please exercise caution around using code snippets from untrusted sources until there are lower level defenses in place such as this vulnerability being mitigated in common code compilers.

So in short, if we have bidirectional characters inside the application, then the code could behave differently than what is intended. Users might not manually write them, but if they are copying any source content from the web, then they should be careful.

Let me know if that helps or if I can clarify anything further!

Cheers,
Daniel | Atlassian Support

[Thomas Balasch]

Hello Daniel,

thank you for getting back to me so fast! The additional information definitely helps.

If I have any follow-up questions, I will let you know. Thanks again!

Best regards,

Thomas

[Matt Doar · Accepted solution]

The fix in Jira DC 8.13.13 is to show the bidi characters when the text is within a code or noformat macro in the Description field or a comment. 

You can check for the existence of the bidi characters with the following long-running queries but the characters may just be because someone was editing harmless text right to left and then pasted it into Jira.

# Check the Description field

select id from jiraissue ji
where
(
    ji.description like concat('%', x'e280aa', '%')
    or ji.description like concat('%', x'e280ab', '%')
    or ji.description like concat('%', x'e280ac', '%')
    or ji.description like concat('%', x'e280ad', '%')
    or ji.description like concat('%', x'e280ae', '%')
    or ji.description like concat('%', x'e281a6', '%')
    or ji.description like concat('%', x'e281a7', '%')
    or ji.description like concat('%', x'e281a8', '%')
    or ji.description like concat('%', x'e281a9', '%')
);


# Check comments

select issueid from jiraaction ja
where
(
    ja.actionbody like concat('%', x'e280aa', '%')
    or ja.actionbody like concat('%', x'e280ab', '%')
    or ja.actionbody like concat('%', x'e280ac', '%')
    or ja.actionbody like concat('%', x'e280ad', '%')
    or ja.actionbody like concat('%', x'e280ae', '%')
    or ja.actionbody like concat('%', x'e281a6', '%')
    or ja.actionbody like concat('%', x'e281a7', '%')
    or ja.actionbody like concat('%', x'e281a8', '%')
    or ja.actionbody like concat('%', x'e281a9', '%')
);

[Matt Doar]

But the bottom line is that if anyone copies source code text from Jira or Confluence, they should use an editor and a review tool that displays unicode characters. That way they won't accidentally introduce the hidden text into the code base.

[Thomas Balasch]

Hello Matt,

thanks for providing further insight! This might be helpfull, until we decide on a Roadmap regarding update, migration (DC vs. Cloud) etc.

Currently either Jira nor Confluence are used for Software development and therefore shouldn't hold any code apart from snippets written directly by colleagues in the IT department.

Best regards,

Thomas