Latest Contributions by RandallWilliams

A. Yes, do it.  B. Upgrade to 10.8.1 and install all the other security patches we've released this year.      ... View more

@MullaiManickavalli Yes, we're aware. There's a windows linebreaks issue in the file, It should be fixed very soon. Good catch and fix.  ... View more

The web adaptor is not exploitable. The Java web adaptor contains log4j-api-[version#].jar, which is not impacted by this issue. ... View more

Thanks @RexRobichaux and others! No-sleep Randall is still trying to keep up.  I'm sure inquiring minds and IT departments want to know and are asking: "WAIT WAIT WAIT - the version numbers on those files have NOT CHANGED! WHERE'S MY LOG4J 2.16 ERMAGERD!!"" Here's the deal: A. check out Apache's statement: https://logging.apache.org/log4j/2.x/security.html Log4j 2.x mitigation: Implement one of the mitigation techniques below. Java 8 (or later) users should upgrade to release 2.16.0. Users requiring Java 7 should upgrade to release 2.12.2 when it becomes available (work in progress, expected to be available soon). Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class For expediency, we have elected to take the third option. It eliminates the source of the vuln - which is the fact that JNDILookup was enabled by default. The fix Apache provided in Log4J 2.15 was to make this an OPTIONAL tool. We have eliminated this class altogether.  Like I mentioned in an earlier reply, we'd dearly love to just upgrade Log4j and make everyone's vuln scanners test clean. That's just not realistic this early in the game.  Think about this in term of other vendor patches - a Microsoft patch for any give issue might go through multiple iterations before an issue is fully fixed. It's easily possible that even if we could patches for all upstream vendors aligned, Apache will release Log4J 2.17 to fix a whole different but similar issue. None of us have time to chase that. So we've provided what we can provide NOW based on the Log4J docs to mitigate this issue and help make you safe while this continues to shake out. This won't be the last issue to shake the internet - that's the only thing I can promise without any doubt.      ... View more

Yes, but that doesn't change the fact that a WAF is a crucial part of any organization's defense in depth posture. No, a WAF won't eliminate ANY given risk, but security is about risk reduction with an eye toward risk elimination.  ... View more

We removed that statement as information has come out contraindicating that advice.  https://logging.apache.org/log4j/2.x/security.html ... View more

It's a dependencies upon dependencies issue. Esri doesn't "own" zookeeper or elasicsearch or spark. Those all come from 3rd parties, and those third parties have to themselves provide fixes for us to incorporate, then perform all the regression testing etc. Its overly simplistic (bordering on naïve) for an IT group to say "Just replace this file and poof, problem solved." If it was that easy, we'd have had a fix already. Software in general just doesn't work like that. Just replacing those files will simply not work.  We are working feverishly on this issue and have been since Friday. We are close - assuming Apache doesn't introduce more whammies. Like for instance, the advice your IT group provided is already out of date. Log4J 2.16 was released yesterday to address another issue, and the guidance provided by Apache changes daily. Our advisory will continue to be updated this evening.  https://logging.apache.org/log4j/2.x/security.html ... View more

All, We get that this is a frustrating time. Large scale vulnerabilities like this are difficult for customers and vendors alike. We know that customers can't usually upgrade at the drop of a hat. Considerable developments have occurred over the night yesterday and continue to happen today. We've received a lot of feedback (A LOT OF FEEDBACK) and are working to provide updates as soon as we can. ... View more

Restating under my Esri profile for clarity:   Please continue to follow the advisory we've published. There have been and will continue to be updates as the day progresses.   We have spent considerable time performing internal security testing, and there is no evidence of any proven exploit vectors for remote code execution (RCE) in any version of a base ArcGIS Enterprise deployment (including ArcGIS Server, Portal for ArcGIS, and ArcGIS Data Store). This means that while several components of ArcGIS Enterprise incorporate different versions of Log4J across all versions of ArcGIS Enterprise, there are no known ways to exploit this vulnerability. 10.8.x is mitigated: ArcGIS Enterprise versions 10.8 and higher use newer versions of the Java Runtime Environments (JRE) that do not allow for execution of remotely loaded code. On these versions of ArcGIS Enterprise, even hypothetical future remote exploit vectors are presumed to be mitigated. Please continue to refer to the advisory we've posted as the source of truth from Esri regarding this evolving issue.  ... View more

Lol, yes it's me. I have both corporate and my AGO profiles. I changed my AGO username years ago when doing some fuzz testing. Sorry for the confusion.  ... View more

You'll need to restart all ArcGIS Enterprise components for the processes to pick up the environment variable. ... View more

blocking stings like ${jndi will mitigate this issue.  ... View more

HI @NickHarvey , Looks like that doc needs some improvement, I can see the confusion.  You are correct - the OOTB MFA does not work with organization-specific logins like SAML, but the SAML providers OWN MFA absolutely will work. In fact, many of the ArcGIS Online ORGs we manage here internally at Esri leverage OKTA, in which our configuration requires MFA. Check out our Organization Specific logins FAQ in our ArcGIS Trust Center documents , we get deeeeep down in this technical paper. Let us know what you think!   ... View more