December 11, 2021
Apache Struts Vulnerability – Dec 2021
Comments
(5)
December 11, 2021
Apache Struts Vulnerability – Dec 2021
Newbie 3 posts
Followers: 0 people
(5)

Hello All!

I was looking forward to a calm Friday afternoon, reading tech news…and I came across articles talking about a vulnerability in Apache Struts, and how it can be easily exploited.

Oh no!  There went my calm Friday afternoon!

But, I did a lot of searching for a solution aimed at my level of Java users (pretty much zero level).  The best I came across was a post by Pete Freitag, which suggested that I add a line to my JVM Arguments in the CF administrator.  My JVM Arguments now read:

-server –add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED –add-opens=java.base/java.nio=ALL-UNNAMED –add-opens=java.base/java.lang=ALL-UNNAMED –add-opens=java.base/sun.util.cldr=ALL-UNNAMED –add-opens=java.base/sun.util.locale.provider=ALL-UNNAMED –add-opens=java.base/java.net=ALL-UNNAMED –add-opens=java.base/java.io=ALL-UNNAMED -XX:+UseParallelGC -Djdk.attach.allowAttachSelf=true -Dcoldfusion.home={application.home} -Duser.language=en -Dcoldfusion.rootDir={application.home} -Dcoldfusion.libPath={application.home}/lib -Dorg.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER=true -Dcoldfusion.jsafe.defaultalgo=FIPS186Random -Dorg.eclipse.jetty.util.log.class=org.eclipse.jetty.util.log.JavaUtilLog -Djava.util.logging.config.file={application.home}/lib/logging.properties -Dtika.config=tika-config.xml -Djava.locale.providers=COMPAT,SPI -Dsun.font.layoutengine=icu -Dcom.sun.media.jai.disableMediaLib=true -Dlog4j2.formatMsgNoLookups=true

Does this look like it will mitigate this issue?  The last argument, suggested by Pete, is in bold.

I have shut down my development servers, and I would love to shut down production, but…that isn’t really feasible.  I would also like to upgrade the Log4J, but honestly, I can’t figure out where to make a change to point to the newest version.

Any hints on protecting from this problem would be greatly, greatly appreciated.

Thanks!

5 Comments
2021-12-14 22:45:27
2021-12-14 22:45:27

And still-more updated info, now finally we have a formal response from Adobe, in their technote:

Log4j vulnerability on ColdFusion

It covers what to do for now for CF2021, 2018, their related PMT and API Mgr counterparts, and indicates that an update for CF2021 and 2018 is due on Fri Dec 17.

The technote also discusses briefly CF2016 (which by association would be inferred to apply to CF11 and earlier…though those on versions older than CF2018 should take this as their strong cue to get updated to a supported CF version.)

Like
2021-12-14 13:50:52
2021-12-14 13:50:52

Following up on my previous comment, I have posted a blog entry here in the portal to point people also to the resources and options available for now.

Dealing with the recent log4j vulnerability, before Adobe releases an update

 

Like
2021-12-13 14:06:15
2021-12-13 14:06:15

First, note that it’s not a struts vuln (as that would not affect cf), but instead it’s a log4j vuln, which cf does include. As for whether and how vulnerable cf is simply because of that, that is still to be determined, but most are taking a stance of concern that it might be.

Second, it’s not that there’s been NO discussion by anyone about this in an Adobe community resource. It’s just been happening primarily in the cf community FORUM rather than here on the cf PORTAL.

Follow the far more elaborated discussion there, which includes replies from Adobe and many others, since the day news of the vuln broke:

https://community.adobe.com/t5/coldfusion-discussions/zero-day-exploit-affecting-the-popular-apache-log4j-utility-cve-2021-44228/m-p/12588615

As for the jvm arg approach you’ve used, see the info shared there and in resources pointed to (including Pete’s info you refer to) for how there are caveats about whether that’s the “right” solution based on the log4j version, and so the cf version (depending on what cf version included what log4j version) as well as perhaps your Java version.

When Adobe has a more formal and complete response, we can expect it would be posted here on the portal.

Finally, if I can opine, I said most are taking a stance that CF might be vulnerable. I think rather it’s that most seem to be freaking out, like much of the it world, and are presuming cf MUST be vulnerable, and inherently so, such that we all need to fear takeover of our servers at any moment.

To have a more accurate perspective, each should read the info in that thread and the specific resources it points to (some of which I shared) and in the broader IT press.

I understand that some don’t want to take the time to understand things, they just want to tick a box to report to stakeholders that they’re “not vulnerable”.  The formal Adobe response will be where we get that most confidently. Until then, the point is that the situation is fluid and there is not yet any “one size fits all” response. 

And time will tell if *ALL* CFers have reason to worry that their instance or instances are inherently vulnerable. Instead, this may be more like sql injection, where one would have had to code something a certain way to become vulnerable.

I’m not saying we need not worry (for now). I’m saying the smoke still has not cleared and things are not as obvious as some would be inclined to assert. As is the case with such issues, there’s a lot more to the topic than what’s shared in a tweet-level response.

Bottom line: if/when Adobe comes out with an update to address the vuln (and completely remove the chance of any exploit based on this issue), that should solve it for those on the supported versions (currently cf2021 and CF2018). Then they or others may offer still more info (though not likely any fix) to help those on older cf versions. Wait for that, or dig into that forum thread for more. 

Like
(2)
>
Charlie Arehart
's comment
2021-12-13 20:46:58
2021-12-13 20:46:58
>
Charlie Arehart
's comment

Hi Charlie, according the Pete’s article

https://www.petefreitag.com/item/923.cfm. It says either or fix,

Add JVM arg: -Dlog4j2.formatMsgNoLookups=true (only works on log4j 2.10.0 and up

or

According to Microsoft’s Response to this issue, you can set an environment variable instead of the JVM argument: LOG4J_FORMAT_MSG_NO_LOOKUPS=true

Could you please shed some light on it. Also, is there way to test whether these changes are really working?

Like
>
ashwinia70450482
's comment
2021-12-13 21:16:02
2021-12-13 21:16:02
>
ashwinia70450482
's comment

There is currently no more light I’m aware of than I already shared above.

And no, I’ve not yet found any way that tests the vuln, causing it or confirming it can be caused, though I’ve tried . I shared that in the discussion forum

For now, again the choices are await Adobe (the shot) or try the jvm arg (the mask). And hope for the best.

Like
Add Comment