An SQL injection vulnerability has been identified in the "ID" attribute of the SAML response when the replay cache of the Shibboleth Service Provider (SP) is configured to use an SQL database as storage service. An unauthenticated attacker can exploit this issue via blind SQL injection, allowing for the extraction of arbitrary data from the database, if the database connection is configured to use the ODBC plugin. The vulnerability arises from insufficient escaping of single quotes in the class SQLString (file odbc-store.cpp, lines 253-271).

This issue affects Shibboleth Service Provider through 3.5.0.

Shibboleth XMLTooling before 3.2.4, as used in OpenSAML and Shibboleth Service Provider, allows SSRF via a crafted KeyInfo element. (This is fixed in, for example, Shibboleth Service Provider 3.4.1.3 on Windows.)

DISPUTED Insecure folder permissions in the Windows installation path of Shibboleth Service Provider (SP) before 3.4.1 allow an unprivileged local attacker to escalate privileges to SYSTEM via DLL planting in the service executable's folder. This occurs because the installation goes under C:\opt (rather than C:\Program Files) by default. NOTE: the vendor disputes the significance of this report, stating that "We consider the ACLs a best effort thing" and "it was a documentation mistake."

The OIDC OP plugin before 3.0.4 for Shibboleth Identity Provider allows server-side request forgery (SSRF) due to insufficient restriction of the requesturi parameter. This allows attackers to interact with arbitrary third-party HTTP services.

Shibboleth Service Provider 3.x before 3.2.2 is prone to a NULL pointer dereference flaw involving the session recovery feature. The flaw is exploitable (for a daemon crash) on systems not using this feature if a crafted cookie is supplied.

Shibboleth Service Provider before 3.2.1 allows content injection because template generation uses attacker-controlled parameters.

Shibboleth Identify Provider 3.x before 3.4.6 has a denial of service flaw. A remote unauthenticated attacker can cause a login flow to trigger Java heap exhaustion due to the creation of objects in the Java Servlet container session.

Shibboleth Service Provider (SP) 3.x before 3.1.0 shipped a spec file that calls chown on files in a directory controlled by the service user (the shibd account) after installation. This allows the user to escalate to root by pointing symlinks to files such as /etc/shadow.

The keygen.sh script in Shibboleth SP 2.0 (located in /usr/local/etc/shibboleth by default) uses OpenSSL to create a DES private key which is placed in sp-key.pm. It relies on the root umask (default 22) instead of chmoding the resulting file itself, so the generated private key is world readable by default.

Shibboleth XMLTooling-C before 1.6.4, as used in Shibboleth Service Provider before 2.6.1.4 on Windows and other products, mishandles digital signatures of user data, which allows remote attackers to obtain sensitive information or conduct impersonation attacks via crafted XML data. NOTE: this issue exists because of an incomplete fix for CVE-2018-0486.

Shibboleth XMLTooling-C before 1.6.3, as used in Shibboleth Service Provider before 2.6.0 on Windows and other products, mishandles digital signatures of user attribute data, which allows remote attackers to obtain sensitive information or conduct impersonation attacks via a crafted DTD.

The DynamicMetadataProvider class in saml/saml2/metadata/impl/DynamicMetadataProvider.cpp in OpenSAML-C in OpenSAML before 2.6.1 fails to properly configure itself with the MetadataFilter plugins and does not perform critical security checks such as signature verification, enforcement of validity periods, and other checks specific to deployments, aka CPPOST-105.

shibsp/metadata/DynamicMetadataProvider.cpp in the Dynamic MetadataProvider plugin in Shibboleth Service Provider before 2.6.1 fails to properly configure itself with the MetadataFilter plugins and does not perform critical security checks such as signature verification, enforcement of validity periods, and other checks specific to deployments, aka SSPCPP-763.

Shibboleth Service Provider (SP) before 2.5.4 allows remote authenticated users to cause a denial of service (crash) via a crafted SAML message.

A critical flaw has been discovered in the PKIX trust components that allows an X509 credential to be trusted in the special case where no trusted names are available for the given entityID. See External References for the complete details.

External References:

http://shibboleth.net/community/advisories/secadv20150225.txt

It was discovered that HttpResource and FileBackedHttpResource implementations in OpenSAML Java and Shibboleth IdP did not enable hostname verification when using TLS connections. Additionaly, OpenSAML Java makes use of Jakarta Commons HttpClient version 3.x, which does not perform verification of the server hostname against the server's X.508 certificate (CVE-2012-5783). This flaw can be exploited by a Man-in-the-middle (MITM) attack, where the attacker can spoof a valid certificate using a specially crafted subject.

IssueDescription:

It was found that the ParserPool and Decrypter classes in the OpenSAML Java implementation resolved external entities, permitting XML External Entity (XXE) attacks. A remote attacker could use this flaw to read files accessible to the user running the application server, and potentially perform other more advanced XXE attacks.

Shibboleth OpenSAML library 2.4.x before 2.4.3 and 2.5.x before 2.5.1, and IdP before 2.3.2, allows remote attackers to forge messages and bypass authentication via an "XML Signature wrapping attack."

Off-by-one error in the XML signature feature in Apache XML Security for C++ 1.6.0, as used in Shibboleth before 2.4.3 and possibly other products, allows remote attackers to cause a denial of service (crash) via a signature using a large RSA key, which triggers a buffer overflow.