The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Уязвимость в GnuTLS, позволяющая возобновить сеанс TLS 1.3 без знания ключа

09.06.2020 09:59

В библиотеке GnuTLS, которая применяется по умолчанию во многих пакетах из состава Debian, включая пакетный менеджер APT и многие утилиты, выявлена уязвимость (CVE-2020-13777), позволяющая возобновить ранее остановленный сеанс TLS без знания сессионного ключа. С практической стороны уязвимость может применяться для осуществления MITM-атак.

Уязвимость вызвана некорректным построением сессионного ticket-ключа - TLS-сервер не осуществлял привязку сессионного ключа шифрования со значением, переданным приложением. До первой ротации ключа TLS-сервер при формировании сессионных ключей продолжает использовать некорректные данные вместо ключа шифрования, полученного от приложения, что позволяет атакующему обойти аутентификацию в TLS 1.3 и возобновить прошлые сеансы в режиме TLS 1.2.

Уязвимость устранена в выпуске 3.6.14, в котором также решены проблемы с обработкой перекрёстно подписанных сертификатов, всплывшие после устаревания корневого сертификата AddTrust. Проблема проявляется начиная с выпуска 3.6.4 (2018-09-24). В дистрибутивах уязвимость устранена в Debian, SUSE, FreeBSD, Fedora, Ubuntu, EPEL, RHEL 8 (RHEL 6 и 7 не подвержены).

  1. Главная ссылка к новости (https://lists.gnupg.org/piperm...)
  2. OpenNews: Устаревание корневого сертификата AddTrust привело к сбоям в системах с OpenSSL и GnuTLS
  3. OpenNews: Лидеры проектов GnuTLS, grep и sed выходят из проекта GNU в знак несогласия с политикой Фонда СПО
  4. OpenNews: Критическая уязвимость в GnuTLS, существенно влияющая на безопасность дистрибутивов Linux
  5. OpenNews: Обновление GnuTLS 3.4.13 с устранением уязвимости
  6. OpenNews: Релиз библиотеки GnuTLS 3.6.0
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/53120-gnutls
Ключевые слова: gnutls
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (31) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Alen (??), 10:23, 09/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +11 +/
    Минуттачку, мы с вами ещё не закончили!  ;)
     
     
  • 2.16, Аноним (16), 22:23, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    ...Будьте добры, помедленнее! Я записываю...
     

  • 1.2, КО (?), 10:35, 09/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "может применяться"
    Только опять таки надо знать атакующего
     
  • 1.3, YetAnotherOnanym (ok), 12:03, 09/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > TLS-сервер не осуществлял привязку сессионного ключа шифрования со значением, переданным приложением

    Шикарно...

     
  • 1.4, Аноним (4), 15:24, 09/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    > GnuTLS, которая применяется по умолчанию во многих пакетах ..., включая пакетный менеджер

    Все загрузочные ISO образы, стайджи и пакеты программ должны обязательно проверяться OpenPGP. Не зависимо от того, что скачали их по https.

     
     
  • 2.5, Аноним84701 (ok), 16:18, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >> GnuTLS, которая применяется по умолчанию во многих пакетах ..., включая пакетный менеджер
    > Все загрузочные ISO образы, стайджи и пакеты программ должны обязательно проверяться OpenPGP.
    > Не зависимо от того, что скачали их по https.

    Зря стараетесь.
    Когда пытаешься донести до местных Свидетелей HTTPS-ца, что шифрование канала никак не заменяет подписей, шифрования самих данных или использования нормальных алгоритмов аутентификации  (особенно учитывая весьма идиотскую привычку "вебдевов" пересылать логины и пароли плейнтекстом "ну а чо, это же в https, а значит сикурно!", где они в обычно в таком виде и хранятся) -- начинается кидание <этим самым, коричневым>, истерика и причитания про луддитов ;)

     
     
  • 3.9, Аноним (9), 20:03, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Самое удивительное, что в это кто-то верил. Мозилла с этими радужными значками так особенно отличилась, вся такая безопасная, угу. А хром вообще сканирует систему. Всё для пущей безопасности, ага.

    А как ещё пересылать, если не плейнтекстом? Передаётся плейн (желательно не через GET, но GET это очень удобно пользователю) и сравнивается с хэшем. Md5 в лучшем случае, хаха. Но с плейн текст паролями должно быть проще вернуть аккаунт законному владельцу в случае чего.

     
     
  • 4.10, Аноним (10), 21:29, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    https://wiki.debian.org/SecureApt

    Но вы продолжайте, продолжайте, за вашим сеансом взаимной мастурбации интересно наблюдать.

     
     
  • 5.11, Аноним (9), 21:34, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > https://wiki.debian.org/SecureApt
    > Но вы продолжайте, продолжайте, за вашим сеансом взаимной мастурбации интересно наблюдать.

    Не понял, при чём тут дебилиан, извините. Но я застал время, когда пакеты в арче и генте никак не верифицировались.

     
  • 4.12, Аноним84701 (ok), 21:40, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > А как ещё пересылать, если не плейнтекстом?

    А зачем? См. хотя бы ту же авторизацию в WPA-PSK (никто не гоняет пароль). Ну или PAKE/SRP (Secure Remote Password).

     
     
  • 5.13, Аноним (9), 21:43, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >> А как ещё пересылать, если не плейнтекстом?
    > А зачем? См. хотя бы ту же авторизацию в WPA-PSK (никто не
    > гоняет пароль). Ну или PAKE/SRP (Secure Remote Password).

    А это где-то используется в интернете? На каких сайтах?

     
     
  • 6.14, Аноним84701 (ok), 21:55, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >>> А как ещё пересылать, если не плейнтекстом?
    >> А зачем? См. хотя бы ту же авторизацию в WPA-PSK (никто не
    >> гоняет пароль). Ну или PAKE/SRP (Secure Remote Password).
    > А это где-то используется в интернете? На каких сайтах?

    А нигде (хотя конечно может где-то и есть, благо либ с реализацией куча https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol#Implementations) -- ведь "испокон веков" принято гонять пароли в плейнтексте. Зачем что-то менять, "ведь есть HTTPS и поэтому оно секурно!"(с).
    Поэтому в браузеры и стандарты попала вагон и маленькая тележка хлама, но никак не реализация нормальной аутетнификации.

     
  • 6.23, Аноним (23), 20:59, 10/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Как минимум, при использовании AWS Amplify для AWS Cognito. Там из коробки SRP.
     
  • 3.24, Аноним (24), 08:02, 11/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > идиотскую привычку "вебдевов" пересылать логины и пароли плейнтекстом "

    Как сделать логин-форму без скриптов и паролей плейнтекстом?

     
     
  • 4.25, Аноним84701 (ok), 13:14, 11/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >> идиотскую привычку "вебдевов" пересылать логины и пароли плейнтекстом "
    > Как сделать логин-форму без скриптов и паролей плейнтекстом?
    > без скриптов

    И в вакууме. Сферическом.
    В 2020м только рассказывать о восьмом чуде света -- современном, интерактивном сайте, работающем без JS 🙄

    Но так и быть:
    https://tools.ietf.org/html/rfc2069
    >  January 1997
    >  An Extension to HTTP : Digest Access Authentication

    Оно было еще в IE 5. Но проще ж было просто пересылать формочку (в то время даже без обертки https) и не заморачиваться 🙄

    Ну и зачастую логин c (любым) паролем -- на самом деле не нужен:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA256

    Это _мое_ сообщение!
    Отправленно плейнтекстом.
    -----BEGIN PGP SIGNATURE-----

    iHUEARYIAB0WIQSqzOsxglhneE9AoANPeamwXnt+nQUCXuIAPwAKCRBPeamwXnt+
    nYEdAQC1A9l0HEIXvx9y3x6t6mtpshg/e7aGa4tEIZ/bdzdxRwD+JrNojtRlHM/7
    H2DBCNQPhtVtZ6vgEo07MarPvVbHoQk=
    =89pk
    -----END PGP SIGNATURE-----

     
     
  • 5.26, Аноним (26), 17:41, 11/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > И в вакууме. Сферическом.

    В 2020м только рассказывать о восьмом чуде света -- современном, интерактивном сайте, работающем без JS 🙄

    Опеннет удивительный сайт. Здесь собираются анти-https и любители модных уеб-технологий (bloatware) в одном лице.

    > January 1997
    >  An Extension to HTTP : Digest Access Authentication
    > Obsolete

    Ну такое.

    > Ну и зачастую логин c (любым) паролем -- на самом деле не нужен:

    -----BEGIN PGP SIGNED MESSAGE-----

    Теперь для каждого сайта надо новый ключ создавать и хранить?

     
     
  • 6.27, Аноним84701 (ok), 18:02, 11/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >> И в вакууме. Сферическом.
    > В 2020м только рассказывать о восьмом чуде света -- современном, интерактивном сайте,
    > работающем без JS 🙄
    > Опеннет удивительный сайт. Здесь собираются анти-https и любители модных уеб-технологий (bloatware) в одном лице.

    А еще любители читать, хм, не совсем глазами, между строк -- и додумывать все остальное. Или аноним может процитировать мое "анти-https" высказывание?

    >> January 1997
    >>  An Extension to HTTP : Digest Access Authentication
    >> Obsolete
    > Ну такое.

    Ну, можно сделать вид, что там нет ссылки на следующий RFC https://tools.ietf.org/html/rfc2617
    1999 года (и оттуда - на версию 2014).
    И что технология заглохла из-за злобного сговора веббраузероклепальщиков, а не потому что "вебдевы" предпочитали не заморачиваться - "и так сойдет!" (с)

    >> Ну и зачастую логин c (любым) паролем -- на самом деле не нужен:
    > -----BEGIN PGP SIGNED MESSAGE-----
    > Теперь для каждого сайта надо новый ключ создавать и хранить?

    1) не на каждый сайт, а лишь на каждый ID.  
    2) какая принципиальная разница-то?


     
     
  • 7.28, Вы забыли заполнить поле (?), 18:33, 11/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Или аноним может процитировать мое "анти-https" высказывание?

    Оно где-то здесь: "Свидетелей HTTPS-ца"

    > И что технология заглохла из-за злобного сговора веббраузероклепальщиков, а не потому что "вебдевы" предпочитали не заморачиваться - "и так сойдет!" (с)

    RFC это очень хорошо, но на практике то можно?

    > 1) не на каждый сайт, а лишь на каждый ID.  

    2) какая принципиальная разница-то?

    Очень неудобно. Софта то для этого нет.

     
     
  • 8.29, Аноним84701 (ok), 19:00, 11/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Кто не с нами, тот против нас И энта самое, что там с современными интеракти... текст свёрнут, показать
     
     
  • 9.30, Аноним (-), 20:21, 11/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Это какие Ну ладно ... текст свёрнут, показать
     
     
  • 10.31, Аноним84701 (ok), 21:03, 11/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Это вам лучше знать, раз уж задавали такие странные вопросы Я, несмотря на вкуш... текст свёрнут, показать
     

  • 1.6, Аноним (6), 17:02, 09/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Уязвимость в GnuTLS, позволяющая возобновить сеанс TLS 1.3

    Хорошо, что у Микрософт и Эппл библиотеки TLS 1.3 без дыр!

     
     
  • 2.7, Билл Джобс (?), 17:07, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • +6 +/
    У нас вообще все библиотеки без дыр.
    (Но код мы вам не покажем, вы должны верить нам, потому что у нас серьезные корпорации).
     
     
  • 3.8, supportapple.com (?), 18:10, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Всё без дыр. В них нет нужды. У нас нормальные инженерные входы.
     
  • 3.19, Бизнесс по всему миру (?), 08:32, 10/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если честно, поверить вам проще чем анонимным волосатым мамкиным хацкерам.
     
  • 3.32, Lex (??), 21:40, 11/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Всё так.
    Не «дыры», а «технологические отверстия» :)
     
  • 2.22, Аноним (22), 19:32, 10/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Речь идёт про "безопасный Линукс", а не Винду и Мак. Не отвлекайся.
     

  • 1.15, Аноним (15), 22:13, 09/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Уязвимость устранена в выпуске 3.6.14
    >В дистрибутивах уязвимость устранена в Debian, SUSE, FreeBSD, Fedora, Ubuntu, EPEL, RHEL 8

    Слоупоки.


    pacman -Qi gnutls | grep -e Version -e 'Install Date'
    Version         : 3.6.14-1
    Install Date    : Fri 05 Jun 2020 01:18:03 PM MSK


     
     
  • 2.17, Аноним (9), 22:39, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    В генту ещё 4 обновили, но glsa только сегодня выпустили https://security.gentoo.org/glsa/202006-01
     

  • 1.18, rtr.ru (?), 23:24, 09/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    интересно все же, как вявили этот уязвимость?o_0 почему именно сейчас, а не тогда когда создавали-тестировали ОС!!!
     
     
  • 2.20, rioko (?), 10:35, 10/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    если б вы хоть краешком были знакомы с концепцией и методологией практического тестирования вопрос отпал бы сам собой.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру