about log4j

[lei]

I need to get an announcement about: cve-2022-23302, cve-2022-23305, cve-2022-23307

[Daniel Eads · Accepted solution]

Hi @lei ,

A common method for getting information about CVEs when Atlassian have not published a security advisory is to check our public Jira instance. Here is a link to a search for the 3 CVEs you mentioned .

Please see our Security Bug Fix Policy for more information about the questions you have raised.

Also note that @Nic Brough -Adaptavist- is not an Atlassian employee - the Community Leader designation next to his name indicates that he has moderator privileges here on Community, which is a public forum. Atlassian employees are indicated by an "Atlassian Team" lozenge next to their name.

I'll also mention that the Trust & Security group is the place where you will see official messages from Atlassian's Security team here on Community. Atlassian's Security team will also utilize email to notify administrators of any security advisories we have published.

Thanks,
Daniel Eads | Atlassian Support 

[lei]

Thank you very much. I'll make a request now

[Jason Unsworth]

 Here is a link to a search for the 3 CVEs you mentioned .

Actually, I'll note that search link currently just leads to issue JRASERVER-62838, which doesn't discuss the first CVE (CVE-2022-23302) at all, and only started discussing the latter two CVEs (CVE-2022-23305 and CVE-2022-23307) a few hours ago.

[Nic Brough -Adaptavist-]

The best thing to do with CVE reports is to subscribe to the updates on the CVE reporting site that you prefer.

I think Atlassian are better than most organisations when there is a security problem.  (If we go to the extremes, Atlassian announce security issues within weeks, but we're still waiting for MS to announce "Windows is insecure" 40 years after the insecure release of 3.1)

If you want info about these reports of insecurity, look at the independent reports.  Do not trust the vendor just because they get other stuff right.  

Read the CVE, then read what the vendor says.  Maybe subscribe to the vendor's security feed.

[lei]

JIRA software 7.2.xx is facing shutdown due to log4j(cve-2022-23302, cve-2022-23305, cve-2022-23307) in our company

So we need a statement that it's okay or not

How should I prove it?

If it's okay, could you please give user a proof

If it has a problem, please tell user how to solve it

[Nic Brough -Adaptavist-]

You'll need to work it out from the CVEs - they have not been evaluated yet so no one has done the work to say whether any particular application may be affected.

[lei]

Do you have a time plan?

[Nic Brough -Adaptavist-]

Um, for what? 

If you are asking about what I personally plan to do about an undefined, unevaluated and probably-not-affecting-me CVE, then my time plan is "wait until someone works out it could be a problem and announces it and then look at the systems I look after to see if they might be affected".  I can't put dates on it, I don't have enough information.

I've skimmed the ones you mention, I can't see them being an issue, but without the evaluations and impact analysis done by people who understand them better than I do, I can't see a problem with the systems I look after.  The attack vector seems to be "an admin could let bad thing happen", and I only let in admins I trust into my systems.

[lei]

Well, yes, there's no problem at the moment.

However, this kind of CVE has occurred. Because it is a hidden danger, our company is not allowed to use it.

So please confirm and make a statement, OK?

At least have a plan. Let's explain it to the company.

Please.

[Nic Brough -Adaptavist-]

Er, it's not up to me to confirm anything (I don't even know what you think needs "confirming"), nor make a statement about it (as I don't know what it is).

You'll need to build a plan and explain it to the company, I can't do that for you.   What exactly do you want to plan for?

[Steve Hadfield]

I think the issue here is that @Nic Brough  is with Adaptavist, not Atlassian, so maybe @Daniel Eads would be able to answer the question.

Lei isn't the only user who works for a company that can, at times, freak out about security alerts. We all went thru several of these with log4j this past December - while many of us were on vacation. My Confluence instance would have been shut down if it was affected by the December log4j security alerts. For me to upgrade our Confluence instance takes about 4-5 months of work, validating plugins & their interactions, our custom authentication, and our custom plugin - its a long ordeal. A patched custom log4j would be a godsend, as I'm still on 7.4.8.

Atlassian uses a custom version of log4j, so the only people that can upgrade log4j is Atlassian. And the goal of the security alert(s) is to move to v 2.x or log4j, and any change of log4j from 1.2 to 2.x may involve a substantial effort on Atlassian's part because they are so far behind, version-wise for lo4j.

[Maximilian Heyne [Communardo]]

@Steve Hadfield i totally agree with you! Larger, more complex instances can't be updated within a couple of days and it takes a lot of work in general. And most of the time there isn't just one applications but many more!

It is really frustrating to see old, or even EOL implementations (like Tomcat, Log4j, etc) in these enterprise systems that can face serious risks to the whole corporate network. 

We even saw CVEs listed with no visible documentation from Atlassian. The way these CVEs are documented, communicated and fixed for the community is not how Atlassian should deal with it (Open company - no bullshit).

[Roel Storms]

We are 2 months later and there seems to have been no update.

[Maximilian Heyne [Communardo]]

@Roel Storms we have created a support ticket. Unfortunately there is still no final report about this. 

However we have received an indirect statement from the security team. This problem does not seem to affect any Atlassian application. 

CVE-2022-23302 and CVE-2022-23307 can only be used if the attacker already has access to your systems hence the problem is a lot bigger than what initially thought to be. 

CVE-2022-23305 is only appliable if JDBCAppender is configured. You can verify this in <install-directory>/atlassian-jira/WEB-INF/classes/log4j.properties

We are still waiting for a final report about these instances and regarding the security score this should be a valid demand. However thank to the assistance of the support member we have made our conclusion and will not further investigate this. 

Actually this should be documented in JRASERVER-62838 or any other ticket.