Skip to main content
Jdsplicer
Jdsplicer
Inspiring
December 10, 2021
Answered

zero-day exploit affecting the popular Apache Log4j utility (CVE-2021-44228)

  • December 10, 2021
  • 30 replies
  • 65943 views

Does anyone know if the zero-day exploit affecting the popular Apache Log4j utility (CVE-2021-44228) that was announced on 12/9/2021 will affect ColdFusion version 10 and 2018?

      This topic has been closed for replies.
      Correct answer Priyank Shrivastava.

      Hi Everyone,


      We had originally published (on Dec 14) some workaround/mitigation steps in this article until the patch would be released. Since then, there have been updates and still further updates.

       

      Dec 14: Technote with initial mitigations offered:

      https://helpx.adobe.com/coldfusion/kb/log4j-vulnerability-coldfusion.html

       

      Update Dec 17: Updates for CF2021 and 2018 were released, addressing this log4j vulnerability. The technote mentioned above was a preliminary response, offered on Dec 14.

       

      Update Dec 21: To address the vulnerabilities later found in log4j 2.16, those who have applied the most recent update can now implement the log4j 2.17 updates, as provided along with instructions here:

      https://helpx.adobe.com/coldfusion/kb/log4j-2-16-vulnerability-coldfusion.html 

       

      Update Jan 11 2022: To address the vulnerabilities later found in log4j 2.17, those who have applied the most recent update can now implement the log4j 2.17.1 updates, as provided along with instructions here:

      https://helpx.adobe.com/coldfusion/kb/log4j-2-17-0-vulnerability-coldfusion.html 

       

      30 replies

      Show previous replies
      K
      KennethMHutch
      Participating Frequently
      December 15, 2021

      Did anyone run into an issue with the CF Admin page after applying the fix?

       

      I applied the fix and everything appears to be running ok, but when I try to launch the CF admin page I get this message. 

       

      The web site you are accessing has experienced an unexpected error.
      Please contact the website administrator.

      The following information is meant for the website developer for debugging purposes.
      Error Occurred While Processing Request

      The Monitoring service is not available.

      This exception is usually caused by service startup failure. Check your server configuration.
       
      The error occurred in Application.cfm: line 114
      Called from Application.cfm: line 4
      Called from Application.cfm: line 1
      -1 : Unable to display error's location in a CFML template.
      Resources:

       

      Browser  Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0
      Remote Address  127.0.0.1
      Referrer   
      Date/Time  15-Dec-21 05:07 PM
      Stack Trace
      at cfApplication2ecfm1524830424._factor3(/CFIDE/administrator/Application.cfm:114) at cfApplication2ecfm1524830424._factor11(/CFIDE/administrator/Application.cfm:4) at cfApplication2ecfm1524830424.runPage(/CFIDE/administrator/Application.cfm:1)

      coldfusion.server.ServiceFactory$ServiceNotAvailableException: The Monitoring service is not available.

	at coldfusion.server.ServiceFactory.getMonitoringService(ServiceFactory.java:227)

	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

	at java.base/java.lang.reflect.Method.invoke(Method.java:566)

	at coldfusion.runtime.java.JavaProxy.invoke(JavaProxy.java:101)

	at coldfusion.runtime.CfJspPage._invoke(CfJspPage.java:3627)

	at coldfusion.runtime.CfJspPage._invoke(CfJspPage.java:3604)

	at cfApplication2ecfm1524830424._factor3(/CFIDE/administrator/Application.cfm:114)

	at cfApplication2ecfm1524830424._factor11(/CFIDE/administrator/Application.cfm:4)

	at cfApplication2ecfm1524830424.runPage(/CFIDE/administrator/Application.cfm:1)

	at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:262)

	at coldfusion.tagext.lang.IncludeTag.handlePageInvoke(IncludeTag.java:735)

	at coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:565)

	at coldfusion.filter.CfincludeFilter.invoke(CfincludeFilter.java:65)

	at coldfusion.filter.CfincludeFilter.include(CfincludeFilter.java:33)

	at coldfusion.filter.ApplicationFilter.invoke(ApplicationFilter.java:471)

	at coldfusion.filter.RequestMonitorFilter.invoke(RequestMonitorFilter.java:43)

	at coldfusion.filter.MonitoringFilter.invoke(MonitoringFilter.java:40)

	at coldfusion.filter.PathFilter.invoke(PathFilter.java:162)

	at coldfusion.filter.IpFilter.invoke(IpFilter.java:45)

	at coldfusion.filter.ExceptionFilter.invoke(ExceptionFilter.java:96)

	at coldfusion.filter.BrowserDebugFilter.invoke(BrowserDebugFilter.java:78)

	at coldfusion.filter.ClientScopePersistenceFilter.invoke(ClientScopePersistenceFilter.java:28)

	at coldfusion.filter.BrowserFilter.invoke(BrowserFilter.java:38)

	at coldfusion.filter.NoCacheFilter.invoke(NoCacheFilter.java:60)

	at coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:38)

	at coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22)

	at coldfusion.filter.CachingFilter.invoke(CachingFilter.java:62)

	at coldfusion.CfmServlet.service(CfmServlet.java:226)

	at coldfusion.bootstrap.BootstrapServlet.service(BootstrapServlet.java:311)

	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:228)

	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:163)

	at coldfusion.monitor.event.MonitoringServletFilter.doFilter(MonitoringServletFilter.java:46)

	at coldfusion.bootstrap.BootstrapFilter.doFilter(BootstrapFilter.java:47)

	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:190)

	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:163)

	at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)

	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:190)

	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:163)

	at coldfusion.filter.ClickjackingProtectionFilter.doFilter(ClickjackingProtectionFilter.java:75)

	at coldfusion.bootstrap.BootstrapFilter.doFilter(BootstrapFilter.java:47)

	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:190)

	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:163)

	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202)

	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97)

	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:542)

	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143)

	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)

	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78)

	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:373)

	at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:382)

	at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)

	at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:893)

	at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1723)

	at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)

	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)

	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)

	at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

	at java.base/java.lang.Thread.run(Thread.java:834)

       

       

      Ripley Casdorph
      Ripley Casdorph
      Participating Frequently
      December 16, 2021

      When I added the wrong jar I was getting a 500 error, but it was for the admin and the site.  Did you have the correct jars? Many are named very similarly.

      A
      AjasHadi
      Participating Frequently
      December 15, 2021

      For Folks reading this as of  Wednesday 12 pm ET Dec 15 2021, As per the Adobe link https://helpx.adobe.com/coldfusion/kb/log4j-vulnerability-coldfusion.html

       

      Can you please be specific with instructions because it has definitely caused some confusion on the steps to perform. I will give example

       

      1.  The link https://cfdownload.adobe.com/pub/adobe/coldfusion/logshell/2.9.0/log4j-core-2.9.0.jar earlier was downloading a file named log4j-core-2.9.0-logshell.jar (as of yesterday Dec 14 2021 ). I renamed it myself by removing -logshell from the file log4j-core-2.9.0.jar .Looks like Adobe has fixed that since then. I downloaded file today Dec 15 2021 and its named correctly log4j-core-2.9.0.jar . Can someone from Adobe post notes at top of the page https://helpx.adobe.com/coldfusion/kb/log4j-vulnerability-coldfusion.html with last updated date time and also what typos/wrong file name have been fixed so people coming to your link know they are looking at latest information.
      2.  Instruction for ColdFusion 2018. ColdFusion 2018 ships with log4j 2.13.3 and/or 2.9.0, and log4j 1.2. The former is impacted by this vulnerability, while the latter (that is, v1.2) is not impacted. So you are saying both log4j 2.13.3 and/or 2.9.0 are impacted but the file provided to download is log4j-core-2.9.0.jar. Question : Should we remove/update both of these  log4j 2.13.3 and/or 2.9.0 from ColdFusion 2018 or just log4j-core-2.9.0.jar? I found log4j-core-2.9.0.jar in ColdFusion2018\CF_Instance\hf-updates\hf-2018-00011-326016\backup\lib and thats the only one we replaced even though its part of hf-updates backup folder. So what is the deal with log4j 2.13.3 ? Are we supposed to leave it like that? Please clarify ASAP.

       

       

        J
        jdbrady67
        New Participant
        December 15, 2021

        The 2.16 version will work also

        A
        aarnir71156744
        Participating Frequently
        December 15, 2021

        Hi All,

         

        Thanks for sharing all the info here.

         

        On CF2021 I did the manual change to 2.15 and jvm.config java-args add yesterday. All ok it seems. Anyone done the manual change to 2.16?

         

        Or should one wait till Friday...?

        Ripley Casdorph
        Ripley Casdorph
        Participating Frequently
        December 15, 2021

        I did the change to 2.16.0 last night without an issue.  Don't know if it is more secure, but it is updated!

        A
        aarnir71156744
        Participating Frequently
        December 15, 2021

        Boldly changed to 2.16 here too just a minute ago. Server (CF2021 Standard) restarted and running ok.

          Priyank Shrivastava.
          Community Manager
          Priyank Shrivastava.Community ManagerCorrect answer
          Community Manager
          December 14, 2021

          Hi Everyone,


          We had originally published (on Dec 14) some workaround/mitigation steps in this article until the patch would be released. Since then, there have been updates and still further updates.

           

          Dec 14: Technote with initial mitigations offered:

          https://helpx.adobe.com/coldfusion/kb/log4j-vulnerability-coldfusion.html

           

          Update Dec 17: Updates for CF2021 and 2018 were released, addressing this log4j vulnerability. The technote mentioned above was a preliminary response, offered on Dec 14.

           

          Update Dec 21: To address the vulnerabilities later found in log4j 2.16, those who have applied the most recent update can now implement the log4j 2.17 updates, as provided along with instructions here:

          https://helpx.adobe.com/coldfusion/kb/log4j-2-16-vulnerability-coldfusion.html 

           

          Update Jan 11 2022: To address the vulnerabilities later found in log4j 2.17, those who have applied the most recent update can now implement the log4j 2.17.1 updates, as provided along with instructions here:

          https://helpx.adobe.com/coldfusion/kb/log4j-2-17-0-vulnerability-coldfusion.html 

           

          Thanks,Priyank Shrivastava
            S
            Segfault
            Participating Frequently
            December 14, 2021

            I have to say i'm not impressed by Adobe taking four days to recommend a workaround the majority of aware CF admins have already applied since before the weekend.

            Has customer data been at reasonable risk at all over last four days or is this still unclear?
            Because if you're applying this fix just now while CF is in vulnerable you need to be doing more then merely setting that java argument...

              altascene
              altascene
              Inspiring
              December 14, 2021

              Point of clarification.  In stepping through the mitigation process for CF2018, step 5 starts with "...If you find log4j-core-2.9.0.jar...".  If I do NOT find log4j-core-2.9.0.jar, do I need to perform any of the steps after 5?

                Priyank Shrivastava.
                Community Manager
                Priyank Shrivastava.Community Manager
                Community Manager
                December 14, 2021

                If you find log4j-core-2.9.0.jar, move the file to a temporary location. If not found, skip step   5..

                 

                We are making correction in that. 

                Thanks,Priyank Shrivastava
                altascene
                altascene
                Inspiring
                December 14, 2021

                Priyank,

                Thanks for the update.  I wanted to mention that, step 5 of the mitigation instructions references the "log4j-core-2.9.0.jar" file, the included link actually downloads a file named "log4j-core-2.9.0.logshell.jar".  Are those files the same?

                Also, in step 5, "Copy the patched log4j-core-2.9.0.jar file with JNDILookUp class that you have removed. The new file can be downloaded from here.", what is meant by "...with JNDILookUp class that you have removed..."?

                Thanks,

                Scott

                 

                  G
                  gualtiero sappa
                  New Participant
                  December 14, 2021

                  Hi all,

                  we contacted Adobe Product Security and Incident Response and received this reply:

                   

                  Adobe is investigating potential impact and taking action, including updating affected systems to the latest versions of Apache log4j 2 recommended by the Apache Software Foundation.

                   

                  The investigation is ongoing but, to date, Adobe has discovered no indication to suggest customer data has been impacted as a result of this issue.

                  ColdFusion plans to release a patch (version(s) 2021 & 2018) for this log4j vulnerability to customers on 12/17/2021. 

                  In the meantime, we recommend ColdFusion customers apply the following workarounds/mitigations steps until this patch has been released:

                   

                  Workaround/Mitigation steps:

                  CF2021:

                  CF 2021 ships with log4j 2.13.3 and 1.2 versions. The former is impacted by this vulnerability while the latter is not. 

                  Steps:

                  1. Stop the server
                  2. Navigate to <cf_root>\<Instance_name>\bin directory
                  3. Open jvm.config file and add -Dlog4j2.formatMsgNoLookups=true argument in java.args section and save
                  4. If using any third-party libraries that use log4j2, and hence vulnerable, search for log4j-core in <cf_root> directory. If log4j2 version (<= 2.10 and >=2.0-beta9)  is found, remove the JndiLookup class from the classpath like below otherwise skip this step.
                  • If the operating systems is Windows , then unzip the log4j-core-2.x.jar file and remove the class from path : org/apache/logging/log4j/core/lookup/JndiLookup.class and zip the log4j-core-2.x.jar. X is the version number you found in the folder.
                  • If the operating systems is non-windows, then remove the JndiLookup class from the classpath : "zip -q -d log4j-core-2.x.jar org/apache/logging/log4j/core/lookup/JndiLookup.class". X is the version number you found in the folder.

                  5. Start the Instance

                  6. Repeat this for all the instances.

                   

                  CF2018:

                  CF 2018 ships with log4j 2.13.3 and/or 2.9.0, and log4j 1.2. The former is impacted by this vulnerability while the latter (i.e., v1.2) is not impacted. 

                  Steps:

                  1. Stop the server
                  2. Navigate to <cf_root>\<Instance_name>\bin directory
                  3. Open jvm.config file and add -Dlog4j2.formatMsgNoLookups=true argument in java.args section and save.
                  4. Navigate to <cf_root >>\<Instance_name>\lib directory. 
                  5. If you find log4j-core-2.9.0.jar, move the file to a temporary location
                  6. Copy the patched log4j-core-2.9.0.jar file with JNDILookUp class removed from here
                  7. If using any third-party libraries that use log4j2, and hence vulnerable, search for log4j-core in <cf_root> directory. If log4j2 version (<= 2.10 and >=2.0-beta9) is found, remove the JndiLookup class from the classpath like below otherwise skip this step
                  • If the operating systems is Windows , then unzip the log4j-core-2.x.jar file and remove the class from path : org/apache/logging/log4j/core/lookup/JndiLookup.class and zip the log4j-core-2.x.jar. X is the version number you found in the folder.
                  • If the operating systems is non-windows, then remove the JndiLookup class from the classpath : "zip -q -d log4j-core-2.x.jar org/apache/logging/log4j/core/lookup/JndiLookup.class ". X is the version number you found in the folder.

                  8. Start the Instance

                  9. You can now delete log4j-core-2.9.0.jar from the temporary location

                  10. Repeat this for all the instances.

                   

                  PMT 2021:

                  PMT 2021 ships with log4j 2.11.1 and log4j 2.3. Both versions are impacted. 

                  Steps:

                  1. Stop the PMT and datastore services
                  2. Navigate to <PMT_Home>\datastore\config directory
                  3. Open jvm.options file, add -Dlog4j2.formatMsgNoLookups=true argument in #log4j2 section and save.
                  4. Navigate to <PMT_Home>\lib directory. 
                  5. Move the file log4j-core-2.3.jar to a temporary location
                  6. Copy the patched log4j-core-2.3.jar file with JNDILookUp class removed from here
                  7. Start the datastore and PMT services
                  8. You can now delete log4j-core-2.3.jar from the temporary location

                   

                  PMT 2018:

                  PMT 2018 ships with log4j 2.9.1 and log4j 2.3. Both versions are impacted. 

                  Steps:

                  1. Stop the PMT and datastore services
                  2. Navigate to <PMT_Home>\datastore\lib directory
                  3. Move the file log4j-core-2.9.1.jar to a temporary location
                  4. Copy the patched log4j-core-2.9.1.jar file with JNDILookUp class removed from here
                  5. Navigate to <PMT_Home>\lib directory 
                  6. Move the file log4j-core-2.3.jar to a temporary location
                  7. Copy the patched log4j-core-2.3.jar file with JNDILookUp class removed from here
                  8. Start the datastore and PMT services
                  9. You can now delete log4j-core-2.3.jar and log4j-core-2.9.1 from the temporary location

                   

                   APIM 2021 and APIM 2018:

                  APIM 2021 and 2018 ship with log4j 2.3. This version is impacted.

                  Steps:

                  1. Stop the APIM server (<APIM_Home>\bin) and Analytics (<APIM_Home>database\analytics\bin) service.
                  2. Navigate to <APIM_Home>\lib directory. 
                  3. Move the file log4j-core-2.3.jar to a temporary location
                  4. Copy the patched log4j-core-2.3.jar file with JNDILookUp class removed from here
                  5. Start the Analytics service and the APIM server.
                  6. You can now delete log4j-core-2.3.jar from the temporary location

                  Note – For more information, we recommend users to refer to the below post made by Pete Freitag on the log4j issue:

                  https://www.petefreitag.com/item/923.cfm

                    N
                    neochad
                    Inspiring
                    December 14, 2021

                    So I am curious if this is functionally any different than doing the 2.15.0 replacement, is there anything about 2.15.0 that could cause issues? I have been running 2.15.0 now for about 12 hours and no issues have occured as far as I can tell.

                     

                     

                     

                     

                    T
                    T.Brown.10
                    Participating Frequently
                    December 14, 2021

                    My theory (and it's only a theory) that the 2.15.0 update accomplishs the same thing.  However if you are adobe it was quicker to push through a small patch to the exisiting libaray rather then to have to run regressions and unit tests on the new library version.   So there reamins a small risk doing the library update that you may find some issue that wasn't present in the older 

                      3
                      32132132164654654
                      New Participant
                      December 14, 2021

                      Has anybody been able to reproduce a POC of this issue on Coldfusion?

                      Ripley Casdorph
                      Ripley Casdorph
                      Participating Frequently
                      December 14, 2021

                      I have seen discussion from several people that they have been unable to prove CF can  actually be compromised with this hack, but that doesn't mean you shouldn't patch it anyway. 

                       

                      The steps for fix are easy, take about 5 minutes total, and a simple restart of  CF service allows for 40 seconds of down-time.

                       

                      No reason not to fix for the peace of mind. 

                      J
                      JuergenW
                      New Participant
                      December 14, 2021

                      Version 2.16 of log4j has been released:

                      https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-api/2.16.0/log4j-api-2.16.0.jar

                      https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.16.0/log4j-core-2.16.0.jar

                      https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-to-slf4j/2.16.0/log4j-to-slf4j-2.16.0.jar

                       

                      Changes: https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0

                       

                       

                       

                        jeffh65754959
                        jeffh65754959
                        Inspiring
                        December 14, 2021

                        Looking at the release notes, it turns off JNDI and requires log4j2.enableJndi to be set to true to allow it and turns off support for message lookups.

                        J
                        jhansen-cf
                        Inspiring
                        December 13, 2021

                        @Ripley Casdorph When it comes to "4. Update the log4j.properities files changing m% to %m{nolookups} in the same lib folder" please elaborate...

                        In my log4j.properities I see a number of ConversionPattern values like...

                        %d{MM/dd HH:mm:ss} [%t] %-5p %m%n
                        This should be updated to read...

                        %d{MM/dd HH:mm:ss} [%t] %-5p %m{nolookups}%n

                        Correct?

                        Ripley Casdorph
                        Ripley Casdorph
                        Participating Frequently
                        December 13, 2021

                        In our properties file I see 8 places to update %m.

                         

                        Most now look like this:

                         %m{nolookups}%n
                        or
                        %m{nolookups}%n%n
                        and I think the line you are referring to is 58 and it reads.
                        %d{MM/dd HH:mm:ss} [%t] %-5p %m{nolookups}%n
                         
                        Can I confirm that it is working? No.  I can confirm that it didn't break anything on our server and appears to be working and we are getting logs. When I had the wrong jar in there the server wouldn't run, so as long as the new jar works, I beleive we are golden!
                         
                          jeffh65754959
                          jeffh65754959
                          Inspiring
                          December 13, 2021

                          There is also a log4j-1.2.15.jar in the instance/lib directory that was not deleted once the log4j files went to 2.x in later releases.  I have contacted Adobe asking if upgrading to 2.15.0 we are safe and are not voiding our warranty on the software.  I was told that Adobe security is still analysing the impact and they will make official announcement.

                            M
                            michaelm87459285
                            Participating Frequently
                            December 13, 2021

                            per apache these versions are not vulnerable: Versions Affected: all log4j-core versions between 2.0-beta9 and 2.14.1

                            F
                            FishDev
                            Participating Frequently
                            December 13, 2021

                            While that is technically true it may not be the case, and remains unclear as I have not seen any official word on if it is impacted or not:

                            See this: Log4j – Apache Log4j Security Vulnerabilities

                            In particular:

                            Please note that Log4j 1.x has reached end of life and is no longer supported. Vulnerabilities reported after August 2015 against Log4j 1.x were not checked and will not be fixed.

                              Show more replies
                              Terms & ConditionsAccessibility statement
                              Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices