From 1d7d4da0149f4e37061c54734ab7676a88392295 Mon Sep 17 00:00:00 2001 From: frasertweedale Date: Wed, 2 Oct 2024 20:23:02 +0000 Subject: [PATCH] deploy: d5d7caf879218a8d5447f954ce868906810c8240 --- .nojekyll | 0 advisory/HSEC-2023-0001.html | 32 ++ advisory/HSEC-2023-0002.html | 29 ++ advisory/HSEC-2023-0003.html | 29 ++ advisory/HSEC-2023-0004.html | 31 ++ advisory/HSEC-2023-0005.html | 32 ++ advisory/HSEC-2023-0006.html | 24 + advisory/HSEC-2023-0007.html | 65 +++ advisory/HSEC-2023-0008.html | 41 ++ advisory/HSEC-2023-0009.html | 40 ++ advisory/HSEC-2023-0010.html | 64 +++ advisory/HSEC-2023-0011.html | 42 ++ advisory/HSEC-2023-0012.html | 29 ++ advisory/HSEC-2023-0013.html | 64 +++ advisory/HSEC-2023-0014.html | 24 + advisory/HSEC-2023-0015.html | 87 ++++ advisory/HSEC-2024-0001.html | 27 ++ advisory/HSEC-2024-0002.html | 57 +++ advisory/HSEC-2024-0003.html | 140 ++++++ advisory/HSEC-2024-0009.html | 30 ++ assets/css/default.css | 152 ++++++ assets/images/hf-logo.png | Bin 0 -> 12105 bytes atom.xml | 869 +++++++++++++++++++++++++++++++++++ by-dates.html | 1 + by-packages.html | 1 + index.html | 1 + 26 files changed, 1911 insertions(+) create mode 100644 .nojekyll create mode 100644 advisory/HSEC-2023-0001.html create mode 100644 advisory/HSEC-2023-0002.html create mode 100644 advisory/HSEC-2023-0003.html create mode 100644 advisory/HSEC-2023-0004.html create mode 100644 advisory/HSEC-2023-0005.html create mode 100644 advisory/HSEC-2023-0006.html create mode 100644 advisory/HSEC-2023-0007.html create mode 100644 advisory/HSEC-2023-0008.html create mode 100644 advisory/HSEC-2023-0009.html create mode 100644 advisory/HSEC-2023-0010.html create mode 100644 advisory/HSEC-2023-0011.html create mode 100644 advisory/HSEC-2023-0012.html create mode 100644 advisory/HSEC-2023-0013.html create mode 100644 advisory/HSEC-2023-0014.html create mode 100644 advisory/HSEC-2023-0015.html create mode 100644 advisory/HSEC-2024-0001.html create mode 100644 advisory/HSEC-2024-0002.html create mode 100644 advisory/HSEC-2024-0003.html create mode 100644 advisory/HSEC-2024-0009.html create mode 100644 assets/css/default.css create mode 100644 assets/images/hf-logo.png create mode 100644 atom.xml create mode 100644 by-dates.html create mode 100644 by-packages.html create mode 100644 index.html diff --git a/.nojekyll b/.nojekyll new file mode 100644 index 00000000..e69de29b diff --git a/advisory/HSEC-2023-0001.html b/advisory/HSEC-2023-0001.html new file mode 100644 index 00000000..a59fec35 --- /dev/null +++ b/advisory/HSEC-2023-0001.html @@ -0,0 +1,32 @@ +Haskell Security advisories

Advisories list

[advisory]
+id = "HSEC-2023-0001"
+cwe = [328, 400]
+keywords = ["json", "dos", "historical"]
+aliases = ["CVE-2022-3433"]
+
+[[affected]]
+package = "aeson"
+cvss = "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"
+
+[[affected.versions]]
+introduced = "0.4.0.0"
+fixed = "2.0.1.0"
+
+[[references]]
+type = "ARTICLE"
+url = "https://cs-syd.eu/posts/2021-09-11-json-vulnerability"
+[[references]]
+type = "ARTICLE"
+url = "https://frasertweedale.github.io/blog-fp/posts/2021-10-12-aeson-hash-flooding-protection.html"
+[[references]]
+type = "DISCUSSION"
+url = "https://github.com/haskell/aeson/issues/864"
+
+

Hash flooding vulnerability in aeson

+

aeson was vulnerable to hash flooding (a.k.a. hash DoS). The +issue is a consequence of the HashMap implementation from +unordered-containers. It results in a denial of service through +CPU consumption. This technique has been used in real-world attacks +against a variety of languages, libraries and frameworks over the +years.

+
\ No newline at end of file diff --git a/advisory/HSEC-2023-0002.html b/advisory/HSEC-2023-0002.html new file mode 100644 index 00000000..4efbf247 --- /dev/null +++ b/advisory/HSEC-2023-0002.html @@ -0,0 +1,29 @@ +Haskell Security advisories

Advisories list

[advisory]
+id = "HSEC-2023-0002"
+cwe = [347]
+keywords = ["crypto", "historical"]
+aliases = ["CVE-2022-31053"]
+related = ["GHSA-75rw-34q6-72cr"]
+
+[[affected]]
+package = "biscuit-haskell"
+cvss = "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"
+[[affected.versions]]
+introduced = "0.1.0.0"
+fixed = "0.2.0.0"
+
+[[references]]
+type = "REPORT"
+url = "https://eprint.iacr.org/2020/1484"
+[[references]]
+type = "ADVISORY"
+url = "https://github.com/biscuit-auth/biscuit/security/advisories/GHSA-75rw-34q6-72cr"
+
+
+

Improper Verification of Cryptographic Signature

+

The Biscuit specification version 1 contains a vulnerable algorithm that allows +malicious actors to forge valid Γ-signatures. Such an attack would allow an +attacker to create a token with any access level. The version 2 of the +specification mandates a different algorithm than gamma signatures and as such +is not affected by this vulnerability.

+
\ No newline at end of file diff --git a/advisory/HSEC-2023-0003.html b/advisory/HSEC-2023-0003.html new file mode 100644 index 00000000..89e04181 --- /dev/null +++ b/advisory/HSEC-2023-0003.html @@ -0,0 +1,29 @@ +Haskell Security advisories

Advisories list

[advisory]
+id = "HSEC-2023-0003"
+cwe = [94]
+keywords = ["code", "injection", "historical"]
+aliases = ["CVE-2013-1436"]
+
+[[affected]]
+package = "xmonad-contrib"
+cvss = "AV:N/AC:L/Au:N/C:P/I:P/A:P"
+[[affected.versions]]
+introduced = "0.5"
+fixed = "0.11.2"
+
+[[references]]
+type = "ADVISORY"
+url = "https://security.gentoo.org/glsa/201405-28"
+[[references]]
+type = "DISCUSSION"
+url = "http://www.openwall.com/lists/oss-security/2013/07/26/5"
+[[references]]
+type = "FIX"
+url = "https://github.com/xmonad/xmonad-contrib/commit/d3b2a01e3d01ac628e7a3139dd55becbfa37cf51"
+
+

code injection in xmonad-contrib

+

The XMonad.Hooks.DynamicLog module in xmonad-contrib before +0.11.2 allows remote attackers to execute arbitrary commands via a +web page title, which activates the commands when the user clicks on +the xmobar window title, as demonstrated using an action tag.

+
\ No newline at end of file diff --git a/advisory/HSEC-2023-0004.html b/advisory/HSEC-2023-0004.html new file mode 100644 index 00000000..f2721c44 --- /dev/null +++ b/advisory/HSEC-2023-0004.html @@ -0,0 +1,31 @@ +Haskell Security advisories

Advisories list

[advisory]
+id = "HSEC-2023-0004"
+cwe = [776]
+keywords = ["xml", "dos", "historical"]
+aliases = ["CVE-2021-4249", "VDB-216204"]
+
+[[affected]]
+package = "xml-conduit"
+cvss = "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
+
+[[affected.versions]]
+introduced = "0.5.0"
+fixed = "1.9.1.0"
+
+[[references]]
+type = "FIX"
+url = "https://github.com/snoyberg/xml/pull/161"
+[[references]]
+type = "FIX"
+url = "https://github.com/snoyberg/xml/commit/4be1021791dcdee8b164d239433a2043dc0939ea"
+
+

xml-conduit unbounded entity expansion

+

A vulnerability was found in xml-conduit. It has been classified +as problematic. Affected is an unknown function of the file +xml-conduit/src/Text/XML/Stream/Parse.hs of the component DOCTYPE +Entity Expansion Handler. The manipulation leads to infinite loop. +It is possible to launch the attack remotely. Upgrading to version +1.9.1.0 is able to address this issue. The name of the patch is +4be1021791dcdee8b164d239433a2043dc0939ea. It is recommended to +upgrade the affected component.

+
\ No newline at end of file diff --git a/advisory/HSEC-2023-0005.html b/advisory/HSEC-2023-0005.html new file mode 100644 index 00000000..010e079a --- /dev/null +++ b/advisory/HSEC-2023-0005.html @@ -0,0 +1,32 @@ +Haskell Security advisories

Advisories list

[advisory]
+id = "HSEC-2023-0005"
+cwe = [295]
+keywords = ["x509", "pki", "mitm", "historical"]
+aliases = ["CVE-2013-0243"]
+
+[[affected]]
+package = "tls-extra"
+cvss = "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N"
+
+[[affected.versions]]
+introduced = "0.1.0"
+fixed = "0.4.6.1"
+
+[[references]]
+type = "DISCUSSION"
+url = "https://www.openwall.com/lists/oss-security/2013/01/30/6"
+[[references]]
+type = "REPORT"
+url = "https://github.com/haskell-tls/hs-tls/issues/29"
+[[references]]
+type = "FIX"
+url = "https://github.com/haskell-tls/hs-tls/commit/15885c0649ceabd2f4d2913df8ac6dc63d6b3b37"
+
+

tls-extra: certificate validation does not check Basic Constraints

+

tls-extra does not check the Basic Constraints extension of a +certificate in certificate chain processing. Any certificate is +treated as a CA certificate. As a consequence, anyone who has a +valid certificate can use it to sign another one (with an arbitrary +subject DN/domain name embedded into it) and have it accepted by +tls. This allows MITM attacks on TLS connections.

+
\ No newline at end of file diff --git a/advisory/HSEC-2023-0006.html b/advisory/HSEC-2023-0006.html new file mode 100644 index 00000000..eff999c0 --- /dev/null +++ b/advisory/HSEC-2023-0006.html @@ -0,0 +1,24 @@ +Haskell Security advisories

Advisories list

[advisory]
+id = "HSEC-2023-0006"
+cwe = [295]
+keywords = ["x509", "pki", "historical"]
+
+[[affected]]
+package = "x509-validation"
+cvss = "CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:N"
+
+[[affected.versions]]
+introduced = "1.4.0"
+fixed = "1.4.8"
+
+[[references]]
+type = "FIX"
+url = "https://github.com/haskell-tls/hs-certificate/commit/06d15dbbc53739314760d8504ca764000770e46e"
+
+

x509-validation does not enforce pathLenConstraint

+

x509-validation prior to version 1.4.8 did not enforce the +pathLenConstraint value. Constrained CAs could accidentally (or +deliberately) issue CAs below the maximum depth and +x509-validation would accept certificates issued by the +unauthorised intermediate CAs.

+
\ No newline at end of file diff --git a/advisory/HSEC-2023-0007.html b/advisory/HSEC-2023-0007.html new file mode 100644 index 00000000..79a101a7 --- /dev/null +++ b/advisory/HSEC-2023-0007.html @@ -0,0 +1,65 @@ +Haskell Security advisories

Advisories list

[advisory]
+id = "HSEC-2023-0007"
+cwe = [1284, 789]
+keywords = ["toml", "parser", "dos"]
+
+[[affected]]
+package = "base"
+cvss = "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
+[[affected.versions]]
+# it was introduced earlier, but this is the earliest version on Hackage
+introduced = "3.0.3.1"
+
+[[affected]]
+package = "toml-reader"
+cvss = "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
+[[affected.versions]]
+introduced = "0.1.0.0"
+fixed = "0.2.0.0"
+
+[[references]]
+type = "REPORT"
+url = "https://gitlab.haskell.org/ghc/ghc/-/issues/23538"
+[[references]]
+type = "REPORT"
+url = "https://github.com/brandonchinn178/toml-reader/issues/8"
+[[references]]
+type = "FIX"
+url = "https://github.com/brandonchinn178/toml-reader/pull/9"
+
+
+

readFloat: memory exhaustion with large exponent

+

Numeric.readFloat takes time and memory linear in the size of the +number denoted by the input string. In particular, processing a +number expressed in scientific notation with a very large exponent +could cause a denial of service. The slowdown is observable on a +modern machine running GHC 9.4.4:

+
ghci> import qualified Numeric
+ghci> Numeric.readFloat "1e1000000"    -- near instantaneous
+[(Infinity,"")]
+ghci> Numeric.readFloat "1e10000000"   -- perceptible pause
+[(Infinity,"")]
+ghci> Numeric.readFloat "1e100000000"  -- ~ 3 seconds
+[(Infinity,"")]
+ghci> Numeric.readFloat "1e1000000000" -- ~ 35 seconds
+[(Infinity,"")]
+
+

In base

+

Numeric.readFloat is defined for all RealFrac a => a:

+
readFloat :: RealFrac a => ReadS a
+
+

The RealFrac type class does not express any bounds on the size of +values representable in the types for which instances exist, so +bounds checking is not possible (in this generic function). +readFloat uses to Text.Read.Lex.numberToRational which, among +other things, calculates 10 ^ exponent, which seems to take linear +time and memory.

+

Mitigation: use read. The Read instances for Float and +Double perform bounds checks on the exponent, via +Text.Read.Lex.numberToRangedRational.

+

In toml-reader

+

The issue was detected in toml-reader version 0.1.0.0, and +mitigated in version 0.2.0.0 by immediately returning Infinity +when the exponent is large enough that there's no reason to process +it.

+
\ No newline at end of file diff --git a/advisory/HSEC-2023-0008.html b/advisory/HSEC-2023-0008.html new file mode 100644 index 00000000..c11719e7 --- /dev/null +++ b/advisory/HSEC-2023-0008.html @@ -0,0 +1,41 @@ +Haskell Security advisories

Advisories list

