Latest Contributions by RandallWilliams

@RexRobichaux we plan to update again later today.  ... View more

We are nearing our investigation regarding this issue and plan to update our Log4J statement later today to include information regarding CVE-2021-45105. ... View more

The scripts don't delete log4j*.jar - they delete the jndilookup.class from inside the .jar.  ... View more

The reason you’re potentially seeing that file is that GeoEvent Server effectively has two copies of the contents of the Jar files when running. One copy, which the script is specifically targeting for GeoEvent Server in the System folder path, and a second unpacked version within the data folder. As a part of the script guidelines for GeoEvent Server we instruct users to delete the contents of the Data folder (including subfolder) which the Windows & Linux services/daemons are stopped. Once the script finished running and the services restarted, GeoEvent Server will unpack PAX jar (and all others we’re using) and store them in the cache bundles. Within a given release those will consistently be in the same location (e.g. bundle8) but with each release those could get unpacked into different locations. Again for that reason we instruct users to delete all of the contents in the data folder as opposed to searching in specific bundles. It will add a minute or so to the initial start-up time, but is the best way to ensure nothing remains of the vanilla/unmodified files. ... View more

We’re in the process of finalizing our review if this new CVE. We also provided a significant update to our advisory on the Trust center today. ... View more

@Anonymous User It changed December 15. Subscribe to the RSS feed on the ArcGIS Trust Center.   ... View more

@RobertDarlow I can provide clarity.  On Friday, Dec 10 (when this issue broke) the guidance provided by Apache indicated that apps that use Java 8.0.121+ were protected by built in protections in java that prevented the deserialization and execution of remote code. They also indicated that an environment variable would mitigate. Researchers quickly discredited those mitigation measures, so we removed them from our guidance. As you can tell, this is still an evolving situation - Apache released Log4J 2.17 Friday, December 17.    Run the scripts and check the advisory.  ... View more

We are aware of this new issue and are investigating. I'm not yet sure we set those non-default patterns and if we do, where.  ... View more

This isn't related to the Log4j scripts we've provided. I've seen something similar. Try restarting the datastore service. I believe there's a bug out there support logged.  ... View more

Look for an update in our advisory re: PRO today.  FWIW: Our response has initially focused first on what's most at risk and cascades from there. We are now moving to make statements regarding what's less at risk.  ... View more

@LaurensGIS Please open a case with Esri Support. We haven't yet seen an issue that is directly caused by this script - it only modifies Log4J files. We did test these script extensively before we released them.  ... View more

@SaraSiskavich There is a WAF guide on https://trust.arcgis.com. It's been updated in response to this issue. It's under the documents tab - in the customer-only docs tile. You need to sign in w/ your ArcGIS account to access. ... View more

See the advisory on https://trust.arcgis.com ... View more

https://www.esri.com/en-us/legal/requirements/open-source-acknowledgements ... View more

Apache corrected this issue in Log4J in v 2.15 by disabling  JNDILookup. In prior versions, it was enabled by default. There are no adverse effects we've seen by removing these classes. Removing these classes is a mitigation endorsed by Apache.   https://logging.apache.org/log4j/2.x/security.html#CVE-2021-44228 ... View more