CVSS: 4.6EPSS: 0%CPEs: 2EXPL: 0CVE-2024-32657 – Hydra has persistent XSS vulnerability serving HTML build outputs
https://notcve.org/view.php?id=CVE-2024-32657
Hydra is a Continuous Integration service for Nix based projects. Attackers can execute arbitrary code in the browser context of Hydra and execute authenticated HTTP requests. The abused feature allows Nix builds to specify files that Hydra serves to clients. One use of this functionality is serving NixOS `.iso` files. The issue is only with html files served by Hydra. • https://github.com/NixOS/hydra/commit/b72528be5074f3e62e9ae2c2ae8ef9c07a0b4dd3 https://github.com/NixOS/hydra/security/advisories/GHSA-2p75-6g9f-pqgx https://github.com/NixOS/nixpkgs/pull/306017 https://github.com/NixOS/nixpkgs/pull/306018 • CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') •
CVSS: 8.1EPSS: 0%CPEs: 1EXPL: 1CVE-2023-42449 – Malicious head initialiser can extract PTs from control of Hydra scripts, leading to locked participant commits or spoofed commits
https://notcve.org/view.php?id=CVE-2023-42449
Hydra is the two-layer scalability solution for Cardano. Prior to version 0.13.0, it is possible for a malicious head initializer to extract one or more PTs for the head they are initializing due to incorrect data validation logic in the head token minting policy which then results in an flawed check for burning the head ST in the `initial` validator. This is possible because it is not checked in `HeadTokens.hs` that the datums of the outputs at the `initial` validator are equal to the real head ID, and it is also not checked in the `off-chain code`. During the `Initial` state of the protocol, if the malicious initializer removes a PT from the Hydra scripts it becomes impossible for any other participant to reclaim any funds they have attempted to commit into the head, as to do so the Abort transaction must burn all the PTs for the head, but they cannot burn the PT which the attacker controls and so cannot satisfy this requirement. That means the initializer can lock the other participants committed funds forever or until they choose to return the PT (ransom). The malicious initializer can also use the PT to spoof that they have committed a particular TxO when progressing the head into the `Open` state. For example, they could say they committed a TxO residing at their address containing 100 ADA, but in fact this 100 ADA was not moved into the head, and thus in order for an other participant to perform the fanout they will be forced to pay the attacker the 100 ADA out of their own funds, as the fanout transaction must pay all the committed TxOs (even though the attacker did not really commit that TxO). • https://github.com/input-output-hk/hydra/blob/1e13b60a7b21c5ccd6c36e3cf220547f5d443cef/hydra-node/src/Hydra/Chain/Direct/Tx.hs#L645-L761 https://github.com/input-output-hk/hydra/blob/1e13b60a7b21c5ccd6c36e3cf220547f5d443cef/hydra-plutus/src/Hydra/Contract/Initial.hs#L84-L91 https://github.com/input-output-hk/hydra/blob/master/CHANGELOG.md#0130---2023-10-03 https://github.com/input-output-hk/hydra/blob/master/hydra-plutus/src/Hydra/Contract/HeadTokens.hs#L76-L136 https://github.com/input-output-hk/h • CWE-20: Improper Input Validation •
CVSS: 8.1EPSS: 0%CPEs: 1EXPL: 0CVE-2023-42448 – Hydra's contestation period in head datum can be modified during Close transaction, allowing malicious participant to freely modify the contestation deadline
https://notcve.org/view.php?id=CVE-2023-42448
Hydra is the layer-two scalability solution for Cardano. Prior to version 0.13.0, the specification states that the contestation period in the datum of the UTxO at the head validator must stay unchanged as the state progresses from Open to Closed (Close transaction), but no such check appears to be performed in the `checkClose` function of the head validator. This would allow a malicious participant to modify the contestation deadline of the head to either allow them to fanout the head without giving another participant the chance to contest, or prevent any participant from ever redistributing the funds locked in the head via a fan-out. Version 0.13.0 contains a patch for this issue. Hydra es la solución de escalabilidad de capa dos para Cardano. • https://github.com/input-output-hk/hydra/blob/master/CHANGELOG.md#0130---2023-10-03 https://github.com/input-output-hk/hydra/blob/master/hydra-plutus/src/Hydra/Contract/Head.hs#L284-L296 https://github.com/input-output-hk/hydra/blob/master/hydra-plutus/src/Hydra/Contract/Head.hs#L320-L323 https://github.com/input-output-hk/hydra/commit/2f45529729e28254a62f7a7c8d6649066923ed1f https://github.com/input-output-hk/hydra/security/advisories/GHSA-mgcx-6p7h-5996 • CWE-20: Improper Input Validation CWE-1284: Improper Validation of Specified Quantity in Input •
CVSS: 9.1EPSS: 0%CPEs: 1EXPL: 1CVE-2023-38701 – Hydra's committed UTxOs at Commit validator and UTxOs at Initial validator can be spent arbitrarily by anyone
https://notcve.org/view.php?id=CVE-2023-38701
Hydra is the layer-two scalability solution for Cardano. Users of the Hydra head protocol send the UTxOs they wish to commit into the Hydra head first to the `commit` validator, where they remain until they are either collected into the `head` validator or the protocol initialisation is aborted and the value in the committed UTxOs is returned to the users who committed them. Prior to version 0.12.0, the `commit` validator contains a flawed check when the `ViaAbort` redeemer is used, which allows any user to spend any UTxO which is at the validator arbitrarily, meaning an attacker can steal the funds that users are trying to commit into the head validator. The intended behavior is that the funds must be returned to the user which committed the funds and can only be performed by a participant of the head. The `initial` validator also is similarly affected as the same flawed check is performed for the `ViaAbort` redeemer. • https://github.com/input-output-hk/hydra/blob/master/CHANGELOG.md#0120---2023-08-18 https://github.com/input-output-hk/hydra/blob/master/hydra-plutus/src/Hydra/Contract/Commit.hs#L94-L97 https://github.com/input-output-hk/hydra/blob/master/hydra-plutus/src/Hydra/Contract/Util.hs#L32-L42 https://github.com/input-output-hk/hydra/security/advisories/GHSA-6x9v-7x5r-w8w6 • CWE-20: Improper Input Validation •
CVSS: 6.5EPSS: 0%CPEs: 1EXPL: 0CVE-2023-42806 – Snapshot signature not including HeadID will allow replay attacks
https://notcve.org/view.php?id=CVE-2023-42806
Hydra is the layer-two scalability solution for Cardano. Prior to version 0.13.0, not signing and verifying `$\mathsf{cid}$` allows an attacker (which must be a participant of this head) to use a snapshot from an old head instance with the same participants to close the head or contest the state with it. This can lead to an incorrect distribution of value (= value extraction attack; hard, but possible) or prevent the head to finalize because the value available is not consistent with the closed utxo state (= denial of service; easy). A patch is planned for version 0.13.0. As a workaround, rotate keys between heads so not to re-use keys and not result in the same multi-signature participants. • https://github.com/input-output-hk/hydra/blob/ec6c7a2ab651462228475d0b34264e9a182c22bb/hydra-node/src/Hydra/HeadLogic.hs#L357 https://github.com/input-output-hk/hydra/blob/ec6c7a2ab651462228475d0b34264e9a182c22bb/hydra-node/src/Hydra/Snapshot.hs#L50-L54 https://github.com/input-output-hk/hydra/blob/ec6c7a2ab651462228475d0b34264e9a182c22bb/hydra-plutus/src/Hydra/Contract/Head.hs#L583-L599 https://github.com/input-output-hk/hydra/security/advisories/GHSA-gr36-mc6v-72qq • CWE-347: Improper Verification of Cryptographic Signature •