[advisory]
+id = "HSEC-2023-0008"
+cwe = [87]
+keywords = ["web", "xss", "historical"]
+aliases = ["CVE-2021-46888"]
+
+[[affected]]
+package = "hledger-web"
+cvss = "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N"
+[[affected.versions]]
+introduced = "0.24"
+fixed = "1.23"
+
+[[references]]
+type = "REPORT"
+url = "https://github.com/simonmichael/hledger/issues/1525"
+[[references]]
+type = "INTRODUCED"
+url = "https://github.com/simonmichael/hledger/commit/ec51d28839b2910eea360b1b8c72904b51cf7821"
+[[references]]
+type = "EVIDENCE"
+url = "https://www.youtube.com/watch?v=QnRO-VkfIic"
+[[references]]
+type = "FIX"
+url = "https://github.com/simonmichael/hledger/pull/1663"
+
+
+

Stored XSS in hledger-web

+

An issue was discovered in hledger-web < 1.23. A Stored Cross-Site +Scripting (XSS) vulnerability exists in toBloodhoundJson that +allows an attacker to execute JavaScript by encoding user-controlled +values in a payload with base64 and parsing them with the atob +function.

+

hledger-web forms sanitise obvious JavaScript, but not obfuscated +JavaScript (see OWASP Filter Evasion Cheat Sheet). +This means hledger-web instances, especially anonymously-writable +ones like demo.hledger.org, could be loaded with malicious +JavaScript to be executed by subsequent visitors.

+

Reported by Gaspard Baye and Hamidullah Muslih. Fix by Arsen +Arsenović.

+
\ No newline at end of file diff --git a/advisory/HSEC-2023-0009.html b/advisory/HSEC-2023-0009.html new file mode 100644 index 00000000..0c42d2cc --- /dev/null +++ b/advisory/HSEC-2023-0009.html @@ -0,0 +1,40 @@ +Haskell Security advisories

Advisories list

[advisory]
+id = "HSEC-2023-0009"
+cwe = [20, 78]
+keywords = ["ssh", "command-injection", "historical"]
+aliases = ["CVE-2017-12976"]
+related = ["CVE-2017-9800", "CVE-2017-12836", "CVE-2017-1000116", "CVE-2017-1000117"]
+
+[[affected]]
+package = "git-annex"
+cvss = "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H"
+[[affected.versions]]
+introduced = "0.1"
+fixed = "6.20170818"
+
+[[references]]
+type = "ADVISORY"
+url = "https://git-annex.branchable.com/security/CVE-2017-12976/"
+[[references]]
+type = "FIX"
+url = "http://source.git-annex.branchable.com/?p=source.git;a=commitdiff;h=df11e54788b254efebb4898b474de11ae8d3b471"
+
+

git-annex command injection via malicious SSH hostname

+

git-annex was vulnerable to the same class of security hole as +git's CVE-2017-1000117. In several cases, git-annex parses a +repository URL, and uses it to generate a ssh command, with the +hostname to ssh to coming from the URL. If the hostname it parses is +something like -eProxyCommand=evil, this could result in arbitrary +local code execution.

+

Some details of URL parsing may prevent the exploit working in some +cases.

+

Exploiting this would involve the attacker tricking the victim into +adding a remote something like ssh://-eProxyCommand=evil/blah.

+

One possible avenue for an attacker that avoids exposing the URL to +the user is to use initremote with an SSH remote, so embedding the +URL in the git-annex branch. Then the victim would enable it with +enableremote.

+

This was fixed in version 6.20170818. Now there's a SshHost +type that is not allowed to start with a dash, and every invocation +of git-annex uses a function that takes a SshHost.

+
\ No newline at end of file diff --git a/advisory/HSEC-2023-0010.html b/advisory/HSEC-2023-0010.html new file mode 100644 index 00000000..8ae91018 --- /dev/null +++ b/advisory/HSEC-2023-0010.html @@ -0,0 +1,64 @@ +Haskell Security advisories

Advisories list

[advisory]
+id = "HSEC-2023-0010"
+cwe = [200, 610]
+keywords = ["exfiltration", "historical"]
+aliases = ["CVE-2018-10857"]
+
+[[affected]]
+package = "git-annex"
+cvss = "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N"
+[[affected.versions]]
+introduced = "0.1"
+fixed = "6.20180626"
+
+[[references]]
+type = "ADVISORY"
+url = "https://git-annex.branchable.com/security/CVE-2018-10857_and_CVE-2018-10859/"
+
+

git-annex private data exfiltration to compromised remote

+

Some uses of git-annex were vulnerable to a private data exposure +and exfiltration attack. It could expose the content of files +located outside the git-annex repository, or content from a +private web server on localhost or the LAN. Joey Hess discovered +this attack.

+

To perform this attack, the attacker needs to have control over one +of the remotes of the victim's git-annex repository. For example, +they may provide a public git-annex repository that the victim +clones. Or, equivalantly, the attacker could have read access to the +victim's git-annex repository or a repository it pushes to, and +some channel to get commits into it (e.g. pull requests).

+

These exploits are most likely to succeed when the victim is running +the git-annex assistant, or is periodically running git annex sync --content.

+

To perform the attack the attacker runs git-annex addurl --relaxed file:///etc/passwd and commits this to the repository in some out +of the way place. After the victim's git repository receives that +change, git-annex follows the attacker-provided URL to the private +data, which it stores in the git-annex repository. From there it +transfers the content to the remote git-annex repository that the +attacker has access to.

+

As well as file:/// URLs, the attacker can use URLs to private web +servers. The URL can also be one that the attacker controls, that +redirects to a URL that is accessible to the victim system (and not +necessarily the compromised remote).

+

Fix

+

The issue was fixed by making git-annex refuse to follow +file:/// urls and URLs pointing to private/local IP addresses by +default. Two new configuration settings, +annex.security.allowed-url-schemes and +annex.security.allowed-ip-addresses, can relax this security +policy, and are intended for cases where the git-annex repository +is kept private and so the attack does not apply.

+

Impact on external special remotes

+

