diff --git a/advisories/github-reviewed/2024/05/GHSA-3rcq-39xp-7xjp/GHSA-3rcq-39xp-7xjp.json b/advisories/github-reviewed/2024/05/GHSA-3rcq-39xp-7xjp/GHSA-3rcq-39xp-7xjp.json index 4bc32978d67..551143ef4ae 100644 --- a/advisories/github-reviewed/2024/05/GHSA-3rcq-39xp-7xjp/GHSA-3rcq-39xp-7xjp.json +++ b/advisories/github-reviewed/2024/05/GHSA-3rcq-39xp-7xjp/GHSA-3rcq-39xp-7xjp.json @@ -1,7 +1,7 @@ { "schema_version": "1.4.0", "id": "GHSA-3rcq-39xp-7xjp", - "modified": "2024-05-21T14:49:48Z", + "modified": "2024-12-04T16:23:07Z", "published": "2024-05-21T14:49:48Z", "aliases": [ "CVE-2024-4435" @@ -63,6 +63,10 @@ { "type": "WEB", "url": "https://internetcomputer.org/docs/current/developer-docs/smart-contracts/maintain/storage#stable-memory" + }, + { + "type": "WEB", + "url": "https://rustsec.org/advisories/RUSTSEC-2024-0406.html" } ], "database_specific": { diff --git a/advisories/github-reviewed/2024/11/GHSA-j3px-q95c-9683/GHSA-j3px-q95c-9683.json b/advisories/github-reviewed/2024/11/GHSA-j3px-q95c-9683/GHSA-j3px-q95c-9683.json index 0a7b9fff9e2..734074e6dad 100644 --- a/advisories/github-reviewed/2024/11/GHSA-j3px-q95c-9683/GHSA-j3px-q95c-9683.json +++ b/advisories/github-reviewed/2024/11/GHSA-j3px-q95c-9683/GHSA-j3px-q95c-9683.json @@ -1,11 +1,9 @@ { "schema_version": "1.4.0", "id": "GHSA-j3px-q95c-9683", - "modified": "2024-11-14T18:09:33Z", + "modified": "2024-12-04T16:22:50Z", "published": "2024-11-14T18:09:33Z", - "aliases": [ - - ], + "aliases": [], "summary": "zlib-rs stack overflow during decompression with malicious input", "details": "A denial of service vulnerability was found in zlib-rs, triggered by specially constructed input. This input causes a stack overflow, resulting in the process using zlib-rs to crash.\n\n### Impact\n\nDue to the way LLVM handles the zlib-rs codebase, tail calls were not guaranteed. This caused certain input patterns to result in a large number of stack frames being required, quickly resulting in a stack overflow. These are unlikely to occur in practice, but a dedicated attacker can construct malicious input files.\n\nAfter stack overflows were found by @inahga with a fuzzer, we dove into the assembly, and found some cases where the stack grew\n\n```asm\n.LBB109_326:\n mov rdi, rbx\n call zlib_rs::inflate::State::type_do\n jmp .LBB109_311\n\n.LBB109_311:\n lea rsp, [rbp - 40]\n pop rbx\n pop r12\n pop r13\n pop r14\n pop r15\n pop rbp\n .cfi_def_cfa rsp, 8\n ret\n```\n\nLLVM wants to centralize the cleanup before the return (many other blocks jump to `LBB109_311`), thereby invalidating a tail call to `type_do`. We were not able to get rid of this call without introducing one elsewhere: we just don't currently have the power to tell LLVM what we want it to do.\n\nSo, we switch back to loop+match waiting for changes to rust to make a more efficient implementation possible. Performance-wise, the damage is relatively minimal: we're just slower in cases where we already were slower than C. We are faster in cases where the relevant code is barely touched (in these cases the logic quickly moves into a hot inner loop and just spends most of its time there).\n\n### Patches\nVersion 0.4.0 patches the problem and is no longer vulnerable.\n\n### Workarounds\nUsers of zlib-rs should upgrade to the latest version. Users could alternatively run zlib-rs in a separate process to prevent a stack overflow crashing the entire program. In some situations a signal handler can be used to catch a stack overflow happening.\n", "severity": [ @@ -90,6 +88,10 @@ { "type": "PACKAGE", "url": "https://github.com/trifectatechfoundation/zlib-rs" + }, + { + "type": "WEB", + "url": "https://rustsec.org/advisories/RUSTSEC-2024-0401.html" } ], "database_specific": { diff --git a/advisories/github-reviewed/2024/11/GHSA-xg58-75qf-9r67/GHSA-xg58-75qf-9r67.json b/advisories/github-reviewed/2024/11/GHSA-xg58-75qf-9r67/GHSA-xg58-75qf-9r67.json index 04a823ac287..c6d4727efea 100644 --- a/advisories/github-reviewed/2024/11/GHSA-xg58-75qf-9r67/GHSA-xg58-75qf-9r67.json +++ b/advisories/github-reviewed/2024/11/GHSA-xg58-75qf-9r67/GHSA-xg58-75qf-9r67.json @@ -1,13 +1,13 @@ { "schema_version": "1.4.0", "id": "GHSA-xg58-75qf-9r67", - "modified": "2024-12-03T18:11:16Z", + "modified": "2024-12-04T16:22:27Z", "published": "2024-11-25T19:35:10Z", "aliases": [ "CVE-2024-52529" ], "summary": "Cilium's Layer 7 policy enforcement may not occur in policies with wildcarded port ranges", - "details": "### Impact\n\nFor users with the following configuration:\n\n* An allow policy that selects a [Layer 3 destination](https://docs.cilium.io/en/v1.14/security/policy/language/#layer-3-examples) and a [port range](https://docs.cilium.io/en/stable/security/policy/language/#example-port-ranges) **AND**\n* A [Layer 7 allow policy](https://docs.cilium.io/en/latest/security/policy/language/#layer-7-examples) that selects a specific port within the first policy's range \n\nthen Layer 7 enforcement would not occur for the traffic selected by the Layer 7 policy.\n\nThis issue only affects users who use Cilium's port range functionality, which was introduced in Cilium v1.16.\n\nFor reference, an example of a pair of policies that would trigger this issue is:\n\n```\napiVersion: \"cilium.io/v2\"\nkind: CiliumNetworkPolicy\nmetadata:\n name: \"layer-3-and-4\"\nspec:\n endpointSelector:\n matchLabels:\n app: service\n ingress:\n - fromCIDR:\n - 192.168.60.0/24\n toPorts:\n - ports:\n - port: \"80\"\n endPort: 444\n protocol: TCP\n```\nand\n```\napiVersion: \"cilium.io/v2\"\nkind: CiliumNetworkPolicy\nmetadata:\n name: \"layer-4-and-7\"\nspec:\n endpointSelector:\n matchLabels:\n app: service\n ingress:\n toPorts:\n - ports:\n - port: \"80\"\n protocol: TCP\n rules:\n http:\n - method: \"GET\"\n path: \"/public\"\n```\n\nIn the above example, requests would be permitted to all HTTP paths on matching endpoints, rather than just `GET` requests to the `/public` path as intentded by the `l7-port-range-rule` policy. In patched versions of Cilium, the `l7-port-range-rule` would take precedence over the `l3-port-range-rule`.\n\n### Patches\n\nThis issue is patched in https://github.com/cilium/cilium/pull/35150.\n\nThis issue affects Cilium v1.16 between v1.16.0 and v1.16.3 inclusive.\n\nThis issue is patched in Cilium v1.16.4.\n\n### Workarounds\n\nUsers with network policies that match the pattern described above can work around the issue by rewriting any policies that use port ranges to individually specify the ports permitted for traffic.\n\n### Acknowledgements\nThe Cilium community has worked together with members of Isovalent to prepare these mitigations. Special thanks to @jrajahalme for resolving this issue.\n\n### For more information\nIf you have any questions or comments about this advisory, please reach out on [Slack](https://docs.cilium.io/en/latest/community/community/#slack).\n\nIf you think you have found a vulnerability affecting Cilium, we strongly encourage you to report it to our security mailing list at [security@cilium.io](mailto:security@cilium.io). This is a private mailing list for the Cilium security team, and your report will be treated as top priority.\n", + "details": "### Impact\n\nFor users with the following configuration:\n\n* An allow policy that selects a [Layer 3 identity](https://docs.cilium.io/en/v1.14/security/policy/language/#layer-3-examples) and a [port range](https://docs.cilium.io/en/stable/security/policy/language/#example-port-ranges) **AND**\n* A [Layer 7 allow policy](https://docs.cilium.io/en/latest/security/policy/language/#layer-7-examples) that selects a specific port within the first policy's range \n\nthen Layer 7 enforcement would not occur for the traffic selected by the Layer 7 policy.\n\nThis issue only affects users who use Cilium's port range functionality, which was introduced in Cilium v1.16.\n\nFor reference, an example of a pair of policies that would trigger this issue is:\n\n```\napiVersion: \"cilium.io/v2\"\nkind: CiliumNetworkPolicy\nmetadata:\n name: \"layer-3-and-4\"\nspec:\n endpointSelector:\n matchLabels:\n app: service\n ingress:\n - fromCIDR:\n - 192.168.60.0/24\n toPorts:\n - ports:\n - port: \"80\"\n endPort: 444\n protocol: TCP\n```\nand\n```\napiVersion: \"cilium.io/v2\"\nkind: CiliumNetworkPolicy\nmetadata:\n name: \"layer-4-and-7\"\nspec:\n endpointSelector:\n matchLabels:\n app: service\n ingress:\n toPorts:\n - ports:\n - port: \"80\"\n protocol: TCP\n rules:\n http:\n - method: \"GET\"\n path: \"/public\"\n```\n\nIn the above example, requests would be permitted to all HTTP paths on matching endpoints, rather than just `GET` requests to the `/public` path as intended by the `layer-4-and-7` policy. In patched versions of Cilium, the `layer-4-and-7` rule would take precedence over the `layer-3-and-4` rule.\n\n### Patches\n\nThis issue is patched in https://github.com/cilium/cilium/pull/35150.\n\nThis issue affects Cilium v1.16 between v1.16.0 and v1.16.3 inclusive.\n\nThis issue is patched in Cilium v1.16.4.\n\n### Workarounds\n\nUsers with network policies that match the pattern described above can work around the issue by rewriting any policies that use port ranges to individually specify the ports permitted for traffic.\n\n### Acknowledgements\nThe Cilium community has worked together with members of Isovalent to prepare these mitigations. Special thanks to @jrajahalme for resolving this issue.\n\n### For more information\nIf you have any questions or comments about this advisory, please reach out on [Slack](https://docs.cilium.io/en/latest/community/community/#slack).\n\nIf you think you have found a vulnerability affecting Cilium, we strongly encourage you to report it to our security mailing list at [security@cilium.io](mailto:security@cilium.io). This is a private mailing list for the Cilium security team, and your report will be treated as top priority.\n", "severity": [ { "type": "CVSS_V3",