POST
|
While Commons-text is utilized across a number of ArcGIS products, we have validated that the base ArcGIS Enterprise deployment (Portal for ArcGIS, ArcGIS Server, ArcGIS Datastore) and ArcGIS Pro are not vulnerable. A security scanner run against these products may incorrectly flag the vulnerability as present. This is because some security scanners detect a vulnerable version of Commons-text, however we have confirmed that the library, when present in these products, is not used a way that would make it vulnerable to this CVE. According to CISA's Known Exploitable Vulnerability Catalog, this issue is not known to have been exploited in the wild in any product. https://www.cisa.gov/known-exploited-vulnerabilities-catalog see: https://www.esri.com/arcgis-blog/products/trust-arcgis/administration/commons-text-vulnerability/
... View more
12-07-2022
07:12 AM
|
0
|
0
|
795
|
POST
|
I think it's important for users and security teams to have context into how commons-text version 1.10 was updated in order to address CVE-2022-42889. I'll pull heavily from Apache's blog describing this issue. https://blogs.apache.org/security/entry/cve-2022-42889 Key take aways (emphasis mine): If you rely on software that uses a version of commons-text prior to 1.10.0, you are likely still not vulnerable: you are only affected when this software uses the StringSubstitutor API without properly sanitizing any untrusted input. If your own software uses commons-text, double-check whether it uses the StringSubstitutor API without properly sanitizing any untrusted input. If so, an update to 1.10.0 could be a quick workaround, but the recommended solution is to also properly validate and sanitize any untrusted input. More: "Apache Commons Text is a low-level library for performing various text operations, such as escaping, calculating string differences, and substituting placeholders in the text with values looked up through interpolators. When using the string substitution feature, some of the available interpolators can trigger network access or code execution. This is intended, but it also means an application that includes user input in the string passed to the substitution without properly sanitizing it would allow an attacker to trigger those interpolators." "For that reason the Apache Commons Text team have decided to update the configuration to be more "secure by default", so that the impact of a failure to validate inputs is mitigated and will not give an attacker access to these interpolators. However, it is still recommended that users treat untrusted input with care." "We're not currently aware of any applications that pass untrusted input to the substitutor and thus would have been impacted by this problem prior to Apache Commons Text 1.10.0." What does this mean? It means that in commons-text 1.10 (the "patched version" of this component, the vulnerable feature is disabled by default. But...what happens if a vendor actually USES that feature (hint: everyone using commons-text uses this feature)? The vendor still MUST sanitize the input in the first place - and that's always been heavily emphasized in the Apache commons documentation - nothing changes there. We are in the process of finalizing our evaluation of Esri software and will post the results of this analysis. Like all of our security advisories and notifications, you'll find it soon on the front page of the ArcGIS Trust Center.
... View more
10-26-2022
08:47 AM
|
2
|
1
|
3958
|
POST
|
There's a lot of undue media hype regarding this issue floating around. This is NOT a Log4j type event. Some less sensational writeups of this issue are available that provide good context that describe the low likelihood of this issue being exploitable in software, eg: https://portswigger.net/daily-swig/apache-commons-text-rce-resemblance-to-log4shell-but-exposure-risk-is-much-lower https://www.rapid7.com/blog/post/2022/10/17/cve-2022-42889-keep-calm-and-stop-saying-4shell/ To that end, Esri is aware of and is in the process of performing the due diligence to evaluate any impact of the recently announced Apache Commons-Text vulnerability traded as CVE-2022-42889 in the context of our products. Esri is unaware of any instance of ArcGIS Software being exploited by CVE-2022-42889 at this time, and as of this writing there have been no reports of CVE-2022-42889 exploited in the wild reflected in the CISA Known Exploited Vulnerabilities Catalog. We will provide additional details regarding our findings to our customers as we complete our validation.
... View more
10-21-2022
05:48 AM
|
7
|
5
|
4512
|
BLOG
|
@TammySikma1 That's a potential option if you have your own auth provider (EG: a SAML system that supports email based MFA). ArcGIS Online currently requires a software based MFA token for built-in users. There's an enhancement request to allow admins to enforce MFA in AGO. [#ENH-000113296 Admins of ArcGIS Online Organizations should have the ability to require that members of their organization use Multi-Factor Authentication]
... View more
02-22-2022
08:54 AM
|
3
|
0
|
2084
|
POST
|
The layer needs to support metadata to edit the itemInfo resource for a sublayer. New in 10.6.1 New property named archivingInfo is added. supportsCountDistinct property added inside the advancedQueryCapabilities element. New property named hasMetadata is added. This value is true when the service is published using ArcGIS Pro 2.2 or later, false otherwise. If hasMetadata is true, the layer / table supports iteminfo, thumbnail, and metadata resources.
... View more
02-22-2022
07:53 AM
|
0
|
0
|
751
|
BLOG
|
@CourtneyDunn That's a good question. In all MFA solutions I've seen, MFA is handled at the authorization provider level, meaning that if you use SAML to log into ArcGIS Online, your credentials and MFA tokens are validated by SAML. If FME prompts you to log into ArcGIS Online, ArcGIS Online (as the authorization provider) will handle the MFA token. FME shouldn't really care at that level. I don't think you pass credentials to FME, I think you pass credentials to ArcGIS Online or your organization-specific login provider.
... View more
02-22-2022
07:35 AM
|
0
|
0
|
2093
|
POST
|
@DeanMoiler Our patches will handle this, but I've been telling people to not delete the backup files that the Logpresso tool created in case they need to be restored. Logpresso provides a command for restoring.
... View more
02-04-2022
06:13 AM
|
1
|
0
|
1324
|
POST
|
All, note that customers with IA teams concerned about Log4J issues in 2.x or 1.2.x) that we do not explicitly target in our mitigation scripts can consider using a tool like Logpresso's log4j-scan tool. This tool is endorsed by CIS, is frequently updated, and well documented. While it does not update Log4J, it does remove vulnerable classes - and the vulns it doesn't address are documented.
... View more
02-02-2022
10:12 AM
|
1
|
0
|
1349
|
POST
|
You wouldn't - we don't use this pattern for contextLookup and that's why this CVE isn't exploitable in our software.
... View more
01-13-2022
11:34 AM
|
0
|
0
|
1569
|
POST
|
HI All, Sorry for the lack or recent participation. As you can imagine, we've been heads down with Log4J and other tactical and strategic issues software security issues here at Esri. To answer some questions in no particular order: @ErikLash1 @DavidColey Esri has not yet heard from a customer who has been exploited via log4j of any version in any of our software. We (Software Security and Privacy) AND the core ArcGIS Enterprise development team used white box testing techniques (walking the source code) while testing these 5 recently logged CVEs and we have not been able to exploit these either. We do not believe that ANY of these log4j issues are exploitable in our software (mitigation by design), but we are nonetheless producing formal patches for all versions in current support status since December 09 2021. In terms of what an exploit would look like: An exploit would most likely look like one of the bundled JREs that ship with ArcGIS Enterprise invoking some windows executable - like Javaw.exe --cmd /c c:\path\to\some\exe --some --argument. Note that ArcGIS Enterprise (as designed) itself will call some exes by default - like we call (for example) pg_isready to check the health of the internal database. If you see a JAVAW instance calling wget or ftp or similar and pulling down a file...that would concern me.
... View more
01-13-2022
11:33 AM
|
4
|
1
|
1500
|
POST
|
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
12-22-2021
09:35 AM
|
1
|
2
|
679
|
POST
|
The scripts don't delete log4j*.jar - they delete the jndilookup.class from inside the .jar.
... View more
12-21-2021
12:36 PM
|
0
|
0
|
1970
|
POST
|
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
12-21-2021
09:51 AM
|
2
|
1
|
1964
|
POST
|
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
12-20-2021
06:55 PM
|
3
|
2
|
2062
|
Title | Kudos | Posted |
---|---|---|
1 | 05-14-2024 11:27 AM | |
2 | 02-29-2024 06:01 PM | |
6 | 02-29-2024 04:23 PM | |
1 | 01-26-2024 11:59 AM | |
3 | 12-15-2023 10:41 AM |
Online Status |
Offline
|
Date Last Visited |
06-05-2024
02:23 PM
|