Uploaded image for project: 'Iroha'
  1. Iroha
  2. IR-2

Multi-signatory transactions can potentially be authorised by single user

    Details

    • Type: Bug
    • Status: Complete
    • Priority: High
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: 1.0 RC5
    • Security Level: Not a security issue
    • Labels:

      Description

      In the function StatefulValidatorImpl::validate, a comparison is made between the number of signatures attached to a transaction and the quorum for the account:

      tx.signatures().size() >= account->quorum()

      This makes the implicit assumption that the number of distinct signatures is necessarily equal to the number of distinct users who have signed the transaction.

      The signatures are stored in a container with set-like semantics (a SignatureSetType), therefore merely repeating the exact same signature will not trigger this vulnerability. However, if a single user were able to create multiple distinct, valid signatures for the same plaintext using the same public key, it would be possible for a single user to authorise a transaction which ought to require the signatures of multiple users.

      It is clearly possible to conceive of digital signature algorithms which would allow this to happen, and ones which would not. Since the algorithm has been abstracted by means of a provider API, this means at the very least that there is potential for it to happen. Furthermore, the signature algorithm which is currently implemented (ed25519) appears to allow for the possibility in this instance.

      In the function ed25519_verify (part of the iroha-ed25519 repository), the signature is passed in as a const_signature_t*. This is merely a wrapper for a fixed length array (unsigned char[ed25519_signature_SIZE]), and does not contain an explicit length field. It follows that any excess data beyond the expected length would be ignored.

      Each signature is stored in an object of type SignatureType. Since the higher levels of iroha are not coupled to a particular signing algorithm, they do not appear to constrain what can be passed to that signing algorithm.

      (There may, incidentally, be secondary issue if the signature is too short, however this is unlikely to be exploitable.)

      This finding has not been validated by Nettitude, in part because there appears to be an error in the SignaturesSubet function: instead of checking that all of the signers of the transaction are signatories to the account, it appears to be checking that all signatories to the account are signers of the transaction. Consequently, it appears that all signatories must sign, even if the quorum requires a lesser number. Further investigation can likely be performed more efficiently by those familiar with the code in question.

      To address this issue, Nettitude recommends checking that the public keys of the supplied signatures are distinct: it is not sufficient that the signatures themselves be distinct.

        Attachments

          Activity

            People

            • Assignee:
              Kitsu Eugene Minibaev
              Reporter:
              gdshaw Graham Shaw
              Watchers:
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: