Skip to content

Commit 59ca899

Browse files
1 parent 035e8c2 commit 59ca899

File tree

4 files changed

+29
-16
lines changed

4 files changed

+29
-16
lines changed

advisories/github-reviewed/2021/05/GHSA-xg2h-wx96-xgxr/GHSA-xg2h-wx96-xgxr.json

Lines changed: 16 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,11 +1,13 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-xg2h-wx96-xgxr",
4-
"modified": "2024-05-20T21:15:51Z",
4+
"modified": "2026-01-23T22:52:01Z",
55
"published": "2021-05-21T16:26:06Z",
6-
"aliases": [],
6+
"aliases": [
7+
"CVE-2021-4238"
8+
],
79
"summary": "RandomAlphaNumeric and CryptoRandomAlphaNumeric are not as random as they should be",
8-
"details": "### Impact\n\nA security-sensitive bug was discovered by Open Source Developer *Erik Sundell of Sundell Open Source Consulting AB*.\n\nThe functions `RandomAlphaNumeric(int)` and `CryptoRandomAlphaNumeric(int)` are not as random as they should be. Small values of `int` in the functions above will return a smaller subset of results than they should. For example, `RandomAlphaNumeric(1)` will always return a digit in the 0-9 range, while `RandomAlphaNumeric(4)` will return around ~7 million of the ~13M possible permutations.\n\nThis is considered a security release because programs that rely upon random generators for passwords are at an increased risk of brute force-style password guessing. There is also a higher probability of collision.\n\nThe problem was the result of a mistaken regular expression that only accepted random strings if they contained a digit from `[0-9]`. That restriction has been removed.\n\n### Patches\n\nThis issue has been corrected in v1.1.1.\n\n### Workarounds\n\nIf you cannot upgrade to v1.1.1, you can work around the issue by calling `RandomAlphaNumericCustom(N, true, true)`|`CryptoRandomAlphaNumericCustom(N, true, true)` instead. (Where `N` is the desired length, and `true` is the literal boolean `true`.) ",
10+
"details": "### Impact\n\nA security-sensitive bug was discovered by Open Source Developer *Erik Sundell of Sundell Open Source Consulting AB*.\n\nThe functions `RandomAlphaNumeric(int)` and `CryptoRandomAlphaNumeric(int)` are not as random as they should be. Small values of `int` in the functions above will return a smaller subset of results than they should. For example, `RandomAlphaNumeric(1)` will always return a digit in the 0-9 range, while `RandomAlphaNumeric(4)` will return around ~7 million of the ~13M possible permutations.\n\nThis is considered a security release because programs that rely upon random generators for passwords are at an increased risk of brute force-style password guessing. There is also a higher probability of collision.\n\nThe problem was the result of a mistaken regular expression that only accepted random strings if they contained a digit from `[0-9]`. That restriction has been removed.\n\n### Patches\n\nThis issue has been corrected in v1.1.1.\n\n### Workarounds\n\nIf you cannot upgrade to v1.1.1, you can work around the issue by calling `RandomAlphaNumericCustom(N, true, true)`|`CryptoRandomAlphaNumericCustom(N, true, true)` instead. (Where `N` is the desired length, and `true` is the literal boolean `true`.)",
911
"severity": [],
1012
"affected": [
1113
{
@@ -33,6 +35,10 @@
3335
"type": "WEB",
3436
"url": "https://github.com/Masterminds/goutils/security/advisories/GHSA-xg2h-wx96-xgxr"
3537
},
38+
{
39+
"type": "ADVISORY",
40+
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4238"
41+
},
3642
{
3743
"type": "WEB",
3844
"url": "https://github.com/Masterminds/goutils/commit/869801f20f9f1e7ecdbdb6422049d8241270d5e1"
@@ -48,10 +54,16 @@
4854
{
4955
"type": "WEB",
5056
"url": "https://github.com/Masterminds/goutils/releases/tag/v1.1.1"
57+
},
58+
{
59+
"type": "WEB",
60+
"url": "https://pkg.go.dev/vuln/GO-2022-0411"
5161
}
5262
],
5363
"database_specific": {
54-
"cwe_ids": [],
64+
"cwe_ids": [
65+
"CWE-331"
66+
],
5567
"severity": "LOW",
5668
"github_reviewed": true,
5769
"github_reviewed_at": "2021-05-21T14:36:56Z",

advisories/github-reviewed/2021/08/GHSA-r88h-6987-g79f/GHSA-r88h-6987-g79f.json

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,11 +1,12 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-r88h-6987-g79f",
4-
"modified": "2023-06-13T21:54:46Z",
4+
"modified": "2026-01-23T22:52:22Z",
55
"published": "2021-08-25T21:00:28Z",
6+
"withdrawn": "2026-01-23T22:52:22Z",
67
"aliases": [],
7-
"summary": "Data races on syncpool",
8-
"details": "Affected versions of this crate unconditionally implements `Send` for `Bucket2`. This allows sending non-Send types to other threads.\n\nThis can lead to data races when non Send types like `Cell<T>` or `Rc<T>` are contained inside `Bucket2` and sent across thread boundaries. The data races can potentially lead to memory corruption (as demonstrated in the PoC from the original report issue).\n\nThe flaw was corrected in commit `15b2828` by adding a `T: Send` bound to the `Send` impl of `Bucket2<T>`.\n",
8+
"summary": "Duplicate Advisory: Data races on syncpool",
9+
"details": "## Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-vp6r-mrq9-8f4h. This link is maintained to preserve external references.\n\n## Original Description\nAffected versions of this crate unconditionally implements `Send` for `Bucket2`. This allows sending non-Send types to other threads.\n\nThis can lead to data races when non Send types like `Cell<T>` or `Rc<T>` are contained inside `Bucket2` and sent across thread boundaries. The data races can potentially lead to memory corruption (as demonstrated in the PoC from the original report issue).\n\nThe flaw was corrected in commit `15b2828` by adding a `T: Send` bound to the `Send` impl of `Bucket2<T>`.",
910
"severity": [
1011
{
1112
"type": "CVSS_V3",

advisories/github-reviewed/2022/12/GHSA-3839-6r69-m497/GHSA-3839-6r69-m497.json

Lines changed: 5 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,12 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-3839-6r69-m497",
4-
"modified": "2024-05-20T21:28:45Z",
4+
"modified": "2026-01-23T22:51:27Z",
55
"published": "2022-12-28T00:30:23Z",
6-
"aliases": [
7-
"CVE-2021-4238"
8-
],
9-
"summary": "GoUtils's randomly-generated alphanumeric strings contain significantly less entropy than expected",
10-
"details": "Randomly-generated alphanumeric strings contain significantly less entropy than expected. The `RandomAlphaNumeric` and `CryptoRandomAlphaNumeric` functions always return strings containing at least one digit from 0 to 9. This significantly reduces the amount of entropy in short strings generated by these functions.",
6+
"withdrawn": "2026-01-23T22:51:27Z",
7+
"aliases": [],
8+
"summary": "Duplicate Advisory: GoUtils's randomly-generated alphanumeric strings contain significantly less entropy than expected",
9+
"details": "## Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-xg2h-wx96-xgxr. This link is maintained to preserve external references.\n\n## Original Description\nRandomly-generated alphanumeric strings contain significantly less entropy than expected. The `RandomAlphaNumeric` and `CryptoRandomAlphaNumeric` functions always return strings containing at least one digit from 0 to 9. This significantly reduces the amount of entropy in short strings generated by these functions.",
1110
"severity": [
1211
{
1312
"type": "CVSS_V3",

advisories/github-reviewed/2024/05/GHSA-fjr2-r2mp-484p/GHSA-fjr2-r2mp-484p.json

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,11 +1,12 @@
11
{
22
"schema_version": "1.4.0",
33
"id": "GHSA-fjr2-r2mp-484p",
4-
"modified": "2024-05-28T19:29:38Z",
4+
"modified": "2026-01-23T22:52:48Z",
55
"published": "2024-05-28T19:29:37Z",
6+
"withdrawn": "2026-01-23T22:52:48Z",
67
"aliases": [],
7-
"summary": "SimpleSAMLphp signature validation bypass",
8-
"details": "### Background\nSAML messages are usually signed to prove the identity of the issuer of the message. In the case of SAML authentication responses, correctly verifying the signature is critical to trust that the assertion contained inside the response was issued by a trusted third-party and the identity of the subject has been properly verified.\n\nA SAML message can be signed both at the message level and at the assertion level (if the message is an authentication response). When the whole authentication response message is unsigned, all the assertions contained inside must be signed independently in order to verify their authenticity. Failure to properly verify the authenticity of the entire message or individual assertions leads to the ability of an attacker to impersonate any user from any Identity Provider trusted by the Service Provider.\n\n### Description\nA signature validation bypass issue has been found in the `SimpleSAML_XML_Validator` class. This class performs the verification of the XML digital signature of a SAML 1 message with a given key.\n\nWhen a SAML 1 authentication response message is received, it is processed to verify its authenticity, including a check for the signature or signatures included in the message. If the message is not signed but the assertions contained in it are, the signatures of those assertions signed will be verified. Unsigned assertions will not be verified. After verifying every signed element in the response, a list of valid nodes is built, holding the DOM nodes of those XML elements that are signed and whose signatures have been successfully verified.\n\nOnce this list is built, the assertions need to be processed individually. They are not processed until the getAttributes() method of the SimpleSAML_XML_Shib13_AuthnResponse class is called. This method iterates through the list of assertions contained in the response and makes sure they were validated in the previous signature verification step, by checking if their corresponding DOM nodes are in the list of those verified.\n\nThe vulnerability is due to lax comparison of the node being checked and the nodes in the verified list. The isNodeValidated() method of the SimpleSAML_XML_Validator class checks if a given DOM node is in the validNodes array by means of the standard in_array() function. This function, however, will return unexpected results due to the default lax behaviour when checking data types in PHP. In this case, the fact that there is a DOM node in the list is enough for in_array() to return true when looking for any DOM node. This means any unsigned assertion will be considered verified if there is at least one assertion with a valid signature in the message being processed.\n\nThis issue allows an attacker to generate a SAML 1 authentication response that contains two different assertions. The first assertion is the one the attacker wants the Service Provider to use, with custom attributes, expiration and even entityID (provided that the given entityID belongs to an Identity Provider that the Service Provider knows and trusts). The second is a legitimate assertion issued and signed by an Identity Provider trusted by the Service Provider. If the second assertion is still valid when sent by the attacker, SimpleSAMLphp will merge all the attributes found in both assertions, but the entityID registered for the authenticating third-party will be the one found in the first, tampered assertion. If the second (legitimate) assertion is already expired when the attacker sends it, only the attributes found in the tampered assertion will be used.\n\nThe issue can be easily fixed by passing a third parameter to the in_array() function, telling it to perform strict comparisons when checking if an object is found inside a given array. This way, when the code evaluates if the tampered assertion is included in the list of verified assertions, it fails and only the legitimate assertion is used, if possible (e.g. it is not expired).\n\n### Affected versions\nAll SimpleSAMLphp versions before and including 1.14.16.\n\n### Impact\nAn attacker can leverage this vulnerability to impersonate any user from any SAML 1 Identity Provider trusted by a SimpleSAMLphp Service Provider, with the only pre-requisite of a valid assertion previously sent to the affected Service Provider. As such, only those SimpleSAMLphp installations that have metadata deployed for SAML 1 Identity Providers (by default, listed in the metadata/shib13-idp-remote.php file, but could be in other locations depending on your local configuration) are affected.\n\n### Resolution\nUpgrade to the latest version. When an upgrade is not possible immediately, the following patch must be applied:\n```\ndiff --git a/lib/SimpleSAML/XML/Validator.php b/lib/SimpleSAML/XML/Validator.php\nindex e4877f0..69236ef 100644\n--- a/lib/SimpleSAML/XML/Validator.php\n+++ b/lib/SimpleSAML/XML/Validator.php\n@@ -260,7 +260,7 @@ class SimpleSAML_XML_Validator {\n assert('$node instanceof DOMNode');\n\n while($node !== NULL) {\n- if(in_array($node, $this->validNodes)) {\n+ if(in_array($node, $this->validNodes, true)) {\n return TRUE;\n }\n\n```",
8+
"summary": "Duplicate Advisory: SimpleSAMLphp signature validation bypass",
9+
"details": "## Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-j4qf-3w33-8cgc. This link is maintained to preserve external references.\n\n## Original Description\n### Background\nSAML messages are usually signed to prove the identity of the issuer of the message. In the case of SAML authentication responses, correctly verifying the signature is critical to trust that the assertion contained inside the response was issued by a trusted third-party and the identity of the subject has been properly verified.\n\nA SAML message can be signed both at the message level and at the assertion level (if the message is an authentication response). When the whole authentication response message is unsigned, all the assertions contained inside must be signed independently in order to verify their authenticity. Failure to properly verify the authenticity of the entire message or individual assertions leads to the ability of an attacker to impersonate any user from any Identity Provider trusted by the Service Provider.\n\n### Description\nA signature validation bypass issue has been found in the `SimpleSAML_XML_Validator` class. This class performs the verification of the XML digital signature of a SAML 1 message with a given key.\n\nWhen a SAML 1 authentication response message is received, it is processed to verify its authenticity, including a check for the signature or signatures included in the message. If the message is not signed but the assertions contained in it are, the signatures of those assertions signed will be verified. Unsigned assertions will not be verified. After verifying every signed element in the response, a list of valid nodes is built, holding the DOM nodes of those XML elements that are signed and whose signatures have been successfully verified.\n\nOnce this list is built, the assertions need to be processed individually. They are not processed until the getAttributes() method of the SimpleSAML_XML_Shib13_AuthnResponse class is called. This method iterates through the list of assertions contained in the response and makes sure they were validated in the previous signature verification step, by checking if their corresponding DOM nodes are in the list of those verified.\n\nThe vulnerability is due to lax comparison of the node being checked and the nodes in the verified list. The isNodeValidated() method of the SimpleSAML_XML_Validator class checks if a given DOM node is in the validNodes array by means of the standard in_array() function. This function, however, will return unexpected results due to the default lax behaviour when checking data types in PHP. In this case, the fact that there is a DOM node in the list is enough for in_array() to return true when looking for any DOM node. This means any unsigned assertion will be considered verified if there is at least one assertion with a valid signature in the message being processed.\n\nThis issue allows an attacker to generate a SAML 1 authentication response that contains two different assertions. The first assertion is the one the attacker wants the Service Provider to use, with custom attributes, expiration and even entityID (provided that the given entityID belongs to an Identity Provider that the Service Provider knows and trusts). The second is a legitimate assertion issued and signed by an Identity Provider trusted by the Service Provider. If the second assertion is still valid when sent by the attacker, SimpleSAMLphp will merge all the attributes found in both assertions, but the entityID registered for the authenticating third-party will be the one found in the first, tampered assertion. If the second (legitimate) assertion is already expired when the attacker sends it, only the attributes found in the tampered assertion will be used.\n\nThe issue can be easily fixed by passing a third parameter to the in_array() function, telling it to perform strict comparisons when checking if an object is found inside a given array. This way, when the code evaluates if the tampered assertion is included in the list of verified assertions, it fails and only the legitimate assertion is used, if possible (e.g. it is not expired).\n\n### Affected versions\nAll SimpleSAMLphp versions before and including 1.14.16.\n\n### Impact\nAn attacker can leverage this vulnerability to impersonate any user from any SAML 1 Identity Provider trusted by a SimpleSAMLphp Service Provider, with the only pre-requisite of a valid assertion previously sent to the affected Service Provider. As such, only those SimpleSAMLphp installations that have metadata deployed for SAML 1 Identity Providers (by default, listed in the metadata/shib13-idp-remote.php file, but could be in other locations depending on your local configuration) are affected.\n\n### Resolution\nUpgrade to the latest version. When an upgrade is not possible immediately, the following patch must be applied:\n```\ndiff --git a/lib/SimpleSAML/XML/Validator.php b/lib/SimpleSAML/XML/Validator.php\nindex e4877f0..69236ef 100644\n--- a/lib/SimpleSAML/XML/Validator.php\n+++ b/lib/SimpleSAML/XML/Validator.php\n@@ -260,7 +260,7 @@ class SimpleSAML_XML_Validator {\n assert('$node instanceof DOMNode');\n\n while($node !== NULL) {\n- if(in_array($node, $this->validNodes)) {\n+ if(in_array($node, $this->validNodes, true)) {\n return TRUE;\n }\n\n```",
910
"severity": [],
1011
"affected": [
1112
{

0 commit comments

Comments
 (0)