[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] CVE Request - Ruby OpenSSL Library - IV Reuse in GCM Mode
From:       Mike Santillana <michael.santillana () wework ! com>
Date:       2016-09-30 14:00:29
Message-ID: CAARAU444QiAcq1eEXy3_QzyT_cPb4ysvN1HEP=ka8kO6+2ki9Q () mail ! gmail ! com
[Download RAW message or body]


Hello,

Is there any update on the cve request? Additionally, the ruby team has
made a commit to fix this:
https://github.com/ruby/openssl/commit/8108e0a6db133f3375608303fdd2083eb5115062

Thanks,


*WeWork | Mike Santillana*
Security Engineer
www.wework.com
Create Your Life's Work

On Mon, Sep 19, 2016 at 6:02 PM, Mike Santillana <
michael.santillana@wework.com> wrote:

> Hi Reed,
>
> Yes this has been submitted via HackerOne as well.
>
> Thanks
>
>
> *WeWork | Mike Santillana*
> Security Engineer
> 845-709-5655
> www.wework.com
>
> Create Your Life's Work
>
> On Mon, Sep 19, 2016 at 4:55 PM, 'Reed Loden' via Information Security <
> infosec@wework.com> wrote:
>
>> Was Ruby actually notified of this outside of the GitHub issue? Not sure
>> they are monitoring that repository for security issues, so could have been
>> missed.
>>
>> https://www.ruby-lang.org/en/security/ defines their security reporting
>> processes.
>>
>> ~reed
>>
>> On Mon, Sep 19, 2016 at 12:20 PM, Mike Santillana <
>> michael.santillana@wework.com> wrote:
>>
>>> Product: Ruby's OpenSSL Library
>>> Version: Tested on 2.3.1 (latest)
>>> Bug: IV Reuse
>>> Impact: Depends on the usage of the library
>>>
>>> Hello,
>>>
>>> An IV reuse bug was discovered in Ruby's OpenSSL library when using
>>> aes-gcm. When encrypting data with aes-*-gcm, if the IV is set before
>>> setting the key, the cipher will default to using a static IV. This
>>> creates
>>> a static nonce and since aes-gcm is a stream cipher, this can lead to
>>> known
>>> cryptographic issues.
>>>
>>> The documentation does not appear to specify the order of operations when
>>> setting the key and IV [1]. As an example, see the following insecure
>>> code
>>> snippet below:
>>>
>>> Vulnerable Code:
>>>
>>> def encrypt(plaintext)
>>>     cipher = OpenSSL::Cipher.new('aes-256-gcm')
>>>     iv = cipher.random_iv # Notice here the IV is set before the key
>>>     cipher.key = '11111111111111111111111111111111'
>>>     cipher.auth_data = ""
>>>     ciphertext = cipher.update(plaintext) + cipher.final
>>>     tag = cipher.auth_tag
>>>
>>>     puts "[+] Encrypting: #{plaintext}"
>>>     puts "[+] CipherMessage (IV | Tag | Ciphertext): #{bin2hex(iv)} |
>>> #{bin2hex(tag)} | #{bin2hex(ciphertext)}"
>>> end
>>>
>>> A developer that uses the code above may incorrectly assume that their
>>> code
>>> is secure from the pitfalls associated with IV reuse in aes-*-gcm, since
>>> the ‘cipher.random_iv' method is used. According to the documentation,
>>> this
>>> should generate a random IV each time the encryption method is called.
>>>
>>> When the code above is run with the same key and same plaintext message,
>>> the following results are obtained:
>>>
>>> Output:
>>> # Run 1
>>> ./gcm_encrypt.rb 'This is some secret message.'
>>> [+] Encrypting: This is some secret message.
>>> [+] CipherMessage (IV | Tag | Ciphertext): e32594080cca2b37f7d7e968 |
>>> 8c676db7551cf046266252ee776ecaa9 | 81092d16b62902d9985656253891dc
>>> 800a5bb48fb1c4ad0b7bdf6054
>>>
>>> # Run 2
>>> ./gcm_encrypt.rb 'This is some secret message.'
>>> [+] Encrypting: This is some secret message.
>>> [+] CipherMessage (IV | Tag | Ciphertext): 431d70714f5e5f876d1c7830 |
>>> 8c676db7551cf046266252ee776ecaa9 | 81092d16b62902d9985656253891dc
>>> 800a5bb48fb1c4ad0b7bdf6054
>>>
>>> Notice that in the output above a unique IV is returned for both runs,
>>> but
>>> with the same ciphertext. This proves that even though the random_iv
>>> method
>>> is called, the code is defaulting to a static IV. If an attacker can
>>> retrieve multiple ciphertext messages, it is possible to decrypt the
>>> ciphertexts by applying the same attack one would use in a two-time pad
>>> (XOR ciphertexts and crib drag).
>>>
>>> Next review the following code snippet and output, which depicts a secure
>>> implementation of the code:
>>>
>>> Valid Code:
>>>
>>> def encrypt(plaintext)
>>>     cipher = OpenSSL::Cipher.new('aes-256-gcm')
>>>     cipher.key = '11111111111111111111111111111111'
>>>     iv = cipher.random_iv # Notice here the IV is set after the key
>>>     cipher.auth_data = ""
>>>     ciphertext = cipher.update(plaintext) + cipher.final
>>>     tag = cipher.auth_tag
>>>
>>>     puts "[+] Encrypting: #{plaintext}"
>>>     puts "[+] CipherMessage (IV | Tag | Ciphertext): #{bin2hex(iv)} |
>>> #{bin2hex(tag)} | #{bin2hex(ciphertext)}"
>>> end
>>>
>>> Output:
>>> # Run 1
>>> ./gcm_encrypt.rb 'This is some secret message.'
>>> [+] Encrypting: This is some secret message.
>>> [+] CipherMessage (IV | Tag | Ciphertext): 8beb4aa05533e90f4f4eddd3 |
>>> ea1b015958a9b8bd2aafa61887309caf | 19574a9c9869b92140a57a5fd43a14
>>> 9a5eaa7e5beefdff5d56cc4136
>>>
>>> # Run 2
>>> ./gcm_encrypt.rb 'This is some secret message.'
>>> [+] Encrypting: This is some secret message.
>>> [+] CipherMessage (IV | Tag | Ciphertext): 87361b3f1e32291602ac7b40 |
>>> bce7093daa10cc9d2fad0f2b91e077f2 | 47f9a5ba55631204233ace70f169e6
>>> 65846e877dca11a6e13a659540
>>>
>>> Notice that this time both the IV and ciphertexts are both different for
>>> the same plaintext. This is the intended result a developer would expect
>>> to
>>> happen when using this library.
>>>
>>> It should be noted that when I went to Ruby's github page to report this
>>> bug, I noticed a developer also independently encountered this weird
>>> phenomenon [2]. Since it has already been brought up to the Ruby team, I
>>> have not created a new ticket.
>>>
>>> References:
>>>  [1]
>>> https://ruby-doc.org/stdlib-2.0.0/libdoc/openssl/rdoc/OpenSS
>>> L/Cipher.html#class-OpenSSL::Cipher-label-Authenticated+Encr
>>> yption+and+Associated+Data+-28AEAD-29
>>>  [2] https://github.com/ruby/openssl/issues/49
>>>
>>> I'd like to to request a CVE ID for this issue.
>>>
>>> Thanks
>>>
>>> *WeWork | Mike Santillana*
>>> Security Engineer
>>> 845-709-5655
>>> www.wework.com
>>>
>>> Create Your Life's Work
>>>
>>
>>
>


[prev in list] [next in list] [prev in thread] [next in thread]