Суперечка щодо вразливості CVE-2014-2734

Опублікував emboss 09-05-2014
Переклав: Andrii Furmanets

Нам недавно повідомили про можливу вразливість безпеки, яка була опублікована як CVE-2014-2734. Однак, на основі нашого детального аналізу нижче, ми не вважаємо Ruby вразливим.

Ця вразливість потенційно могла б дозволити зловмиснику підробити довільні кореневі сертифікати, модифікуючи підпис сертифіката, ефективно замінюючи оригінальний приватний ключ сертифіката на той, який вибрав зловмисник.

Доказ концепції

Наступне - це наш аналіз CVE-2014-2734, ми змогли скоротити оригінальний PoC, який, на нашу думку, захоплює сутність доказу концепції:

require 'openssl'

forge_key = OpenSSL::PKey::RSA.new(2048)
raw_certificate = File.read("arbitrary.cer")
cert = OpenSSL::X509::Certificate.new(raw_certificate)
resigned_cert = cert.sign(spoof, OpenSSL::Digest::SHA1.new)

resigned_cert.verify(key) #=> true

Може здивувати, що X509Certificate#verify повертає true. Оригінальний сертифікат може містити Subject Public Key Info , який вказує на оригінальний публічний ключ, який відрізняється від публічного ключа forge_key. Очевидно, пара публічний / приватний ключ, яка була використана для повторного підпису сертифіката, більше не відповідає оригінальному публічному ключу, на який посилається Subject Public Key Info. Чому #verify повертає true?

Як перевіряються ключі

X509Certificate#verify використовує функцію OpenSSL X509_verify внутрішньо, яка делегує до ASN1_item_verify. Ці функції встановлюють валідність підпису з урахуванням публічного ключа , який був представлений. Однак, вони не перевірять, чи відповідає наданий ключ фактично будь-якому публічному ключу суб’єкта, на який посилається сертифікат. Це означає, що повернення true є очікуваною поведінкою для X509Certificate#verify у цьому сценарії. Пропуск цієї перевірки не має значного впливу на загальну безпеку моделі довіри X.509.

Розділ 4.1.1.3 RFC 5280 явно зазначає, що, обчислюючи підпис сертифіката, CA підтверджує правильність інформації , що міститься в сертифікаті. Хоча цей принцип порушується у наведеному вище прикладі коду, це не становить загрози безпеці. Сертифікат, підроблений або модифікований таким чином, не може бути експлуатований, якщо хтось не зможе переконати вас явно довірити сертифікату, який порушує цей принцип.

Потенційні ризики

Є два випадки для розгляду:

Повторний підпис кореневого сертифіката

Як користувачі, ми довіряємо кореневим сертифікатам безумовно. Навіть якщо вони не містять валідної інформації, статус публічно визнаного кореневого сертифіката сам по собі є тим, що тримає їх чистими. Вони є попередньо налаштованими значеннями у сховищах довіри наших браузерів або операційних систем. Просто володіння ними встановлює їхній статус як валідних якорів довіри. Наприклад, OpenSSL сам не перевіряє підпис самопідписаних кореневих сертифікатів за замовчуванням з тих самих причин, див. Документацію X509_V_FLAG_CHECK_SS_SIGNATURE.

Повторно підписаний кореневий сертифікат стає де-факто “самопідписаним” сертифікатом (хоча з неправильним Subject Public Key Info). Це не більш небезпечно, ніж звичайний самопідписаний кореневий сертифікат. Насправді, будь-хто може створити самопідписані кореневі сертифікати, які можуть повністю відповідати валідному кореневому сертифікату - за винятком підпису. Оскільки ми довіряємо кореневим сертифікатам лише через володіння, такий сертифікат-обманщик безглуздий без активного згоди клієнта довірити йому.

Повторний підпис проміжного або листового сертифіката

Також повторний підпис непідкореневого сертифіката не порушує безпеку моделі довіри X.509. Хоча ми зазвичай не володіємо цими видами сертифікатів заздалегідь, їхня підробка буде виявлена під час процедури перевірки шляху. Тут підпис будь-якого непідкореневого сертифіката перевіряється, використовуючи публічний ключ видаючого сертифіката. У якийсь момент у ланцюжку сертифікатів підробка буде в кінцевому підсумку виявлена у формі невалідного значення підпису сертифіката .

Висновок

На закінчення, ми вважаємо, що X509Certificate#verify працює, як очікується. Інші незалежно прийшли до того ж висновку і тому ми оскаржили CVE-2014-2734 та попросили про його скасування. Ви можете знайти наш повний аналіз оригінального доказу концепції , включаючи коментарі.