One variant of this issue can exploit a vulnerable external special +remote, and could not be prevented by git-annex. (git-annex's +own built-in special remotes are not vulnerable to this attack.)

+

In this attack variant, the attacker guesses the hash of a file +stored on the victim's private web server, and adds it to the +git-annex repository. The attacker also has control of the server +hosting an encrypted special remote used by the victim's git-annex +repository. They cause that server to redirect to the victim's web +server. This allows the attacker to verify if the victim's web +server contains a file that the attacker already knows the content +of, assuming they can guess the URL to it.

+

Developers of external special remotes are encouraged to prevent +this attack by not following such HTTP redirects.

+
\ No newline at end of file diff --git a/advisory/HSEC-2023-0011.html b/advisory/HSEC-2023-0011.html new file mode 100644 index 00000000..10bf17ab --- /dev/null +++ b/advisory/HSEC-2023-0011.html @@ -0,0 +1,42 @@ +Haskell Security advisories

Advisories list

[advisory]
+id = "HSEC-2023-0011"
+cwe = [200]
+keywords = ["exfiltration", "pgp", "historical"]
+aliases = ["CVE-2018-10859"]
+related = ["HSEC-2023-0010", "CVE-2018-10857"]
+
+[[affected]]
+package = "git-annex"
+cvss = "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N"
+[[affected.versions]]
+introduced = "0.20110417"
+fixed = "6.20180626"
+
+[[references]]
+type = "ADVISORY"
+url = "https://git-annex.branchable.com/security/CVE-2018-10857_and_CVE-2018-10859/"
+
+

git-annex GPG decryption attack via compromised remote

+

A malicious server for a special remote could trick git-annex into +decrypting a file that was encrypted to the user's GPG key. This +attack could be used to expose encrypted data that was never stored +in git-annex. Daniel Dent discovered this attack in collaboration +with Joey Hess.

+

To perform this attack the attacker needs control of a server +hosting an encrypted special remote used by the victim's +git-annex repository. The attacker uses git annex addurl --relaxed with an innocuous URL, and waits for the user's +git-annex to download it, and upload an (encrypted) copy to the +special remote they also control. At some later point, when the +user downloads the content from the special remote, the attacker +instead sends them the content of the GPG-encrypted file that they +wish to have decrypted in its place (which may have been exfiltrated +from the victim's system via the attack described in +HSEC-2023-0010 / CVE-2018-10857, or acquired by other +means). Finally, the attacker drops their own copy of the original +innocuous URL, and waits for the victim git-annex to send them the +accidentially decrypted file.

+

The issue was fixed by making git-annex refuse to download +encrypted content from special remotes, unless it knows the hash of +the expected content. When the attacker provides some other +GPG-encrypted content, it will fail the hash check and be discarded.

+
\ No newline at end of file diff --git a/advisory/HSEC-2023-0012.html b/advisory/HSEC-2023-0012.html new file mode 100644 index 00000000..accca5ae --- /dev/null +++ b/advisory/HSEC-2023-0012.html @@ -0,0 +1,29 @@ +Haskell Security advisories

Advisories list

[advisory]
+id = "HSEC-2023-0012"
+cwe = [200]
+keywords = ["historical"]
+
+[[affected]]
+package = "git-annex"
+cvss = "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N"
+[[affected.versions]]
+introduced = "0.20110417"
+fixed = "6.20160419"
+
+[[references]]
+type = "ADVISORY"
+url = "https://git-annex.branchable.com/security/checksum_exposure_to_encrypted_special_remotes/"
+[[references]]
+type = "FIX"
+url = "http://source.git-annex.branchable.com/?p=source.git;a=commitdiff;h=b890f3a53d936b5e40aa9acc5876cb98f18b9657"
+
+

git-annex checksum exposure to encrypted special remotes

+

A bug exposed the checksum of annexed files to encrypted special +remotes, which are not supposed to have access to the checksum of +the un-encrypted file. This only occurred when resuming uploads to +the encrypted special remote, so it is considered a low-severity +security hole.

+

For details, see commit b890f3a53d936b5e40aa9acc5876cb98f18b9657.

+

No CVE was assigned for this issue.

+

Fixed in git-annex-6.20160419.

+
\ No newline at end of file diff --git a/advisory/HSEC-2023-0013.html b/advisory/HSEC-2023-0013.html new file mode 100644 index 00000000..88618a87 --- /dev/null +++ b/advisory/HSEC-2023-0013.html @@ -0,0 +1,64 @@ +Haskell Security advisories

Advisories list

[advisory]
+id = "HSEC-2023-0013"
+cwe = [312]
+keywords = ["historical"]
+aliases = ["CVE-2014-6274"]
+
+[[affected]]
+package = "git-annex"
+cvss = "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H"
+[[affected.versions]]
+introduced = "0.20110401"
+fixed = "5.20140919"
+
+[[references]]
+type = "ADVISORY"
+url = "https://git-annex.branchable.com/security/CVE-2014-6274/"
+[[references]]
+type = "ARTICLE"
+url = "https://git-annex.branchable.com/upgrades/insecure_embedded_creds/"
+
+

git-annex plaintext storage of embedded credentials on encrypted remotes

+

git-annex had a bug in the S3 and Glacier remotes where if +embedcreds=yes was set, and the remote used encryption=pubkey or +encryption=hybrid, the embedded AWS credentials were stored in the +Git repository in (effectively) plaintext, not encrypted as they +were supposed to be.

+

That means that anyone who gets a copy of the Git repository can +extract the AWS credentials from it. Which would be bad.

+

A remote with this problem cannot be enabled using git annex enableremote. Old versions of git-annex will fail with a GPG +error; the current version will fail with a pointer to this web +page.

+

Remediation

+

If your repository has this problem, chose from one of these +approaches to deal with it:

+
    +
  1. +

    Change your AWS credentials, so the ones stored in the clear in +git won't be used.

    +

    After changing the credentials, make sure you have a fixed +version of git-annex, and you can then re-embed the new creds +into the repository, encrypted this time, by setting the +AWS_SECRET_ACCESS_KEY and AWS_ACCESS_KEY_ID environment +variables, and running git annex enableremote $remotename embedcreds=yes.

    +
    2. +
  2. +

    Fix the problem and then remove the history of the git-annex +branch of the repository.

    +

    Make sure you have a fixed version of git-annex, and force +git-annex to rewrite the embedded creds, with encryption this +time, by setting by setting the AWS_SECRET_ACCESS_KEY and +AWS_ACCESS_KEY_ID environment variables, and running git annex enableremote $remotename embedcreds=yes.

    +

    Then, to get rid of old versions of the git-annex branch that +still contains the creds in cleartext, you can use git annex forget; note that it will remove other historical data too.

    +

    Keep in mind that this will not necessarily delete data from +clones you do not control.

    +
    3. +
  3. +

    If you're sure that you're the only one who has access to the +repository, you could decide to leave it as-is. It's no more +insecure than if you had used encryption=shared in the first +place when setting it up.

    +
    4. +
+
\ No newline at end of file diff --git a/advisory/HSEC-2023-0014.html b/advisory/HSEC-2023-0014.html new file mode 100644 index 00000000..dff190eb --- /dev/null +++ b/advisory/HSEC-2023-0014.html @@ -0,0 +1,24 @@ +Haskell Security advisories

Advisories list

[advisory]
+id = "HSEC-2023-0014"
+keywords = ["file write"]
+aliases = ["CVE-2023-35936", "GHSA-xj5q-fv23-575g"]
+cwe = [20]
+
+[[references]]
+type = "REPORT"
+url = "https://github.com/jgm/pandoc/security/advisories/GHSA-xj5q-fv23-575g"
+
+[[affected]]
+package = "pandoc"
+cvss = "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:N/I:H/A:L"
+
+[[affected.versions]]
+introduced = "1.13"
+fixed = "3.1.4"
+
+
+

Arbitrary file write is possible when using PDF output or --extract-media with untrusted input

+

Pandoc is susceptible to an arbitrary file write vulnerability, which can be triggered by providing a specially crafted image element in the input when generating files using the --extract-media option or outputting to PDF format. This vulnerability allows an attacker to create or overwrite arbitrary files on the system (depending on the privileges of the process running pandoc).

+

This vulnerability only affects systems that (a) pass untrusted user input to pandoc and (b) allow pandoc to be used to produce a PDF or with the --extract-media option.

+

The vulnerability is patched in pandoc 3.1.4.

+
\ No newline at end of file diff --git a/advisory/HSEC-2023-0015.html b/advisory/HSEC-2023-0015.html new file mode 100644 index 00000000..a807bef2 --- /dev/null +++ b/advisory/HSEC-2023-0015.html @@ -0,0 +1,87 @@ +Haskell Security advisories

Advisories list

[advisory]
+id = "HSEC-2023-0015"
+cwe = [672]
+keywords = ["hackage", "mitm", "supply-chain"]
+
+[[affected]]
+package = "cabal-install"
+cvss = "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N"
+[[affected.versions]]
+introduced = "1.24.0.0"
+fixed = "3.10.2.0"
+
+[[references]]
+type = "REPORT"
+url = "https://github.com/haskell/cabal/issues/8918#issuecomment-1521096581"
+[[references]]
+type = "FIX"
+url = "https://github.com/haskell/cabal/commit/dcfdc9cffd74cade4e8cf3df37c5993413ffd30f"
+
+

cabal-install uses expired key policies

+

A problem was recently discovered in cabal-install's +implementation of the Hackage Security protocol that would allow an +attacker who was in possession of a revoked private key and who +could perform a man-in-the-middle attack against Hackage to use the +revoked key to deliver malicious packages. At this time, this is +only a theoretical attack - no keys have been revoked. Release +3.10.2.0 of cabal-install contains a fix for this bug, and we have +contacted distributors of older versions (such as Linux +distributions) with a patch that they can apply.

+

Background

+

Hackage Security is an implementation of The Update Framework, +which is a design for a package repository that allows untrusted +mirrors without undermining software supply-chain security. In +particular, Hackage Security cryptographically guarantees the +following properties:

+ +

Hackage has a key policy file that delegates authority to a +number of private keys for various purposes. Most of the keys are +kept securely offline by trusted community members who annually +re-sign the various files to indicate that they still have +confidence in Hackage's policies. However, to prevent clients from +being denied updates, Hackage has an automated process that +periodically re-signs a timestamp file. This signature has a short +expiry. Additionally, a snapshot file contains signed hashes of the +Hackage index that is updated on each package upload. The timestamp +and snapshot private keys are held in memory on the Hackage server. +These are called the operational keys. If an operational key is ever +compromised, then it will be revoked by having the Hackage root +keyholders sign a new key policy file. To prevent replay attacks, +clients that connect to Hackage after this update will reject older +policy files, based on a monotonically increasing file version +number.

+

If a client has not yet received the updated policy file (for +example, because they have a fresh install of cabal-install or +because they have not run cabal update in some time), the built-in +expiration date in the file limits the window of exposure in which +the revoked operational keys would be expected. As long as the root +keys have not been compromised, the compromised operational keys can +only be used until the policy file expires. In addition to +compromising a Hackage operational key, an attacker would +additionally need to either compromise a Hackage mirror or perform a +man-in-the-middle attack against the target in order to serve a +malicious or obsolete package index.

+

The Issue

+

A bug in cabal-install caused it to skip the verification of the +key policy file's expiration timestamp. This means that users of +older, unpatched versions of cabal-install could be vulnerable to +a malicious mirror or man-in-the-middle attack against Hackage if +they have not connected to Hackage in a long time, even after the +policy file has expired.

+

We do not believe that it has been possible to exploit this +vulnerability, because no operational keys have been revoked. +However, in case key revocation occurs, we strongly advise all users +of cabal-install to ensure that they have version 3.10.2.0 or +newer, which contain the fix.

+
\ No newline at end of file diff --git a/advisory/HSEC-2024-0001.html b/advisory/HSEC-2024-0001.html new file mode 100644 index 00000000..710adeb5 --- /dev/null +++ b/advisory/HSEC-2024-0001.html @@ -0,0 +1,27 @@ +Haskell Security advisories

Advisories list

[advisory]
+id = "HSEC-2024-0001"
+cwe = [79]
+keywords = ["http", "xss", "rxss", "historical"]
+
+[[references]]
+type = "FIX"
+url = "https://github.com/snoyberg/keter/pull/246"
+
+[[affected]]
+package = "keter"
+cvss = "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N"
+declarations."Keter.Proxy.toResponse" = ">= 0.3.4 && < 1.0.1"
+declarations."Keter.Proxy.unknownHostResponse" = ">= 1.0.1 && < 1.8.4"
+
+[[affected.versions]]
+introduced = "0.3.4"
+fixed = "1.8.4"
+
+

Reflected XSS vulnerability in keter

+

Keter is an app-server/reverse-proxy often used with webapps build on Yesod web-framework.

+

In the logic handling VHost dispatch, Keter was echoing back Host header value, unescaped, +as part of an HTML error page. This constitutes a reflected-XSS vulnerability. Although +not readily exploitable directly from a browser (where Host header can't generally assume +arbitrary values), it may become such in presence of further weaknesses in components +upstream of Keter in the http proxying chain. Therefore, AC:High in CVSS evaluation.

+
\ No newline at end of file diff --git a/advisory/HSEC-2024-0002.html b/advisory/HSEC-2024-0002.html new file mode 100644 index 00000000..4b552071 --- /dev/null +++ b/advisory/HSEC-2024-0002.html @@ -0,0 +1,57 @@ +Haskell Security advisories

Advisories list

[advisory]
+id = "HSEC-2024-0002"
+cwe = [787]
+keywords = ["corruption", "vendored-code", "language-c"]
+aliases = ["CVE-2019-12900"]
+
+[[references]]
+type = "DISCUSSION"
+url = "https://gnu.wildebeest.org/blog/mjw/2019/08/02/bzip2-and-the-cve-that-wasnt/"
+
+[[references]]
+type = "DISCUSSION"
+url = "http://scary.beasts.org/security/CESA-2008-005.html"
+
+[[references]]
+type = "ADVISORY"
+url = "https://access.redhat.com/security/cve/cve-2019-12900"
+
+[[references]]
+type = "FIX"
+url = "https://sourceware.org/git/?p=bzip2.git;a=commit;h=7ed62bfb46e87a9e878712603469440e6882b184"
+
+[[affected]]
+package = "bzlib"
+cvss = "CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N"
+
+[[affected.versions]]
+introduced = "0.4"
+fixed = "0.5.2.0"
+
+[[affected]]
+package = "bz2"
+cvss = "CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N"
+
+[[affected.versions]]
+introduced = "0.1.0.0"
+fixed = "1.0.1.1"
+
+[[affected]]
+package = "bzlib-conduit"
+cvss = "CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N"
+
+[[affected.versions]]
+introduced = "0.1.0.0"
+fixed = "0.3.0.3"
+
+

out-of-bounds write when there are many bzip2 selectors

+

A malicious bzip2 payload may produce a memory corruption +resulting in a denial of service and/or remote code execution. +Network services or command line utilities decompressing +untrusted bzip2 payloads are affected.

+

Note that the exploitation of this bug relies on an undefined +behavior that appears to be handled safely by current compilers.

+

The Haskell libraires are vulnerable when they are built using +the bundled C library source code, which is the default +in most cases.

+
\ No newline at end of file diff --git a/advisory/HSEC-2024-0003.html b/advisory/HSEC-2024-0003.html new file mode 100644 index 00000000..084da72a --- /dev/null +++ b/advisory/HSEC-2024-0003.html @@ -0,0 +1,140 @@ +Haskell Security advisories

Advisories list

[advisory]
+id = "HSEC-2024-0003"
+cwe = [150]
+keywords = ["windows"]
+aliases = ["CVE-2024-3566", "VU#123335"]
+related = ["CVE-2024-1874", "CVE-2024-24576", "CVE-2024-22423"]
+
+[[references]]
+type = "ARTICLE"
+url = "https://flatt.tech/research/posts/batbadbut-you-cant-securely-execute-commands-on-windows/"
+
+[[references]]
+type = "ADVISORY"
+url = "https://kb.cert.org/vuls/id/123335"
+
+[[references]]
+type = "FIX"
+url = "https://github.com/haskell/process/commit/3c419f9eeedac024c9dccce544e5a6fb587179a5"
+
+[[references]]
+type = "FIX"
+url = "https://github.com/haskell/process/commit/951b02dd95559b1a26f2456bfb97cf740ea40934"
+
+[[references]]
+type = "FIX"
+url = "https://github.com/haskell/process/commit/5fc91f5f36ed4479be2b95f04f264bb78ac8089d"
+
+[[affected]]
+package = "process"
+os = ["mingw32"]
+cvss = "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H"
+
+[[affected.versions]]
+introduced = "1.0.0.0"
+fixed = "1.6.23.0"
+
+

process: command injection via argument list on Windows

+

The process library on Windows is vulnerable to a command injection +vulnerability, via cmd.exe's interpretation of arguments. Programs that +invoke batch files (.bat, .cmd) and pass arguments whose values are +affected by program inputs may be affected.

+

This issue was discovered in many programming languages' Windows process +execution behaviour. It was tracked by CERT/CC as VU#123335 and a +coordinated disclosure was made on 2024-04-09 17:00 UTC.

+

A fix was released in process-1.6.19.0.

+

Background

+

Unlike POSIX systems, Windows does not have a mechanism for passing multiple +arguments.Command line parsing is up to individual programs.

+

The process library defines the RawCommand constructor for specifying an +executable and its arguments:

+
data CmdSpec
+  = ShellCommand String
+  | RawCommand FilePath [String]
+
+

On Windows, the RawCommand executable name and arguments are serialised into +a single command line string, with separate arguments quoted separately. +process then invokes the Windows CreateProcess +routine with this command line string is given as the lpCommandLine +argument.

+

Issue

+

When executing .bat or .cmd files, CreateProcess +implicitly spawns cmd.exe. The System.Process command line construction +does not escape characters with special meaning to cmd.exe. As a +consequence, a command injection vulnerability arises when the following +conditions are satisfied:

+ +

Demonstration

+

The following batch file, test.bat, merely prints the executable name the +first two arguments (as interpreted by cmd.exe):

+
@ECHO OFF
+ECHO 0: %0
+ECHO 1: %1
+ECHO 2: %2
+PAUSE
+
+

The following Haskell program executes test.bat with basic string arguments. +The output is as expected:

+
λ> readProcess "test.bat" ["a","b"] [] >>= putStrLn
+0: "test.bat"
+1: "a"
+2: "b"
+
+

However, we can use a close quote and the & character to induce cmd.exe to +execute a program named in the argument:

+
λ> readProcess "test.bat" ["\"&calc.exe"] [] >>= putStrLn
+0: "test.bat"
+1: "\"
+2:
+
+

In addition to producing the above output, calc.exe is executed.

+

Mitigation

+

The lack of a general mechanism on Windows for safely conveying command line +arguments to programs increases the risk of this kind of security issue. The +fact that cmd.exe command line parsing is complex and poorly documented +exacerbates this issue, and also heightens the risk that the fix is +incomplete, or causes other issues.

+

If possible, avoid executing batch files where arguments include or are +influenced by untrusted program inputs. If it must be done, reject arguments +that include special characters including & and ".

+

Fix versions

+

process was modified to perform additional escaping and quoting +when executing .bat and .cmd files on Windows (ignoring +character case). The behaviour is unchanged in all other cases.

+

The fix was released in process-1.6.19.0. The following GHC +releases were the first in their series to include a fixed version +of the process library:

+ +

Such a change in semantics should normally result in a major version +bump. Because we expect very few (if any) users will be impacted by +the behavioural change, the GHC team made a pragmatic decision to +avoid the disruption that a major version bump would cause.

+

A follow-up fix was released in process-1.6.23.0 to handle batch +scripts with paths ending in whitespace and periods and +unescaped % expansions.

+

Acknowledgements

+

Security researcher RyotaK discovered and responsibly disclosed +this vulnerability, coordinating the response across the many +affected langauges and ecosystems.

+

Ben Gamari commited and released the fix, which was based on a +proposal by Fraser Tweedale. Fraser also improved the +System.Process module documentation to better explain the Windows +semantics.

+

Security researcher Kainan Zhang (@4xpl0r3r) discovered and +responsibly disclosing the issue in the first fix and the Rust +Security Response WG coordinated the response.

+
\ No newline at end of file diff --git a/advisory/HSEC-2024-0009.html b/advisory/HSEC-2024-0009.html new file mode 100644 index 00000000..8e1bf95d --- /dev/null +++ b/advisory/HSEC-2024-0009.html @@ -0,0 +1,30 @@ +Haskell Security advisories

Advisories list

[advisory]
+id = "HSEC-2024-0009"
+keywords = ["biscuit"]
+aliases = ["CVE-2024-41949", "GHSA-rgqv-mwc3-c78m", "GHSA-47cq-pc2v-3rmp"]
+
+[[references]]
+type = "ADVISORY"
+url = "https://github.com/biscuit-auth/biscuit-haskell/security/advisories/GHSA-47cq-pc2v-3rmp"
+[[references]]
+type = "FIX"
+url = "https://github.com/biscuit-auth/biscuit-haskell/pull/93"
+
+[[affected]]
+package = "biscuit-haskell"
+cvss = "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:N/I:L/A:N"
+
+[[affected.versions]]
+introduced = "0.3.0.0"
+fixed = "0.4.0.0"
+
+

Public key confusion in third-party blocks

+

Third-party blocks can be generated without transferring the whole token to the third-party authority. Instead, a ThirdPartyBlock request can be sent, providing only the necessary info to generate a third-party block and to sign it:

+ +

A third-party block request forged by a malicious user can trick the third-party authority into generating datalog trusting the wrong keypair.

+
\ No newline at end of file diff --git a/assets/css/default.css b/assets/css/default.css new file mode 100644 index 00000000..17973558 --- /dev/null +++ b/assets/css/default.css @@ -0,0 +1,152 @@ +:root{ + --bg-color:#FFFFFF; + --text-color:#333; + --outline-color:#DB83ED; + --header-color:#5E5184; + --anchor-color:#9E358F; + --anchor-visited-color:#6F5F9C; + --code-bg-color:#FAFAFA; + --filename-bg:#EAEAEA; + --code-color:#383a42; + --code-bg-color:#fafafa; + --code-comment-color:#a0a1a7; + --code-kw-color:#af005f; + --code-name-color:#e45649; + --code-literal-color:#268bd2; + --code-string-color:#cb4b16; + --code-attr-color:#986801; + --code-constructor-color:#5f5faf; + --code-symbol-color:#4078f2; + --code-record-field-color:#c18401; + --code-pragma-color:#2aa198 +} +@media (prefers-color-scheme:dark){ + :root{ + --bg-color:#333; + --text-color:#C9D1D9; + --header-color:#BBA1FF; + --anchor-color:#EB82DC; + --anchor-visited-color:#D5C5FF; + --code-bg-color:transparent; + --filename-bg:#2C2C2C; + --code-color:#C9D1D9; + --code-bg-color:#333; + --code-comment-color:#a0a1a7; + --code-kw-color:#BBA1FF; + --code-name-color:#e45649; + --code-literal-color:#268bd2; + --code-string-color:#cb4b16; + --code-attr-color:#986801; + --code-constructor-color:#d079c9; + --code-symbol-color:var(--code-color); + --code-record-field-color:#c18401; + --code-pragma-color:#2aa198 + } +} +*:focus-visible{ + outline-color:var(--outline-color) +} +body{ + color:var(--text-color); + background-color:var(--bg-color) +} +a{ + color:var(--anchor-color) +} +a:visited{ + color:var(--anchor-visited-color) +} +h1,h2,h3,h4,h5,h6{ + color:var(--header-color) +} +input{ + background-color:rgba(255,255,255,0.06); + color:var(--text-color) +} +.nav-bar{ + text-align: right; +} +.nav-bar ul{ + display: inline-block; + list-style: none; + margin: 0; + padding: 0; +} +.nav-bar li{ + display: inline-block; + vertical-align: middle; + padding: 0; + margin: 0; + height: 100%; + position: relative; +} + *:focus-visible{ + outline-offset:4px; + outline-width:1px +} +body{ + font-size:1.6rem; + margin:0 auto; + max-width:120rem +} +footer{ + margin-top:3rem; + padding:1.2rem 0; + border-top:0.2rem solid #000; + font-size:1.2rem; + color:#555 +} +h1{ + font-size:2.4rem +} +h2{ + font-size:2rem +} +html{ + font-size:62.5%; + font-family:Helvetica,sans-serif +} +table tbody td{ + padding:5px +} +footer{ + padding: 0 2%; + text-align: center; +} +footer .HF{ + height:50px; + line-height:50px; + display:inline-block; + background-repeat:no-repeat; + background-image:url('../images/hf-logo.png'); + background-size:50px; + background-position:left center; + padding-left:60px +} +@media (max-width:319px){ + .nav-bar{ + margin:0 1.5rem 0 0; + } + .nav-bar a{ + display:block; + line-height:1.6 + } +} +@media (min-width:320px){ + .nav-bar{ + margin:0 2rem 0 0; + } + .nav-bar a{ + display:inline; + margin:0 0.6rem + } +} +@media (min-width:640px){ + .nav-bar{ + margin:0 3rem 0 0; + } + .nav-bar a{ + margin:0 0 0 1.2rem; + display:inline + } +} diff --git a/assets/images/hf-logo.png b/assets/images/hf-logo.png new file mode 100644 index 0000000000000000000000000000000000000000..5a79f4c1ae0a84731a7485230b8487fc5978c552 GIT binary patch literal 12105 zcmeHtXH=8h)-Iv<-fQShLIR=pBE5GIl_Z4Tgg_{QROv-}2c-#81nETrC@39iN(ZHh z6hROLa=>RN-7EUF6ZgtuPf~P) zil1L`kWJl)-@`vd`}7?%_q*e&UG~>aH4P&TE<=XH_sbswu zG?`O-xBGi`-DkaoZ^d;xw_~Hd)yBCddhf2bf7z>Dn!MNPTiam$bMNAb;x6Ru#ux9S ziJI;DJj*Y+B>rJyAA4S0B)lignXGsMbIbeW==S)yc6HFZqDFAuE?}YW5H%L`#@`+_ z;*VZ>J~3@r$^1k5`BDGH?m+0X`x^x%YTpvS`w!(z_LFAuO%$9lUk=$X^>{p+UV36# z-_0HyJmg^H|GBMq%iCC1yKb!zE_a;FaB_UB&xv)okW(&+z5RsLtrHM-6?SEM3y;Mh zp~6?7SQBFNLEn9@ha84nZv@SD<0$7e$0 z!qNaa>9-Bu3{gvTJj`f^R?(xWPG6t2u7_fh4EW^h(+U{nUnf9JRrsyk9#^Ho^@OX^ z-Q23T(-1~-+vx-eJ<+s=y8Jn2Zmt#cCI~~Rc{6v<7MWGt(mXq_irG24L;GivzT2P1 z0Xz3__jJf>NyN=0d{UEA!d_i3~Uf7DJ_F$r!s#?hA zs1;M0^;V|jqTOgmJxd~xK5h40-eg91f@Bx#>oX^(yX+! z_}dg+JjX_ktz0KX!S-f#MZz=DzLdv_hnuH6DU*;Fbm=Qke8b>h=_hYq6>Txsym(fWBaR24i+9?ZF{yQLosl#I@}-#@EJi7d)iqk9 zlgVe1N>$Ar)lC{thsHt+V#?gcCX&_^l;kwXmYMFI7|>{FA!LRx$kW6*y`^Pkue(01 zyUvpJJn=A(l|R96s0zMR+Xi2vEY&g=4nFR!PL>b~S1e@dqHLc!waA08jPL14GHl*w z)vr5b`1(-N0@P-gnWOP-shgbXVrlu3eWj!L=*{diq|+PNk#yNfP^GEwnV*^Y*dm7w zm%o-M(?EG_NsubxGs(nvWLd^xT5cmP-KFCsb%Qn!2@B|ArWA#NfaXuM;(WKCy(?VK z@yio6W5~jFf<}y9i|8i}y3nvd?7gpycMT=&V(Xb6@nf|P7Xxja)hM-UWu92=gw}q^ za%)PqQ7R%WI+R|MN)XZZudytP^zpNzV*&>@-~@zg-n&71=zP*$S{M8(l>LZS$ZLS6 z(8~2*POe?4r*RvbO~Q0c^%xQ~(p;}GX1RwELn(zdnfdury7{SlHjNt_QoNOz9D%BuX$_1hW z+*#SyBHOcY$;|oYh@TdS!y?*I_rNSGv!c?4oYJu~f9`s%0r=p%iU|L1wd9g03~_v) zyi1oI5xp!fEgJx}6uomTVSRM8F^yqr&EO;n(7X!aJ07{E%I6E2zSb{))0RcZnR5dF z%=KXM)8+pAS0wF4%V~*?K@Fg@m&E=PNWJr&-FRM1ee7`0g0mpj
5YsAED%o@jS58YUI$Z6Qma$mn zoWcII_IPQcT6VY86k$h{P7HO8?i(wQMZIgDnY}+Z6wM4-oOaNrO;R3)Rd``X4q8+k z^e!&Tu4&2wLsg3x#wH}y!c4|q7PA*6l2^lB0bFy*OdUi-u!hD3@~DO2myc%=%BkPI z2`SJ9nO75e7S}`dHboyaK*NkSa_IB9^dajXy<1N>!Z)Xowh~cY6$S z@OV+Zvy3wn@$;tPW_i;0v~_05r&_TSszrcV3del1mPSO`ya^{zR%zJu3xSJf*9UfO zhSUCKvQ6`@8*WrzBCRBzUaPP$wmvY9526JO` zs~PR2k#S3eEk>j+9=CT4r~+O$(s~YvqN`!Rn5_ZYG@bwtn4B$tyv|NIZ+y;?LNu;d zoh2FMrCahdix-aCNEuD_J2nO{4#Iol+pZ^NgNI)zH^@`H0i{l|)oBizdB0f@AOZ@| zXKty1BqyTpm6PL0tUfwzdbdy_cily~iHlrc!~w*nDS^j;tI2wpuSsyeMv62 zJhImU5m7fW$8otZjzdB3vO}Na#mFX~yOmj;7E%&vFHinTNV7*+C|N z*lbX>OAgz5#@uCE{-%uCw4&X!>?!vVFCj+ajg^5T8MRCs?Y$IMYkbfo_2$O)^ey+g z5lF*a_qxMPmEf9aRRseV02OH+O2}1W?AU*WWk_n01vuk`6Iwu+ zPT4)${&+mP$Rp!qFo+VJtMer2j+v%ZxJg%PVV}I>Q#~*Idq8_lg}wGq2HR^s#LKEW z<1Rw&R_I}B!Dtu$S>nJUfqdGrfwfAaiyX!IYfeR+K=*5kuL3hpCiRhtN)knqW zW^OvQ3Mjfn_RCLxMI$7xD9_YettPXXLqdfP;xE~~Rg4d()yL+ue%^VgVyNH7a%8+6GiW3fc~rxl(TBPrA93u=UZVagLIbgB_n#d0(9ByM zcIa<#*Y-Kqw7%AkDpT$^qL(nt(k>X>2tL`b!q6+3*{fhEi1nQwv7$$?DR=@mMC+C*s>*Ywo`+X-Ol+^L(`LzKCIr#McW~F-emw z=kUal#UUwb=8sMe-TzKrbu8LRUis8KTGYk+K(-qxbAhWCpx=7T0=Li+$MFz7-76* z68eOV%U|WiVc}vDS~?*$?LpHy*caV{yj4c9sWo&&VAub=t336yAIQk;uH=2$k_-GZ??gkC+8wx=>Ip{vdRIc(17#O^WJ~Yc7CNz9S%XLlHO|hsfxrU7wtTz6 zHJ;fPxyWIzhMosgQ1RFhyr{3G8u}KNpHq!cQ>s-^)q)jKzR$xk>H~9B1V5gxEM z9KA@>)~Huh`v#!fxE`}yx>5?sV{W*xVjBw2HS0^Y%(DAEg{^8bHcBpd^c>-D8+i<3 zj^~z>`J;&8CASAQvnk>0lf~f(Vz8nL1FSFJz7y*?roD8i%pSh&$RJs&bJ)RwVS3A^e*J-E8dv-~(@4$$x0Kkd z?wmddamZcP72DkP_rhQr5tQj>%Na=nS0JD_b;QIeK0m9oVVd)1=bEc&V_$m~l`;}H z=7t%>{Jb=9DrJR7oFp2Q#uwFjsPKu>xgyzGPbgQnaUi&AJX^Yz2*Rt-wR_8|eHQ1t z73sG_5lXp`Jar+`!=lIT_L@Q=`6M=gch}ogfDrcOBs_=WTtNdN2fTojph-^!0TI9? zW2kB8PFF1Xo?#Q=f^o`VsTi|u%9a`8WtwTqwN8VE3)~-1Ca+%S=S`^JyYhQ@l`$^U z%kX{Rjbbf{i$LO+2`@&0gqGb~1FBY1n)Mp07SdXc5h(bB_j%!C^ns zMw!3EwaO_>-H72Lu8lmF%SJX{vQx<+jbY^J8L*y7i@|zX0vOx#pZdOQ95s)@Uo`O~M;elbY{hQDqK!kw0ICOt|oMPja762*SL+ zp?BHWd67jeK-{EGpeo18L=$nC-HdAqOx>oWW>58a<9QS8S2(jhgOvUrRbm4OL!(Yi z&+s?j9!JiH!$Sw6<;q?Pf30LQ+9y?uW8w%mzA?&t^7Mh^LRZwT(_9aQgLNC8`u_bU zQUw?*&!@<39n}eV`Z6RBb^3qbsh@^B_=lg(7= zSwxVuY-~H6AkoxR8RMrf_+&;PH%*2=e0%_`dyu;wu&ukcp<$x@$k;`tUJw0AcQ}_f zW7?+)3QE7I9UIM2nfq!~6Xc!wQR`Tw_{_k*+*{0+txp#%SBD#dPt`MNi+nA_{WN^K zi!LHi>P4%O|67qE|I#}UPErQ*rDh0lAiAmYzE0(}8AL^WxXi5z~OLw z0Qx8@f$&;vD?I0UYV2(>K6&o)mego}XNv1PQp2DH`*Cahj9Ab6&nF{8UIl))I;04& zN@k@q7r%X6MG;0zX<37gQ;V$b!iVfjl(jw-G|PSc2v&LEL!y*tI%7@v(VFBM!4jWI zcb013qKkq8k3|SLcQy`Uc@=$jl1$ikos4OAysE*q+q><}qt6GbL1o@1JX7n;1`jG2 zov#bsN_bb>t`ucrQ#TX1)BbZoA@#@5+&9IMa*ELbdDZggavOFrmy{w?dvo1h88sc- z@HfnNTKXhSV#t&UgAdpjzp`Z-g?)hzN)H|GsiqZgZ(Z^g>yX)#llNS+d|O<(48;JT z0ww{}E8a=2>^)zK-d*7}7mZ1M_+tJVduZ$MZ%=DoeNc#Br?pD)eH7s)+LljH`x*iLQpmKTd|R5eh>eDCrESvcJ52qvg6NWdQYV+QWn>0#h38 zI&~V6XuF4&L>c-j(E=2@35jKEc0Nal#*b?owNIj+0ExrGW##3BJ9Xl(^hw3win0eo zT_LGm=E89QW zd-PTu!;OK(uud3F1D&y_o&0v_2C=9v>1VmmkJXs?!aj6ZrtHEoBHc^wB`N zxatJ^BF%%1ED*u&2suX{6=hPzKzS^HClUn%26}pU`N;<=@%+Y>$G-nHEY1V`ZGv)F z;;}I_0cv>rB7sm46a*H#9_Sh%!J|wHRP=Rpk~h=T`V#{CNr}e=h4PUX7e}MfAhaaN z+t*nfA}1#&4wev?kPyRKi1`J1pYT^7HgDH2e$R%kNJXuzZLI!hFObAh5Wnr}*DJ{7}~eupoaX^lv@*a@nc_EO$ zps?T|S1gXKBg9b#E+s4GC?z2!28B4m#bAyI7#0F9B`E`OlyXEk{SCs{*A=Tun8)9< z`UT~Pg@QpG!7y1#DKR-11TF@JVY7jQW#M9ya#Au#ISC0Fq@&z#C`W|6mbb4b47;4J zo-k*mxR00f?}=Z8%d45_D)C5w!2cXE@qnS6untN*2CiQIf&ZMaaP>r*qhP<-gh)$4 zv1i**X{dyZgshD8KaH%AzJ6FG{=$TSL6U#q{#q7!Y%y43VZU^W1^DfOtwmnL7YRdo z`&xK=dnobzN(uPO^S8W#ihnGMj;kNmBIuXm|J1xW^3ETh{%8RY*WXh>;BVQ=!w`Q2 z@q+~*|5y>M-yc&57nqkb65HQ@3hE!@uK#ASB;_Qf;S#b)FOsoF!IIK)*cO7x z$zc0Y1}X+aIwHj+kT7YOjGQDG=JbdB{+HAv1D2LRz?~3cFt7x+9xxcYJ`fnTqn%)I z85mqr4lD`%R|WmQ=uHBQ-Ak}nEwHQwL{c6Kkq1LX!4iLyprZJ%UF07frYQb@_23@{ zf7^Dj(*0u$yPaWoNAbV5$3HcV<^O;3@n`SjV{uE-e4oWuzz)eo+cPZjpy1c$^& z$JP(~mAm<0Pk_2mK_GUJ2&HRyooI`Ym`oU-L_-04UPF|ntEpxYxUgIpnq*`wJeZ$(5~6!p8_#X!PFc>IQKgi2=qpG4qnLM3kt@RaGG7B2zB* zrQI?~HxI^cucJ@9>0`tTJ5Ri@YnZ!}eo(qr*=ObJ7nC ztJ(z!&&m-L#|(H$RLtlw5#RFtd4xYTvr1Cu=FAX4;Dy}}?hJeZj@3eZMm7c9Zt=N~ z`}E^17$KkFhrUqj%ENcJtHUHb_6O)U6^9M*R*(@&v?jX6H#2-oz+)qy*lqUDIcJHM z;(lb$w_w*|`|542ujK^AbE3Pm#~j}4K59#4Ddl9mD(u1@ez%|7JTCWHhmNvW}l!S z^vul`8pHbu;szfNG`7UvZS=uEA9htDVs-D_jyR1(`y21)Dy)6hPaGM+81y;dcqCtf zb9g=rujLs~=cct2pC=+)$V82hCbtU383P2(T3g~VdI;rwvMi)1J*6OQl%k&I zEIqRDUXlvM`m?8xZ35|pnsa*-axsJfcCCS4;G-3SiE9lwGEg8=aC2%e{6`)6i{wCH zqtyt3f>=)O@dy)HFFq$DbiE9t{?6cOz*snMj{yj=!QBsv>-k zb7bN~oYW$Zvn2ZXyJqmo>Dfk8ex|F%aK}gc^DWn$c=87om!Jok$zmxj2}$Hgj;5#z z%Wv?9k}-b8n~|%*m(qs@+5K)s^!@qlF>U)slS@%x$7{Clqv zEjK~pgtzFL5y%g*IjsqpGl8I0(of##o~O9TfGqhlKL^ z>=A+=@>N%49f`DL4km9R@%G&BXG%Ra3RkL6$#gCX$kTxvlazNsI#e7Lt1t+eHT>|tgL8K|~kWR*pj-@5!TdmzS3C`}S(CPY@& zgy$hOJcmnUM24#*lS{rN_E_G1Xk|#>AJ?Q#tZeuLr(}7zHFMUGR#>1nY1JDKVVRAH z^v8<~?x$o3pnL?$;MHEoAyNnXG*UQ_Mk?k+k_nPGH(|Q6;9u4CpYa2x(swMTWhkW9p}EH zvSy2dbZz1Xn@26Mj#zaTAnJ;x2sZ!@U#L&(PnH}iOVog7NA79XHsN-a{K~4Pu((lxM|p`xN(`z2znCs?^^47uDvDa`2r4^= zPjM}s3$L!t;h~A+>@&m}ty-aRfhCj+5nLp%7Oi5ty>FxwfoJ`q^z-SntTn>|ZQaX! zQVcO6*BV!=EmB#hKXk-u71kr z^#qf6TX`i?>2(%=tZ5mqioM?(k}peZ25YgnOYqv+QqzM5kP2Vd=={+4Xf$ySaa+%U z+x^VgV+`n1Z|FPyQx}L5bqRqNU9-2RuZzDuwmGzoD>D5AkDl-L-ybu+=RaFOn?y}m znq!n!k;`|6lS*81_xAL!5cZ`v!rOS~+)hfz3bj{t%l{uphCk zD}qF5M-(JQw3Frvy3B_*T8Y24c*R5(+Fz7?zr66t`%p>1>z1WOMBUH4eijlBnze47 zQ`(9aerwI=qK|_cEr#Wyx=k?%+`^lUR!%*Jm@Z@W8IF|9+um83hEz+qg~<3R?*orO zucPa0PHKWyLv~UqaPg8&(Xxo}wpmdzUSPU(l{X`HQ)=y?kTSSX@*j_j;X5GYWYGH- z=8l`uu%K`CMXAw>N(Q!Xli10h@0^&nd}imxyO~eqMKn&|?UBvB%wi$_aM8}Wb~e$F zFZFKY1u1tee9%1>KQ%W7#@}G;*Y6_w+j;|FZHaskell Security Advisory DBhttps://haskell.github.io/security-advisories/atom.xml2024-08-01T12:52:14ZHaskell Security Response Teamhttps://haskell.github.io/security-advisories/advisory/HSEC-2023-0007.htmlHSEC-2023-0007 - readFloat: memory exhaustion with large exponent2023-07-22T02:29:32Z<pre><code class="language-toml">[advisory] +id = &quot;HSEC-2023-0007&quot; +cwe = [1284, 789] +keywords = [&quot;toml&quot;, &quot;parser&quot;, &quot;dos&quot;] + +[[affected]] +package = &quot;base&quot; +cvss = &quot;CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H&quot; +[[affected.versions]] +# it was introduced earlier, but this is the earliest version on Hackage +introduced = &quot;3.0.3.1&quot; + +[[affected]] +package = &quot;toml-reader&quot; +cvss = &quot;CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H&quot; +[[affected.versions]] +introduced = &quot;0.1.0.0&quot; +fixed = &quot;0.2.0.0&quot; + +[[references]] +type = &quot;REPORT&quot; +url = &quot;https://gitlab.haskell.org/ghc/ghc/-/issues/23538&quot; +[[references]] +type = &quot;REPORT&quot; +url = &quot;https://github.com/brandonchinn178/toml-reader/issues/8&quot; +[[references]] +type = &quot;FIX&quot; +url = &quot;https://github.com/brandonchinn178/toml-reader/pull/9&quot; + +</code></pre> +<h1><code>readFloat</code>: memory exhaustion with large exponent</h1> +<p><code>Numeric.readFloat</code> takes time and memory linear in the size of the +number <em>denoted</em> by the input string. In particular, processing a +number expressed in scientific notation with a very large exponent +could cause a denial of service. The slowdown is observable on a +modern machine running GHC 9.4.4:</p> +<pre><code>ghci&gt; import qualified Numeric +ghci&gt; Numeric.readFloat &quot;1e1000000&quot; -- near instantaneous +[(Infinity,&quot;&quot;)] +ghci&gt; Numeric.readFloat &quot;1e10000000&quot; -- perceptible pause +[(Infinity,&quot;&quot;)] +ghci&gt; Numeric.readFloat &quot;1e100000000&quot; -- ~ 3 seconds +[(Infinity,&quot;&quot;)] +ghci&gt; Numeric.readFloat &quot;1e1000000000&quot; -- ~ 35 seconds +[(Infinity,&quot;&quot;)] +</code></pre> +<h2>In <em>base</em></h2> +<p><code>Numeric.readFloat</code> is defined for all <code>RealFrac a =&gt; a</code>:</p> +<pre><code class="language-haskell">readFloat :: RealFrac a =&gt; ReadS a +</code></pre> +<p>The <code>RealFrac</code> type class does not express any bounds on the size of +values representable in the types for which instances exist, so +bounds checking is not possible (in this <em>generic</em> function). +<code>readFloat</code> uses to <code>Text.Read.Lex.numberToRational</code> which, among +other things, calculates <code>10 ^ exponent</code>, which seems to take linear +time and memory.</p> +<p><strong>Mitigation:</strong> use <code>read</code>. The <code>Read</code> instances for <code>Float</code> and +<code>Double</code> perform bounds checks on the exponent, via +<code>Text.Read.Lex.numberToRangedRational</code>.</p> +<h2>In <em>toml-reader</em></h2> +<p>The issue was detected in <em>toml-reader</em> version 0.1.0.0, and +mitigated in version 0.2.0.0 by immediately returning <code>Infinity</code> +when the exponent is large enough that there's no reason to process +it.</p> +https://haskell.github.io/security-advisories/advisory/HSEC-2024-0003.htmlHSEC-2024-0003 - process: command injection via argument list on Windows2024-04-09T22:14:47Z<pre><code class="language-toml">[advisory] +id = &quot;HSEC-2024-0003&quot; +cwe = [150] +keywords = [&quot;windows&quot;] +aliases = [&quot;CVE-2024-3566&quot;, &quot;VU#123335&quot;] +related = [&quot;CVE-2024-1874&quot;, &quot;CVE-2024-24576&quot;, &quot;CVE-2024-22423&quot;] + +[[references]] +type = &quot;ARTICLE&quot; +url = &quot;https://flatt.tech/research/posts/batbadbut-you-cant-securely-execute-commands-on-windows/&quot; + +[[references]] +type = &quot;ADVISORY&quot; +url = &quot;https://kb.cert.org/vuls/id/123335&quot; + +[[references]] +type = &quot;FIX&quot; +url = &quot;https://github.com/haskell/process/commit/3c419f9eeedac024c9dccce544e5a6fb587179a5&quot; + +[[references]] +type = &quot;FIX&quot; +url = &quot;https://github.com/haskell/process/commit/951b02dd95559b1a26f2456bfb97cf740ea40934&quot; + +[[references]] +type = &quot;FIX&quot; +url = &quot;https://github.com/haskell/process/commit/5fc91f5f36ed4479be2b95f04f264bb78ac8089d&quot; + +[[affected]] +package = &quot;process&quot; +os = [&quot;mingw32&quot;] +cvss = &quot;CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H&quot; + +[[affected.versions]] +introduced = &quot;1.0.0.0&quot; +fixed = &quot;1.6.23.0&quot; +</code></pre> +<h1>process: command injection via argument list on Windows</h1> +<p>The <em>process</em> library on Windows is vulnerable to a command injection +vulnerability, via <code>cmd.exe</code>'s interpretation of arguments. Programs that +invoke batch files (<code>.bat</code>, <code>.cmd</code>) and pass arguments whose values are +affected by program inputs may be affected.</p> +<p>This issue was discovered in many programming languages' Windows process +execution behaviour. It was tracked by CERT/CC as <strong>VU#123335</strong> and a +coordinated disclosure was made on 2024-04-09 17:00 UTC.</p> +<p>A fix was released in <em>process-1.6.19.0</em>.</p> +<h2>Background</h2> +<p>Unlike POSIX systems, Windows does not have a mechanism for passing multiple +arguments.Command line parsing is up to individual programs.</p> +<p>The <em>process</em> library defines the <code>RawCommand</code> constructor for specifying an +executable and its arguments:</p> +<pre><code class="language-haskell">data CmdSpec + = ShellCommand String + | RawCommand FilePath [String] +</code></pre> +<p>On Windows, the <code>RawCommand</code> executable name and arguments are serialised into +a single <em>command line</em> string, with separate arguments quoted separately. +<em>process</em> then invokes the Windows <a href="https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa"><code>CreateProcess</code></a> +routine with this command line string is given as the <code>lpCommandLine</code> +argument.</p> +<h2>Issue</h2> +<p>When executing <code>.bat</code> or <code>.cmd</code> files, <a href="https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa"><code>CreateProcess</code></a> +implicitly spawns <code>cmd.exe</code>. The <code>System.Process</code> command line construction +does not escape characters with special meaning to <code>cmd.exe</code>. As a +consequence, a command injection vulnerability arises when the following +conditions are satisfied:</p> +<ul> +<li>Program running on Windows +</li> +<li>Program executes a <code>.bat</code> or <code>.cmd</code> file +</li> +<li>The argument values include or are influenced by program input +</li> +</ul> +<h2>Demonstration</h2> +<p>The following batch file, <code>test.bat</code>, merely prints the executable name the +first two arguments (as interpreted by <code>cmd.exe</code>):</p> +<pre><code>@ECHO OFF +ECHO 0: %0 +ECHO 1: %1 +ECHO 2: %2 +PAUSE +</code></pre> +<p>The following Haskell program executes <code>test.bat</code> with basic string arguments. +The output is as expected:</p> +<pre><code>λ&gt; readProcess &quot;test.bat&quot; [&quot;a&quot;,&quot;b&quot;] [] &gt;&gt;= putStrLn +0: &quot;test.bat&quot; +1: &quot;a&quot; +2: &quot;b&quot; +</code></pre> +<p>However, we can use a close quote and the <code>&amp;</code> character to induce <code>cmd.exe</code> to +execute a program named in the argument:</p> +<pre><code>λ&gt; readProcess &quot;test.bat&quot; [&quot;\&quot;&amp;calc.exe&quot;] [] &gt;&gt;= putStrLn +0: &quot;test.bat&quot; +1: &quot;\&quot; +2: +</code></pre> +<p>In addition to producing the above output, <code>calc.exe</code> is executed.</p> +<h2>Mitigation</h2> +<p>The lack of a general mechanism on Windows for safely conveying command line +arguments to programs increases the risk of this kind of security issue. The +fact that <code>cmd.exe</code> command line parsing is complex and poorly documented +exacerbates this issue, and also heightens the risk that the fix is +incomplete, or causes other issues.</p> +<p>If possible, avoid executing batch files where arguments include or are +influenced by untrusted program inputs. If it must be done, reject arguments +that include special characters including <code>&amp;</code> and <code>&quot;</code>.</p> +<h2>Fix versions</h2> +<p><em>process</em> was modified to perform additional escaping and quoting +when executing <code>.bat</code> and <code>.cmd</code> files on Windows (ignoring +character case). The behaviour is unchanged in all other cases.</p> +<p>The fix was released in <em><strong>process-1.6.19.0</strong></em>. The following GHC +releases were the first in their series to include a fixed version +of the <em>process</em> library:</p> +<ul> +<li><strong>GHC 9.10.1-alpha3</strong> (released 2024-04-15) +</li> +<li>GHC 9.8.x (<strong>no release with fix yet</strong>) +</li> +<li><strong>GHC 9.6.5</strong> (released 2024-04-16) +</li> +</ul> +<p>Such a change in semantics should normally result in a major version +bump. Because we expect very few (if any) users will be impacted by +the behavioural change, the GHC team made a pragmatic decision to +avoid the disruption that a major version bump would cause.</p> +<p>A follow-up fix was released in <em><strong>process-1.6.23.0</strong></em> to handle batch +scripts with paths ending in whitespace and periods and +unescaped <code>%</code> expansions.</p> +<h2>Acknowledgements</h2> +<p>Security researcher <strong>RyotaK</strong> discovered and responsibly disclosed +this vulnerability, coordinating the response across the many +affected langauges and ecosystems.</p> +<p>Ben Gamari commited and released the fix, which was based on a +proposal by Fraser Tweedale. Fraser also improved the +<code>System.Process</code> module documentation to better explain the Windows +semantics.</p> +<p>Security researcher <strong>Kainan Zhang</strong> (@4xpl0r3r) discovered and +responsibly disclosing the issue in the first fix and the Rust +Security Response WG coordinated the response.</p> +https://haskell.github.io/security-advisories/advisory/HSEC-2023-0014.htmlHSEC-2023-0014 - Arbitrary file write is possible when using PDF output or --extract-media with untrusted input2023-08-22T23:08:06Z<pre><code class="language-toml">[advisory] +id = &quot;HSEC-2023-0014&quot; +keywords = [&quot;file write&quot;] +aliases = [&quot;CVE-2023-35936&quot;, &quot;GHSA-xj5q-fv23-575g&quot;] +cwe = [20] + +[[references]] +type = &quot;REPORT&quot; +url = &quot;https://github.com/jgm/pandoc/security/advisories/GHSA-xj5q-fv23-575g&quot; + +[[affected]] +package = &quot;pandoc&quot; +cvss = &quot;CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:N/I:H/A:L&quot; + +[[affected.versions]] +introduced = &quot;1.13&quot; +fixed = &quot;3.1.4&quot; + +</code></pre> +<h1>Arbitrary file write is possible when using PDF output or --extract-media with untrusted input</h1> +<p>Pandoc is susceptible to an arbitrary file write vulnerability, which can be triggered by providing a specially crafted image element in the input when generating files using the --extract-media option or outputting to PDF format. This vulnerability allows an attacker to create or overwrite arbitrary files on the system (depending on the privileges of the process running pandoc).</p> +<p>This vulnerability only affects systems that (a) pass untrusted user input to pandoc and (b) allow pandoc to be used to produce a PDF or with the --extract-media option.</p> +<p>The vulnerability is patched in pandoc 3.1.4.</p> +https://haskell.github.io/security-advisories/advisory/HSEC-2023-0005.htmlHSEC-2023-0005 - tls-extra: certificate validation does not check Basic Constraints2023-07-19T13:29:39Z<pre><code class="language-toml">[advisory] +id = &quot;HSEC-2023-0005&quot; +cwe = [295] +keywords = [&quot;x509&quot;, &quot;pki&quot;, &quot;mitm&quot;, &quot;historical&quot;] +aliases = [&quot;CVE-2013-0243&quot;] + +[[affected]] +package = &quot;tls-extra&quot; +cvss = &quot;CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N&quot; + +[[affected.versions]] +introduced = &quot;0.1.0&quot; +fixed = &quot;0.4.6.1&quot; + +[[references]] +type = &quot;DISCUSSION&quot; +url = &quot;https://www.openwall.com/lists/oss-security/2013/01/30/6&quot; +[[references]] +type = &quot;REPORT&quot; +url = &quot;https://github.com/haskell-tls/hs-tls/issues/29&quot; +[[references]] +type = &quot;FIX&quot; +url = &quot;https://github.com/haskell-tls/hs-tls/commit/15885c0649ceabd2f4d2913df8ac6dc63d6b3b37&quot; +</code></pre> +<h1>tls-extra: certificate validation does not check Basic Constraints</h1> +<p><em>tls-extra</em> does not check the Basic Constraints extension of a +certificate in certificate chain processing. Any certificate is +treated as a CA certificate. As a consequence, anyone who has a +valid certificate can use it to sign another one (with an arbitrary +subject DN/domain name embedded into it) and have it accepted by +<em>tls</em>. This allows MITM attacks on TLS connections.</p> +https://haskell.github.io/security-advisories/advisory/HSEC-2023-0006.htmlHSEC-2023-0006 - x509-validation does not enforce pathLenConstraint2023-07-19T13:59:54Z<pre><code class="language-toml">[advisory] +id = &quot;HSEC-2023-0006&quot; +cwe = [295] +keywords = [&quot;x509&quot;, &quot;pki&quot;, &quot;historical&quot;] + +[[affected]] +package = &quot;x509-validation&quot; +cvss = &quot;CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:N&quot; + +[[affected.versions]] +introduced = &quot;1.4.0&quot; +fixed = &quot;1.4.8&quot; + +[[references]] +type = &quot;FIX&quot; +url = &quot;https://github.com/haskell-tls/hs-certificate/commit/06d15dbbc53739314760d8504ca764000770e46e&quot; +</code></pre> +<h1>x509-validation does not enforce pathLenConstraint</h1> +<p><em>x509-validation</em> prior to version 1.4.8 did not enforce the +pathLenConstraint value. Constrained CAs could accidentally (or +deliberately) issue CAs below the maximum depth and +<em>x509-validation</em> would accept certificates issued by the +unauthorised intermediate CAs.</p> +https://haskell.github.io/security-advisories/advisory/HSEC-2023-0015.htmlHSEC-2023-0015 - cabal-install uses expired key policies2023-11-07T03:57:00Z<pre><code class="language-toml">[advisory] +id = &quot;HSEC-2023-0015&quot; +cwe = [672] +keywords = [&quot;hackage&quot;, &quot;mitm&quot;, &quot;supply-chain&quot;] + +[[affected]] +package = &quot;cabal-install&quot; +cvss = &quot;CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N&quot; +[[affected.versions]] +introduced = &quot;1.24.0.0&quot; +fixed = &quot;3.10.2.0&quot; + +[[references]] +type = &quot;REPORT&quot; +url = &quot;https://github.com/haskell/cabal/issues/8918#issuecomment-1521096581&quot; +[[references]] +type = &quot;FIX&quot; +url = &quot;https://github.com/haskell/cabal/commit/dcfdc9cffd74cade4e8cf3df37c5993413ffd30f&quot; +</code></pre> +<h1>cabal-install uses expired key policies</h1> +<p>A problem was recently discovered in <code>cabal-install</code>'s +implementation of the Hackage Security protocol that would allow an +attacker who was in possession of a revoked private key and who +could perform a man-in-the-middle attack against Hackage to use the +revoked key to deliver malicious packages. At this time, this is +only a theoretical attack - no keys have been revoked. Release +3.10.2.0 of <code>cabal-install</code> contains a fix for this bug, and we have +contacted distributors of older versions (such as Linux +distributions) with a patch that they can apply.</p> +<h2>Background</h2> +<p>Hackage Security is an implementation of <a href="https://theupdateframework.io/">The Update Framework</a>, +which is a design for a package repository that allows untrusted +mirrors without undermining software supply-chain security. In +particular, Hackage Security cryptographically guarantees the +following properties:</p> +<ul> +<li> +<p>Mirrors of Hackage cannot change the contents of packages. This +prevents the insertion of malicious code.</p> +</li> +<li> +<p>Mirrors cannot omit newer packages for more than a few days +without clients noticing. This ensures both that mirrors cannot +maliciously deny security updates, and that mistakes in their +configuration will be noticed.</p> +</li> +</ul> +<p>Hackage has a <a href="https://hackage.haskell.org/root.json">key policy file</a> that delegates authority to a +number of private keys for various purposes. Most of the keys are +kept securely offline by trusted community members who annually +re-sign the various files to indicate that they still have +confidence in Hackage's policies. However, to prevent clients from +being denied updates, Hackage has an automated process that +periodically re-signs a timestamp file. This signature has a short +expiry. Additionally, a snapshot file contains signed hashes of the +Hackage index that is updated on each package upload. The timestamp +and snapshot private keys are held in memory on the Hackage server. +These are called the operational keys. If an operational key is ever +compromised, then it will be revoked by having the Hackage root +keyholders sign a new key policy file. To prevent replay attacks, +clients that connect to Hackage after this update will reject older +policy files, based on a monotonically increasing file version +number.</p> +<p>If a client has not yet received the updated policy file (for +example, because they have a fresh install of <code>cabal-install</code> or +because they have not run <code>cabal update</code> in some time), the built-in +expiration date in the file limits the window of exposure in which +the revoked operational keys would be expected. As long as the root +keys have not been compromised, the compromised operational keys can +only be used until the policy file expires. In addition to +compromising a Hackage operational key, an attacker would +additionally need to either compromise a Hackage mirror or perform a +man-in-the-middle attack against the target in order to serve a +malicious or obsolete package index.</p> +<h2>The Issue</h2> +<p>A bug in <code>cabal-install</code> caused it to skip the verification of the +key policy file's expiration timestamp. This means that users of +older, unpatched versions of <code>cabal-install</code> could be vulnerable to +a malicious mirror or man-in-the-middle attack against Hackage if +they have not connected to Hackage in a long time, even after the +policy file has expired.</p> +<p>We do not believe that it has been possible to exploit this +vulnerability, because no operational keys have been revoked. +However, in case key revocation occurs, we strongly advise all users +of <code>cabal-install</code> to ensure that they have version 3.10.2.0 or +newer, which contain the fix.</p> +https://haskell.github.io/security-advisories/advisory/HSEC-2023-0003.htmlHSEC-2023-0003 - code injection in xmonad-contrib2023-06-19T21:35:14Z<pre><code class="language-toml">[advisory] +id = &quot;HSEC-2023-0003&quot; +cwe = [94] +keywords = [&quot;code&quot;, &quot;injection&quot;, &quot;historical&quot;] +aliases = [&quot;CVE-2013-1436&quot;] + +[[affected]] +package = &quot;xmonad-contrib&quot; +cvss = &quot;AV:N/AC:L/Au:N/C:P/I:P/A:P&quot; +[[affected.versions]] +introduced = &quot;0.5&quot; +fixed = &quot;0.11.2&quot; + +[[references]] +type = &quot;ADVISORY&quot; +url = &quot;https://security.gentoo.org/glsa/201405-28&quot; +[[references]] +type = &quot;DISCUSSION&quot; +url = &quot;http://www.openwall.com/lists/oss-security/2013/07/26/5&quot; +[[references]] +type = &quot;FIX&quot; +url = &quot;https://github.com/xmonad/xmonad-contrib/commit/d3b2a01e3d01ac628e7a3139dd55becbfa37cf51&quot; +</code></pre> +<h1>code injection in <em>xmonad-contrib</em></h1> +<p>The <code>XMonad.Hooks.DynamicLog</code> module in <em>xmonad-contrib</em> before +<strong>0.11.2</strong> allows remote attackers to execute arbitrary commands via a +web page title, which activates the commands when the user clicks on +the xmobar window title, as demonstrated using an action tag.</p> +https://haskell.github.io/security-advisories/advisory/HSEC-2024-0002.htmlHSEC-2024-0002 - out-of-bounds write when there are many bzip2 selectors2024-03-11T12:26:51Z<pre><code class="language-toml">[advisory] +id = &quot;HSEC-2024-0002&quot; +cwe = [787] +keywords = [&quot;corruption&quot;, &quot;vendored-code&quot;, &quot;language-c&quot;] +aliases = [&quot;CVE-2019-12900&quot;] + +[[references]] +type = &quot;DISCUSSION&quot; +url = &quot;https://gnu.wildebeest.org/blog/mjw/2019/08/02/bzip2-and-the-cve-that-wasnt/&quot; + +[[references]] +type = &quot;DISCUSSION&quot; +url = &quot;http://scary.beasts.org/security/CESA-2008-005.html&quot; + +[[references]] +type = &quot;ADVISORY&quot; +url = &quot;https://access.redhat.com/security/cve/cve-2019-12900&quot; + +[[references]] +type = &quot;FIX&quot; +url = &quot;https://sourceware.org/git/?p=bzip2.git;a=commit;h=7ed62bfb46e87a9e878712603469440e6882b184&quot; + +[[affected]] +package = &quot;bzlib&quot; +cvss = &quot;CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N&quot; + +[[affected.versions]] +introduced = &quot;0.4&quot; +fixed = &quot;0.5.2.0&quot; + +[[affected]] +package = &quot;bz2&quot; +cvss = &quot;CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N&quot; + +[[affected.versions]] +introduced = &quot;0.1.0.0&quot; +fixed = &quot;1.0.1.1&quot; + +[[affected]] +package = &quot;bzlib-conduit&quot; +cvss = &quot;CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N&quot; + +[[affected.versions]] +introduced = &quot;0.1.0.0&quot; +fixed = &quot;0.3.0.3&quot; +</code></pre> +<h1>out-of-bounds write when there are many bzip2 selectors</h1> +<p>A malicious bzip2 payload may produce a memory corruption +resulting in a denial of service and/or remote code execution. +Network services or command line utilities decompressing +untrusted bzip2 payloads are affected.</p> +<p>Note that the exploitation of this bug relies on an undefined +behavior that appears to be handled safely by current compilers.</p> +<p>The Haskell libraires are vulnerable when they are built using +the bundled C library source code, which is the default +in most cases.</p> +https://haskell.github.io/security-advisories/advisory/HSEC-2024-0001.htmlHSEC-2024-0001 - Reflected XSS vulnerability in keter2024-02-27T17:06:24Z<pre><code class="language-toml">[advisory] +id = &quot;HSEC-2024-0001&quot; +cwe = [79] +keywords = [&quot;http&quot;, &quot;xss&quot;, &quot;rxss&quot;, &quot;historical&quot;] + +[[references]] +type = &quot;FIX&quot; +url = &quot;https://github.com/snoyberg/keter/pull/246&quot; + +[[affected]] +package = &quot;keter&quot; +cvss = &quot;CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N&quot; +declarations.&quot;Keter.Proxy.toResponse&quot; = &quot;&gt;= 0.3.4 &amp;&amp; &lt; 1.0.1&quot; +declarations.&quot;Keter.Proxy.unknownHostResponse&quot; = &quot;&gt;= 1.0.1 &amp;&amp; &lt; 1.8.4&quot; + +[[affected.versions]] +introduced = &quot;0.3.4&quot; +fixed = &quot;1.8.4&quot; +</code></pre> +<h1>Reflected XSS vulnerability in keter</h1> +<p>Keter is an app-server/reverse-proxy often used with webapps build on Yesod web-framework.</p> +<p>In the logic handling VHost dispatch, Keter was echoing back <code>Host</code> header value, unescaped, +as part of an HTML error page. This constitutes a reflected-XSS vulnerability. Although +not readily exploitable directly from a browser (where <code>Host</code> header can't generally assume +arbitrary values), it may become such in presence of further weaknesses in components +upstream of Keter in the http proxying chain. Therefore, AC:High in CVSS evaluation.</p> +https://haskell.github.io/security-advisories/advisory/HSEC-2023-0008.htmlHSEC-2023-0008 - Stored XSS in hledger-web2023-07-22T12:23:10Z<pre><code class="language-toml">[advisory] +id = &quot;HSEC-2023-0008&quot; +cwe = [87] +keywords = [&quot;web&quot;, &quot;xss&quot;, &quot;historical&quot;] +aliases = [&quot;CVE-2021-46888&quot;] + +[[affected]] +package = &quot;hledger-web&quot; +cvss = &quot;CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N&quot; +[[affected.versions]] +introduced = &quot;0.24&quot; +fixed = &quot;1.23&quot; + +[[references]] +type = &quot;REPORT&quot; +url = &quot;https://github.com/simonmichael/hledger/issues/1525&quot; +[[references]] +type = &quot;INTRODUCED&quot; +url = &quot;https://github.com/simonmichael/hledger/commit/ec51d28839b2910eea360b1b8c72904b51cf7821&quot; +[[references]] +type = &quot;EVIDENCE&quot; +url = &quot;https://www.youtube.com/watch?v=QnRO-VkfIic&quot; +[[references]] +type = &quot;FIX&quot; +url = &quot;https://github.com/simonmichael/hledger/pull/1663&quot; + +</code></pre> +<h1>Stored XSS in <em>hledger-web</em></h1> +<p>An issue was discovered in <em>hledger-web</em> &lt; 1.23. A Stored Cross-Site +Scripting (XSS) vulnerability exists in <code>toBloodhoundJson</code> that +allows an attacker to execute JavaScript by encoding user-controlled +values in a payload with base64 and parsing them with the <code>atob</code> +function.</p> +<p><em>hledger-web</em> forms sanitise obvious JavaScript, but not obfuscated +JavaScript (see <a href="https://owasp.org/www-community/xss-filter-evasion-cheatsheet">OWASP Filter Evasion Cheat Sheet</a>). +This means <em>hledger-web</em> instances, especially anonymously-writable +ones like <code>demo.hledger.org</code>, could be loaded with malicious +JavaScript to be executed by subsequent visitors.</p> +<p>Reported by Gaspard Baye and Hamidullah Muslih. Fix by Arsen +Arsenović.</p> +https://haskell.github.io/security-advisories/advisory/HSEC-2023-0001.htmlHSEC-2023-0001 - Hash flooding vulnerability in aeson2023-06-13T09:03:52Z<pre><code class="language-toml">[advisory] +id = &quot;HSEC-2023-0001&quot; +cwe = [328, 400] +keywords = [&quot;json&quot;, &quot;dos&quot;, &quot;historical&quot;] +aliases = [&quot;CVE-2022-3433&quot;] + +[[affected]] +package = &quot;aeson&quot; +cvss = &quot;CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H&quot; + +[[affected.versions]] +introduced = &quot;0.4.0.0&quot; +fixed = &quot;2.0.1.0&quot; + +[[references]] +type = &quot;ARTICLE&quot; +url = &quot;https://cs-syd.eu/posts/2021-09-11-json-vulnerability&quot; +[[references]] +type = &quot;ARTICLE&quot; +url = &quot;https://frasertweedale.github.io/blog-fp/posts/2021-10-12-aeson-hash-flooding-protection.html&quot; +[[references]] +type = &quot;DISCUSSION&quot; +url = &quot;https://github.com/haskell/aeson/issues/864&quot; +</code></pre> +<h1>Hash flooding vulnerability in aeson</h1> +<p><em>aeson</em> was vulnerable to hash flooding (a.k.a. hash DoS). The +issue is a consequence of the HashMap implementation from +<em>unordered-containers</em>. It results in a denial of service through +CPU consumption. This technique has been used in real-world attacks +against a variety of languages, libraries and frameworks over the +years.</p> +https://haskell.github.io/security-advisories/advisory/HSEC-2023-0004.htmlHSEC-2023-0004 - xml-conduit unbounded entity expansion2023-07-18T14:37:41Z<pre><code class="language-toml">[advisory] +id = &quot;HSEC-2023-0004&quot; +cwe = [776] +keywords = [&quot;xml&quot;, &quot;dos&quot;, &quot;historical&quot;] +aliases = [&quot;CVE-2021-4249&quot;, &quot;VDB-216204&quot;] + +[[affected]] +package = &quot;xml-conduit&quot; +cvss = &quot;CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H&quot; + +[[affected.versions]] +introduced = &quot;0.5.0&quot; +fixed = &quot;1.9.1.0&quot; + +[[references]] +type = &quot;FIX&quot; +url = &quot;https://github.com/snoyberg/xml/pull/161&quot; +[[references]] +type = &quot;FIX&quot; +url = &quot;https://github.com/snoyberg/xml/commit/4be1021791dcdee8b164d239433a2043dc0939ea&quot; +</code></pre> +<h1>xml-conduit unbounded entity expansion</h1> +<p>A vulnerability was found in <em>xml-conduit</em>. It has been classified +as problematic. Affected is an unknown function of the file +<code>xml-conduit/src/Text/XML/Stream/Parse.hs</code> of the component DOCTYPE +Entity Expansion Handler. The manipulation leads to infinite loop. +It is possible to launch the attack remotely. Upgrading to version +1.9.1.0 is able to address this issue. The name of the patch is +<code>4be1021791dcdee8b164d239433a2043dc0939ea</code>. It is recommended to +upgrade the affected component.</p> +https://haskell.github.io/security-advisories/advisory/HSEC-2024-0009.htmlHSEC-2024-0009 - Public key confusion in third-party blocks2024-08-01T12:52:14Z<pre><code class="language-toml">[advisory] +id = &quot;HSEC-2024-0009&quot; +keywords = [&quot;biscuit&quot;] +aliases = [&quot;CVE-2024-41949&quot;, &quot;GHSA-rgqv-mwc3-c78m&quot;, &quot;GHSA-47cq-pc2v-3rmp&quot;] + +[[references]] +type = &quot;ADVISORY&quot; +url = &quot;https://github.com/biscuit-auth/biscuit-haskell/security/advisories/GHSA-47cq-pc2v-3rmp&quot; +[[references]] +type = &quot;FIX&quot; +url = &quot;https://github.com/biscuit-auth/biscuit-haskell/pull/93&quot; + +[[affected]] +package = &quot;biscuit-haskell&quot; +cvss = &quot;CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:N/I:L/A:N&quot; + +[[affected.versions]] +introduced = &quot;0.3.0.0&quot; +fixed = &quot;0.4.0.0&quot; +</code></pre> +<h1>Public key confusion in third-party blocks</h1> +<p>Third-party blocks can be generated without transferring the whole token to the third-party authority. Instead, a <code>ThirdPartyBlock</code> request can be sent, providing only the necessary info to generate a third-party block and to sign it:</p> +<ul> +<li>the public key of the previous block (used in the signature); +</li> +<li>the public keys part of the token symbol table (for public key interning in datalog expressions). +</li> +</ul> +<p>A third-party block request forged by a malicious user can trick the third-party authority into generating datalog trusting the wrong keypair.</p> +https://haskell.github.io/security-advisories/advisory/HSEC-2023-0002.htmlHSEC-2023-0002 - Improper Verification of Cryptographic Signature2023-06-19T21:35:33Z<pre><code class="language-toml">[advisory] +id = &quot;HSEC-2023-0002&quot; +cwe = [347] +keywords = [&quot;crypto&quot;, &quot;historical&quot;] +aliases = [&quot;CVE-2022-31053&quot;] +related = [&quot;GHSA-75rw-34q6-72cr&quot;] + +[[affected]] +package = &quot;biscuit-haskell&quot; +cvss = &quot;CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H&quot; +[[affected.versions]] +introduced = &quot;0.1.0.0&quot; +fixed = &quot;0.2.0.0&quot; + +[[references]] +type = &quot;REPORT&quot; +url = &quot;https://eprint.iacr.org/2020/1484&quot; +[[references]] +type = &quot;ADVISORY&quot; +url = &quot;https://github.com/biscuit-auth/biscuit/security/advisories/GHSA-75rw-34q6-72cr&quot; + +</code></pre> +<h1>Improper Verification of Cryptographic Signature</h1> +<p>The Biscuit specification version 1 contains a vulnerable algorithm that allows +malicious actors to forge valid Γ-signatures. Such an attack would allow an +attacker to create a token with any access level. The version 2 of the +specification mandates a different algorithm than gamma signatures and as such +is not affected by this vulnerability.</p> +https://haskell.github.io/security-advisories/advisory/HSEC-2023-0011.htmlHSEC-2023-0011 - git-annex GPG decryption attack via compromised remote2023-07-25T13:25:42Z<pre><code class="language-toml">[advisory] +id = &quot;HSEC-2023-0011&quot; +cwe = [200] +keywords = [&quot;exfiltration&quot;, &quot;pgp&quot;, &quot;historical&quot;] +aliases = [&quot;CVE-2018-10859&quot;] +related = [&quot;HSEC-2023-0010&quot;, &quot;CVE-2018-10857&quot;] + +[[affected]] +package = &quot;git-annex&quot; +cvss = &quot;CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N&quot; +[[affected.versions]] +introduced = &quot;0.20110417&quot; +fixed = &quot;6.20180626&quot; + +[[references]] +type = &quot;ADVISORY&quot; +url = &quot;https://git-annex.branchable.com/security/CVE-2018-10857_and_CVE-2018-10859/&quot; +</code></pre> +<h1><em>git-annex</em> GPG decryption attack via compromised remote</h1> +<p>A malicious server for a special remote could trick <code>git-annex</code> into +decrypting a file that was encrypted to the user's GPG key. This +attack could be used to expose encrypted data that was never stored +in <em>git-annex</em>. Daniel Dent discovered this attack in collaboration +with Joey Hess.</p> +<p>To perform this attack the attacker needs control of a server +hosting an <em>encrypted</em> special remote used by the victim's +<em>git-annex</em> repository. The attacker uses <code>git annex addurl --relaxed</code> with an innocuous URL, and waits for the user's +<code>git-annex</code> to download it, and upload an (encrypted) copy to the +special remote they also control. At some later point, when the +user downloads the content from the special remote, the attacker +instead sends them the content of the GPG-encrypted file that they +wish to have decrypted in its place (which may have been exfiltrated +from the victim's system via the attack described in +<strong>HSEC-2023-0010</strong> / <strong>CVE-2018-10857</strong>, or acquired by other +means). Finally, the attacker drops their own copy of the original +innocuous URL, and waits for the victim <code>git-annex</code> to send them the +accidentially decrypted file.</p> +<p>The issue was fixed by making <code>git-annex</code> refuse to download +encrypted content from special remotes, unless it knows the hash of +the expected content. When the attacker provides some other +GPG-encrypted content, it will fail the hash check and be discarded.</p> +https://haskell.github.io/security-advisories/advisory/HSEC-2023-0009.htmlHSEC-2023-0009 - git-annex command injection via malicious SSH hostname2023-07-25T13:25:42Z<pre><code class="language-toml">[advisory] +id = &quot;HSEC-2023-0009&quot; +cwe = [20, 78] +keywords = [&quot;ssh&quot;, &quot;command-injection&quot;, &quot;historical&quot;] +aliases = [&quot;CVE-2017-12976&quot;] +related = [&quot;CVE-2017-9800&quot;, &quot;CVE-2017-12836&quot;, &quot;CVE-2017-1000116&quot;, &quot;CVE-2017-1000117&quot;] + +[[affected]] +package = &quot;git-annex&quot; +cvss = &quot;CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H&quot; +[[affected.versions]] +introduced = &quot;0.1&quot; +fixed = &quot;6.20170818&quot; + +[[references]] +type = &quot;ADVISORY&quot; +url = &quot;https://git-annex.branchable.com/security/CVE-2017-12976/&quot; +[[references]] +type = &quot;FIX&quot; +url = &quot;http://source.git-annex.branchable.com/?p=source.git;a=commitdiff;h=df11e54788b254efebb4898b474de11ae8d3b471&quot; +</code></pre> +<h1><em>git-annex</em> command injection via malicious SSH hostname</h1> +<p><em>git-annex</em> was vulnerable to the same class of security hole as +git's <strong>CVE-2017-1000117</strong>. In several cases, <code>git-annex</code> parses a +repository URL, and uses it to generate a <code>ssh</code> command, with the +hostname to ssh to coming from the URL. If the hostname it parses is +something like <code>-eProxyCommand=evil</code>, this could result in arbitrary +local code execution.</p> +<p>Some details of URL parsing may prevent the exploit working in some +cases.</p> +<p>Exploiting this would involve the attacker tricking the victim into +adding a remote something like <code>ssh://-eProxyCommand=evil/blah</code>.</p> +<p>One possible avenue for an attacker that avoids exposing the URL to +the user is to use <code>initremote</code> with an SSH remote, so embedding the +URL in the <em>git-annex</em> branch. Then the victim would enable it with +<code>enableremote</code>.</p> +<p>This was fixed in version <strong>6.20170818</strong>. Now there's a <code>SshHost</code> +type that is not allowed to start with a dash, and every invocation +of <code>git-annex</code> uses a function that takes a <code>SshHost</code>.</p> +https://haskell.github.io/security-advisories/advisory/HSEC-2023-0013.htmlHSEC-2023-0013 - git-annex plaintext storage of embedded credentials on encrypted remotes2023-07-25T13:25:42Z<pre><code class="language-toml">[advisory] +id = &quot;HSEC-2023-0013&quot; +cwe = [312] +keywords = [&quot;historical&quot;] +aliases = [&quot;CVE-2014-6274&quot;] + +[[affected]] +package = &quot;git-annex&quot; +cvss = &quot;CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H&quot; +[[affected.versions]] +introduced = &quot;0.20110401&quot; +fixed = &quot;5.20140919&quot; + +[[references]] +type = &quot;ADVISORY&quot; +url = &quot;https://git-annex.branchable.com/security/CVE-2014-6274/&quot; +[[references]] +type = &quot;ARTICLE&quot; +url = &quot;https://git-annex.branchable.com/upgrades/insecure_embedded_creds/&quot; +</code></pre> +<h1><em>git-annex</em> plaintext storage of embedded credentials on encrypted remotes</h1> +<p><em>git-annex</em> had a bug in the <strong>S3</strong> and <strong>Glacier</strong> remotes where if +<code>embedcreds=yes</code> was set, and the remote used <code>encryption=pubkey</code> or +<code>encryption=hybrid</code>, the embedded AWS credentials were stored in the +Git repository in (effectively) plaintext, not encrypted as they +were supposed to be.</p> +<p>That means that anyone who gets a copy of the Git repository can +extract the AWS credentials from it. Which would be bad.</p> +<p>A remote with this problem cannot be enabled using <code>git annex enableremote</code>. Old versions of <em>git-annex</em> will fail with a GPG +error; the current version will fail with a pointer to this web +page.</p> +<h2>Remediation</h2> +<p>If your repository has this problem, chose from one of these +approaches to deal with it:</p> +<ol> +<li> +<p>Change your AWS credentials, so the ones stored in the clear in +git won't be used.</p> +<p>After changing the credentials, make sure you have a fixed +version of git-annex, and you can then re-embed the new creds +into the repository, encrypted this time, by setting the +<code>AWS_SECRET_ACCESS_KEY</code> and <code>AWS_ACCESS_KEY_ID</code> environment +variables, and running <code>git annex enableremote $remotename embedcreds=yes</code>.</p> +</li> +<li> +<p>Fix the problem and then remove the history of the <em>git-annex</em> +branch of the repository.</p> +<p>Make sure you have a fixed version of <em>git-annex</em>, and force +<em>git-annex</em> to rewrite the embedded creds, with encryption this +time, by setting by setting the <code>AWS_SECRET_ACCESS_KEY</code> and +<code>AWS_ACCESS_KEY_ID</code> environment variables, and running <code>git annex enableremote $remotename embedcreds=yes</code>.</p> +<p>Then, to get rid of old versions of the <em>git-annex</em> branch that +still contains the creds in cleartext, you can use <code>git annex forget</code>; note that it will remove other historical data too.</p> +<p>Keep in mind that this will not necessarily delete data from +clones you do not control.</p> +</li> +<li> +<p>If you're sure that you're the only one who has access to the +repository, you could decide to leave it as-is. It's no more +insecure than if you had used <code>encryption=shared</code> in the first +place when setting it up.</p> +</li> +</ol> +https://haskell.github.io/security-advisories/advisory/HSEC-2023-0010.htmlHSEC-2023-0010 - git-annex private data exfiltration to compromised remote2023-07-25T13:25:42Z<pre><code class="language-toml">[advisory] +id = &quot;HSEC-2023-0010&quot; +cwe = [200, 610] +keywords = [&quot;exfiltration&quot;, &quot;historical&quot;] +aliases = [&quot;CVE-2018-10857&quot;] + +[[affected]] +package = &quot;git-annex&quot; +cvss = &quot;CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N&quot; +[[affected.versions]] +introduced = &quot;0.1&quot; +fixed = &quot;6.20180626&quot; + +[[references]] +type = &quot;ADVISORY&quot; +url = &quot;https://git-annex.branchable.com/security/CVE-2018-10857_and_CVE-2018-10859/&quot; +</code></pre> +<h1><em>git-annex</em> private data exfiltration to compromised remote</h1> +<p>Some uses of git-annex were vulnerable to a private data exposure +and exfiltration attack. It could expose the content of files +located outside the <em>git-annex</em> repository, or content from a +private web server on localhost or the LAN. Joey Hess discovered +this attack.</p> +<p>To perform this attack, the attacker needs to have control over one +of the remotes of the victim's <em>git-annex</em> repository. For example, +they may provide a public <em>git-annex</em> repository that the victim +clones. Or, equivalantly, the attacker could have read access to the +victim's <em>git-annex</em> repository or a repository it pushes to, and +some channel to get commits into it (e.g. pull requests).</p> +<p>These exploits are most likely to succeed when the victim is running +the <code>git-annex</code> assistant, or is periodically running <code>git annex sync --content</code>.</p> +<p>To perform the attack the attacker runs <code>git-annex addurl --relaxed file:///etc/passwd</code> and commits this to the repository in some out +of the way place. After the victim's git repository receives that +change, <code>git-annex</code> follows the attacker-provided URL to the private +data, which it stores in the <em>git-annex</em> repository. From there it +transfers the content to the remote <em>git-annex</em> repository that the +attacker has access to.</p> +<p>As well as <code>file:///</code> URLs, the attacker can use URLs to private web +servers. The URL can also be one that the attacker controls, that +redirects to a URL that is accessible to the victim system (and not +necessarily the compromised remote).</p> +<h2>Fix</h2> +<p>The issue was fixed by making <code>git-annex</code> refuse to follow +<code>file:///</code> urls and URLs pointing to private/local IP addresses by +default. Two new configuration settings, +<code>annex.security.allowed-url-schemes</code> and +<code>annex.security.allowed-ip-addresses</code>, can relax this security +policy, and are intended for cases where the <em>git-annex</em> repository +is kept private and so the attack does not apply.</p> +<h2>Impact on external special remotes</h2> +<p>One variant of this issue can exploit a vulnerable external special +remote, and could not be prevented by <code>git-annex</code>. (<code>git-annex</code>'s +own built-in special remotes are not vulnerable to this attack.)</p> +<p>In this attack variant, the attacker guesses the hash of a file +stored on the victim's private web server, and adds it to the +<code>git-annex</code> repository. The attacker also has control of the server +hosting an encrypted special remote used by the victim's <em>git-annex</em> +repository. They cause that server to redirect to the victim's web +server. This allows the attacker to verify if the victim's web +server contains a file that the attacker already knows the content +of, assuming they can guess the URL to it.</p> +<p>Developers of external special remotes are encouraged to prevent +this attack by not following such HTTP redirects.</p> +https://haskell.github.io/security-advisories/advisory/HSEC-2023-0012.htmlHSEC-2023-0012 - git-annex checksum exposure to encrypted special remotes2023-07-25T13:25:42Z<pre><code class="language-toml">[advisory] +id = &quot;HSEC-2023-0012&quot; +cwe = [200] +keywords = [&quot;historical&quot;] + +[[affected]] +package = &quot;git-annex&quot; +cvss = &quot;CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N&quot; +[[affected.versions]] +introduced = &quot;0.20110417&quot; +fixed = &quot;6.20160419&quot; + +[[references]] +type = &quot;ADVISORY&quot; +url = &quot;https://git-annex.branchable.com/security/checksum_exposure_to_encrypted_special_remotes/&quot; +[[references]] +type = &quot;FIX&quot; +url = &quot;http://source.git-annex.branchable.com/?p=source.git;a=commitdiff;h=b890f3a53d936b5e40aa9acc5876cb98f18b9657&quot; +</code></pre> +<h1><em>git-annex</em> checksum exposure to encrypted special remotes</h1> +<p>A bug exposed the checksum of annexed files to encrypted special +remotes, which are not supposed to have access to the checksum of +the un-encrypted file. This only occurred when resuming uploads to +the encrypted special remote, so it is considered a low-severity +security hole.</p> +<p>For details, see commit <code>b890f3a53d936b5e40aa9acc5876cb98f18b9657</code>.</p> +<p>No CVE was assigned for this issue.</p> +<p>Fixed in <em>git-annex-6.20160419</em>.</p> + \ No newline at end of file diff --git a/by-dates.html b/by-dates.html new file mode 100644 index 00000000..1294d173 --- /dev/null +++ b/by-dates.html @@ -0,0 +1 @@ +Haskell Security advisories

Advisories list

The Haskell Security Advisory Database is a repository of security advisories filed against packages published via Hackage.

It is generated from Haskell Security Advisory Database. Feel free to report new or historic security issues.

#Package(s)Summary
HSEC-2024-0009biscuit-haskellPublic key confusion in third-party blocks
HSEC-2024-0003processprocess: command injection via argument list on Windows
HSEC-2024-0002bzlib,bz2,bzlib-conduitout-of-bounds write when there are many bzip2 selectors
HSEC-2024-0001keterReflected XSS vulnerability in keter
HSEC-2023-0015cabal-installcabal-install uses expired key policies
HSEC-2023-0014pandocArbitrary file write is possible when using PDF output or --extract-media with untrusted input
HSEC-2023-0013git-annexgit-annex plaintext storage of embedded credentials on encrypted remotes
HSEC-2023-0012git-annexgit-annex checksum exposure to encrypted special remotes
HSEC-2023-0011git-annexgit-annex GPG decryption attack via compromised remote
HSEC-2023-0010git-annexgit-annex private data exfiltration to compromised remote
HSEC-2023-0009git-annexgit-annex command injection via malicious SSH hostname
HSEC-2023-0008hledger-webStored XSS in hledger-web
HSEC-2023-0007base,toml-readerreadFloat: memory exhaustion with large exponent
HSEC-2023-0006x509-validationx509-validation does not enforce pathLenConstraint
HSEC-2023-0005tls-extratls-extra: certificate validation does not check Basic Constraints
HSEC-2023-0004xml-conduitxml-conduit unbounded entity expansion
HSEC-2023-0003xmonad-contribcode injection in xmonad-contrib
HSEC-2023-0002biscuit-haskellImproper Verification of Cryptographic Signature
HSEC-2023-0001aesonHash flooding vulnerability in aeson
\ No newline at end of file diff --git a/by-packages.html b/by-packages.html new file mode 100644 index 00000000..85b92cce --- /dev/null +++ b/by-packages.html @@ -0,0 +1 @@ +Haskell Security advisories

Advisories list

The Haskell Security Advisory Database is a repository of security advisories filed against packages published via Hackage.

It is generated from Haskell Security Advisory Database. Feel free to report new or historic security issues.

aeson

#IntroducedFixedSummary
HSEC-2023-00010.4.0.02.0.1.0Hash flooding vulnerability in aeson

base

#IntroducedFixedSummary
HSEC-2023-00073.0.3.1readFloat: memory exhaustion with large exponent

biscuit-haskell

#IntroducedFixedSummary
HSEC-2024-00090.3.0.00.4.0.0Public key confusion in third-party blocks
HSEC-2023-00020.1.0.00.2.0.0Improper Verification of Cryptographic Signature

bz2

#IntroducedFixedSummary
HSEC-2024-00020.1.0.01.0.1.1out-of-bounds write when there are many bzip2 selectors

bzlib

#IntroducedFixedSummary
HSEC-2024-00020.40.5.2.0out-of-bounds write when there are many bzip2 selectors

bzlib-conduit

#IntroducedFixedSummary
HSEC-2024-00020.1.0.00.3.0.3out-of-bounds write when there are many bzip2 selectors

cabal-install

#IntroducedFixedSummary
HSEC-2023-00151.24.0.03.10.2.0cabal-install uses expired key policies

git-annex

#IntroducedFixedSummary
HSEC-2023-00130.201104015.20140919git-annex plaintext storage of embedded credentials on encrypted remotes
HSEC-2023-00120.201104176.20160419git-annex checksum exposure to encrypted special remotes
HSEC-2023-00110.201104176.20180626git-annex GPG decryption attack via compromised remote
HSEC-2023-00100.16.20180626git-annex private data exfiltration to compromised remote
HSEC-2023-00090.16.20170818git-annex command injection via malicious SSH hostname

hledger-web

#IntroducedFixedSummary
HSEC-2023-00080.241.23Stored XSS in hledger-web

keter

#IntroducedFixedSummary
HSEC-2024-00010.3.41.8.4Reflected XSS vulnerability in keter

pandoc

#IntroducedFixedSummary
HSEC-2023-00141.133.1.4Arbitrary file write is possible when using PDF output or --extract-media with untrusted input

process

#IntroducedFixedSummary
HSEC-2024-00031.0.0.01.6.23.0process: command injection via argument list on Windows

tls-extra

#IntroducedFixedSummary
HSEC-2023-00050.1.00.4.6.1tls-extra: certificate validation does not check Basic Constraints

toml-reader

#IntroducedFixedSummary
HSEC-2023-00070.1.0.00.2.0.0readFloat: memory exhaustion with large exponent

x509-validation

#IntroducedFixedSummary
HSEC-2023-00061.4.01.4.8x509-validation does not enforce pathLenConstraint

xml-conduit

#IntroducedFixedSummary
HSEC-2023-00040.5.01.9.1.0xml-conduit unbounded entity expansion

xmonad-contrib

#IntroducedFixedSummary
HSEC-2023-00030.50.11.2code injection in xmonad-contrib
\ No newline at end of file diff --git a/index.html b/index.html new file mode 100644 index 00000000..1294d173 --- /dev/null +++ b/index.html @@ -0,0 +1 @@ +Haskell Security advisories

Advisories list

The Haskell Security Advisory Database is a repository of security advisories filed against packages published via Hackage.

It is generated from Haskell Security Advisory Database. Feel free to report new or historic security issues.

#Package(s)Summary
HSEC-2024-0009biscuit-haskellPublic key confusion in third-party blocks
HSEC-2024-0003processprocess: command injection via argument list on Windows
HSEC-2024-0002bzlib,bz2,bzlib-conduitout-of-bounds write when there are many bzip2 selectors
HSEC-2024-0001keterReflected XSS vulnerability in keter
HSEC-2023-0015cabal-installcabal-install uses expired key policies
HSEC-2023-0014pandocArbitrary file write is possible when using PDF output or --extract-media with untrusted input
HSEC-2023-0013git-annexgit-annex plaintext storage of embedded credentials on encrypted remotes
HSEC-2023-0012git-annexgit-annex checksum exposure to encrypted special remotes
HSEC-2023-0011git-annexgit-annex GPG decryption attack via compromised remote
HSEC-2023-0010git-annexgit-annex private data exfiltration to compromised remote
HSEC-2023-0009git-annexgit-annex command injection via malicious SSH hostname
HSEC-2023-0008hledger-webStored XSS in hledger-web
HSEC-2023-0007base,toml-readerreadFloat: memory exhaustion with large exponent
HSEC-2023-0006x509-validationx509-validation does not enforce pathLenConstraint
HSEC-2023-0005tls-extratls-extra: certificate validation does not check Basic Constraints
HSEC-2023-0004xml-conduitxml-conduit unbounded entity expansion
HSEC-2023-0003xmonad-contribcode injection in xmonad-contrib
HSEC-2023-0002biscuit-haskellImproper Verification of Cryptographic Signature
HSEC-2023-0001aesonHash flooding vulnerability in aeson
\ No newline at end of file