• # Applications that only use SSL/TLS are not impacted by this issue.

    Posté par  . Évalué à 2.


    OpenSSL supports creating a custom cipher via the legacy
    EVP_CIPHER_meth_new() function and associated function calls. This function
    was deprecated in OpenSSL 3.0 and application authors are instead encouraged
    to use the new provider mechanism in order to implement custom ciphers.

    OpenSSL versions 3.0.0 to 3.0.5 incorrectly handle legacy custom ciphers
    passed to the EVP_EncryptInit_ex2(), EVP_DecryptInit_ex2() and
    EVP_CipherInit_ex2() functions (as well as other similarly named encryption
    and decryption initialisation functions). Instead of using the custom cipher
    directly it incorrectly tries to fetch an equivalent cipher from the
    available providers. An equivalent cipher is found based on the NID passed to
    EVP_CIPHER_meth_new(). This NID is supposed to represent the unique NID for a
    given cipher. However it is possible for an application to incorrectly pass
    NID_undef as this value in the call to EVP_CIPHER_meth_new(). When NID_undef
    is used in this way the OpenSSL encryption/decryption initialisation function
    will match the NULL cipher as being equivalent and will fetch this from the
    available providers. This will succeed if the default provider has been
    loaded (or if a third party provider has been loaded that offers this
    cipher). Using the NULL cipher means that the plaintext is emitted as the

    Applications are only affected by this issue if they call
    EVP_CIPHER_meth_new() using NID_undef and subsequently use it in a call to an
    encryption/decryption initialisation function. Applications that only use
    SSL/TLS are not impacted by this issue.

    Matt Caswell

  • # Pas encore levés côté transatlantique ?

    Posté par  (site web personnel) . Évalué à 3.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.