POST
|
The change that we put in was to set the content-disposition header on the uploaded PDF to "attachment" instead of "inline". https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition We did not go back and retroactively change PDFs uploaded before this update.
... View more
03-13-2024
09:01 AM
|
0
|
0
|
554
|
POST
|
That could work - I haven't tested that behavior. If your ArcGIS Enterprise is public facing and the PDF is public anyway, you can just share the URL "by reference" instead of via collaboration, too. I've noticed that Firefox gives me actions for how I want files to be used. For me at least, Firefox downloads the file locally then opens the downloaded file. (eg: file:///C:/Users/user/Downloads/doc.pdf). That's cool and a lot less dangerous. Chrome and Edge just download the file but don't open them. I haven't looked for an extension that will do it for those browsers. YMMV.
... View more
02-29-2024
06:01 PM
|
2
|
0
|
2309
|
POST
|
Hi All, This was an intentional change, and I'll tell you why. In almost all web applications, PDFs are uploaded to the app by a trusted source. ArcGIS Online is different in that we allow our many users to upload their own PDFs and share them broadly. When PDFs are generated and uploaded by a trusted source (eg: the site owner), we can be reasonably assured that the PDF has not been changed with a text editor to introduce malicious JavaScript. If an unsuspecting user opens a file containing malicious JS that is hosted on our ArcGIS.com domain while they are currently logged in, a browser's cross domain restrictions are effectively defeated. This leaves our users vulnerable to a, common, dangerous, easily exploited and typically severe type of attack called "stored cross-site scripting". Adobe also recognizes this risk, and offers options to prevent JS execution in Acrobat. Browser plugins also have the ability to block JavaScript - but how effective is relying on an end user to enable this functionality? We understand that this is an unpopular change. We strive to achieve a risk aware balance between "security" and "usability". This style of attack is well known and has been thoroughly documented. This is not a hypothetical - it is a real, persistent threat that we are responding to. We working to identify technologies that can identify and sanitize malicious scripts from PDFs and other files, but this is difficult challenge because PDF files are designed to use JavaScript code. We are also looking into PDF viewers that are either sandboxed or do not support JavaScript at all. We appreciate your feedback regarding this change - it does not go unheard. We look forward to providing a better, more secure option to providing an in-line experience for serving PDFs in a future release.
... View more
02-29-2024
04:23 PM
|
6
|
14
|
2352
|
POST
|
Hi Patrick, Regarding these: C:\Program Files\ArcGIS\DataStore\framework\runtime\couchdb\ssl\key.pem C:\Program Files\ArcGIS\DataStore\framework\template\nosql\ssl\key.pem C:\Program Files\ArcGIS\Portal\framework\runtime\ds\framework\template\nosql\ssl\key.pem These aren't SSH keys. These are 1/2 of the keypair used to support TLS in these components. The certificate keypair (cert + key) is self signed. These are key that are automatically generated upon installation. They are not trusted because they are self signed and not validated up to a certificate authority. For these: C:\Program Files\ArcGIS\DataStore\framework\runtime\ozone\compose\ozone-om-ha\.ssh\id_rsa C:\Program Files\ArcGIS\DataStore\framework\runtime\ozone\compose\ozonescripts\.ssh\id_rsa Those keys are used to start Ozone. It's used in the Object Store. If you don't have the object store configured, you can remove it via add/remove programs, but I'd disagree that these are a risk because they are only used in local communication. If an attacker has access to these keys, then they already have local admin on your ArcGIS Enterprise installation (a much bigger problem). https://ozone.apache.org/docs/1.2.1/start/onprem.html
... View more
02-22-2024
11:52 AM
|
0
|
0
|
358
|
POST
|
This work around is a hack and does nothing to change the back end API. It just obfuscates the troubleshoot.html page. Please log an enhancement with support to block this capability if you're using IWA OR if you're only allowing organization-specific logins.
... View more
01-26-2024
11:59 AM
|
1
|
0
|
275
|
POST
|
NO. DO NOT ATTEMPT TO UPGRADE OR INSTALL ANY PATCHES UNTIL THE 10.9.1 Validation and Repair tool IS AVAILABLE. Upgrading is an option to remediate the Sites vulnerabilities IF and ONLY IF this faulty patch has not yet been installed.
... View more
12-15-2023
10:41 AM
|
3
|
0
|
1048
|
POST
|
Regarding CVEs in general - when we release a security patch, we release an advisory that's discoverable on the ArcGIS Trust Center. An easy way to review all of the CVEs we've released: https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&search_type=all&isCpeNameSearch=false&cpe_vendor=cpe%3A%2F%3Aesri
... View more
12-14-2023
01:54 PM
|
0
|
0
|
498
|
POST
|
To be clear, there are a few issues in play: We released a series of patches for ArcGIS Enterprise Sites to address a few cross site scripting issues. While the patches fixed those issues, on Windows hosts, it introduced an issue that could result in system availability challenges if additional patches or upgrades were subsequently installed. This is what prompted us to pull that patch, and it took some time to develop a fix. This is an unprecedented issue for us, and required a major engineering effort to us to release the tool that fixes this problem. At the same time, we needed to produce a new patch for ArcGIS Enterprise Sites that wouldn't introduce this issue.
... View more
12-14-2023
01:23 PM
|
0
|
0
|
1089
|
POST
|
Hi James, Hi Ryan, The ArcGIS Enterprise 11.1 version of this patch AND the required ArcGIS Validation and Repair tool are available. We describe the defect the original Portal for ArcGIS Enterprise Sites Security Patch introduced and also provide the download location here: https://support.esri.com/en-us/patches-updates/2023/defective-arcgis-enterprise-patch We recently updated our Portal for ArcGIS Validation and Repair tool page here: https://support.esri.com/en-us/patches-updates/2023/portal-for-arcgis-validation-and-repair We also recently updated our security advisory , which found under the Advisories section of the ArcGIS Trust Center. The specific CVEs addressed in the are documented in the advisory. Linux users are unaffected by the issues introduced by the flawed patch. Users who have not yet installed the Portal for ArcGIS Enterprise Sites Security Patch can immediately remediate the security issues that this patch resolves with an upgrade to 11.2. All of the issues that the Portal for ArcGIS Enterprise Sites Security Patch addresses require the ability for a malicious user to manage an ArcGIS Enterprise Site. Mitigation options include temporarily revoking user memberships from the Sites Core Group.
... View more
12-14-2023
09:53 AM
|
4
|
5
|
1147
|
BLOG
|
The Case: Our team was recently asked to assist with troubleshooting an odd set of failures when adding data hosted on ArcGIS Online to ArcGIS Pro. When adding ArcGIS Online hosted feature services to the ArcGIS Pro project, the customer received error 499: Invalid token. They were already signed into ArcGIS Online, so it didn't seem like there was an issue with the token. Pro was functioning correctly on every other host in this organization. Odd that this issue would be localized to one machine. This mystery problem was blocking acceptance of a migration, as this particular host was leveraged with some additional integrations and customizations, and the host was purchased explicitly for its designated workflow. Symptoms: ArcGIS Pro was slow to load Adding hosted feature services to a new ArcGIS Pro project failed with error "Authentication Token required (status code 499) Running previously successful scripting/geoprocessing tasks failed with ERROR 160228, "The user does not have permission to execute the operation. The customer was logged into ArcGIS Online successfully, so unless something upstream was somehow mangling an authorization token, it seemed that there was something else in play. Given the error, we needed to check to see if ArcGIS Pro was having an issue accessing an OAuth resource or perhaps some generateToken call was failing. To do that, we broke out Fiddler4. While using Fiddler to monitor the web traffic between ArcGIS Pro and ArcGIS Online while adding content, we immediately noticed that none of the CRL/OSCP links were accessible - the error was HTTP 502 (bad gateway). So what's OCSP and what's a CRL anyway? OCSP is the Online Certificate Status Protocol. It's an alternative to CRL (Certificate Revocation Link). OCSP and CRL are two of the most common ways web browsers use to check if a site’s certificate has been revoked. A CRL is a list containing serial numbers of all certificates that have been revoked by a Certificate Authority. OCSP is a protocol used to discover the revocation status of a certificate and contains signatures that assert a certificate has not been revoked. This makes it a more effective and efficient validation process, as unlike CRL it does not require a list to be downloaded to discover the status of a certificate. Why did this matter? An HTTP 502 (bad gateway) blocking these URLs is suspect. OCSP and CRL links are expected to be accessible via plaintext HTTP. After all, if a certificate is compromised, how do you validate the status of the certificate using HTTPS? The Windows crypto API won't even try to connect to a CRL or OCSP link over HTTPS. So why were these resources blocked? The answer was simple - the customer had included this host in a firewall policy that blocked all outbound plaintext HTTP - including CRL and OCSP. Organizations sometimes misinterpret PCI/DSS compliance controls to mean communication using plaintext is prohibited, but that's not the case. 1.2.1 - Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment, and specifically deny all other traffic. 1.3.4 - Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet. As long as there is a legitimate reason for this traffic (which there is - OCSP and CRL are served over plaintext), and it is limited to the specific systems and external addresses that are required (CRL and OCSP should always be on allow lists - don't miss this during your firewall log reviews) then there is no issue with sending traffic to a plaintext resource. It seems like ArcGIS Pro didn't handle blocked connections to OCSP and CRL links well and threw a misleading error message when it could not get past the failed certificate revocation checks. Resolution: The customer's firewall team created and documented exceptions to allow outbound connections to: http://s.ss2.us/r.crl http://ocsp.rootg2.amazontrust.com/* http://crl.rootg2.amazontrust.com/rootg2.crl http://crl3.digicert.com/DigiCertGlobalRootG2.crl http://crl.rootca1.amazontrust.com/rootca1.crl http://ocsp.digicert.com/* For good measure, they also added http://ctldl.windowsupdate.com to the allow list, since that's the resource Windows uses to check for Windows updates, including to update it's own list of root CA certs. Meanwhile, we're working with support to improve our doc and error messaging/handling to make this a little more obvious, as we expect more and more users to run into this situation as they implement ZTA patterns. References: https://community.isc2.org/t5/Tech-Talk/PCI-and-revocation-checking-for-public-trusted-certificates/td-p/31830
... View more
12-11-2023
02:50 PM
|
4
|
0
|
440
|
BLOG
|
No worries, here's the link: https://trust.arcgis.com/en/customer-documents/ArcGIS_Enterprise_AV_Guidance.pdf
... View more
11-20-2023
08:35 AM
|
3
|
0
|
1309
|
BLOG
|
There is an updated version in the customer exclusive documents repository in the ArcGIS Trust Center. https://trust.arcgis.com/en/customer-documents/
... View more
11-20-2023
06:03 AM
|
3
|
0
|
1370
|
POST
|
Esri's current statement regarding LibWebP is: Esri utilizes the LibWebP library in a number of products, however they have not been demonstrated as exploitable at this time. Out of an abundance of caution, all products utilizing the LibWebP component will be updated as part of the next product release. Patches for older versions will be considered for products where there is additional risk identified.
... View more
10-17-2023
08:39 AM
|
4
|
0
|
804
|
POST
|
Esri is aware of CVE-2023-4863, which has recently seen broad media attention due to the impact to the commonly leveraged image library libwebp. We are also tracking CVE-2023-5217, which has not attracted as much media attention. The libwebp library is used to process images created in the webp image format. CVE-2023-4863 is known to have been exploited in the wild by an attacker tricking a victim into opening an HTML page that contains a specifically crafted webp image, triggering a buffer overflow. CVE-2023-5217 is a similar issue, found in libvpx. The libpvx library is used to process videos created with the VPX codec. CVE-2023-5217 is also known to have been exploited in the wild. We are investigating the impact of these vulnerabilities in these 3rd party components in our software. We encourage you to subscribe to the RSS feed on the ArcGIS Trust Center for the latest as it becomes available.
... View more
10-02-2023
01:43 PM
|
8
|
0
|
1481
|
Title | Kudos | Posted |
---|---|---|
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 | |
4 | 12-14-2023 09:53 AM |
Online Status |
Offline
|
Date Last Visited |
2 weeks ago
|