Affected: Hackage: aeson

# 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.

Affected: Hackage: biscuit-haskell

# 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.

Affected: Hackage: xmonad-contrib

# 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.

Affected: Hackage: xml-conduit

# 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.

Affected: Hackage: tls-extra

# 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.

Affected: Hackage: x509-validation

# 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.

Affected: Hackage: base, Hackage: toml-reader

# `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`:

```haskell 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 en…

Affected: Hackage: hledger-web

# 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][cheatsheet]). 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.

[cheatsheet]: https://owasp.org/www-community/xss-filter-evasion-cheatsheet

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

Affected: Hackage: git-annex

# *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`.

Affected: Hackage: git-annex

# *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…