У стабильной версии Debian есть уязвимая версия wpa_supplicant?

Я на Debian jessie стабильный релиз. Я заметил, что версия wpa_supplicant уязвима для DoS-атак в соответствии с CVE-2015-8041 :

Множественное переполнение целых чисел в парсере записи NDEF в hostapd до 2.5 и wpa_supplicant до 2.5 позволяет удаленным злоумышленникам вызвать отказ в обслуживании (сбой процесса или бесконечный цикл) с помощью большого значения поля длины полезной нагрузки в (1) WPS или (2) P2P Запись NFC NDEF, которая запускает чтение вне пределов.

На стабильном выпуске доступной версией является wpa_supplicant 2.3 , с обычным sources.list невозможно обновить текущую версию до версии wpa_supplicant 2.5 Почему Debian стабильно поддерживает некоторые устаревшие (уязвимые) пакеты?

2 Solutions collect form web for “У стабильной версии Debian есть уязвимая версия wpa_supplicant?”

В Debian есть трекер безопасности, который показывает статус CVE во всех поддерживаемых версиях. Вот ваш:

https://security-tracker.debian.org/tracker/CVE-2015-8041

Вы можете проверить, что он исправлен в версии 2.3-1+deb8u3 . Исправление, вероятно, было передано в более раннюю версию, что предотвращает нарушение других вещей с помощью rebase до новой версии в стабильном выпуске (точка стабильного выпуска).

Ошибка, которая позволяет удаленному человеку сбой программного обеспечения (DoS) не совсем на том же уровне риска, что и мы обычно думаем, когда говорим об «уязвимостях». Я бы не назвал это «уязвимым» пакетом; в противном случае вы поднимаете любую ошибку, которая может привести к сбою программы в уязвимости безопасности.

Кроме того, мне непонятно, действительно ли это можно использовать в любой реальной системе Debian. См. Комментарии в https://w1.fi/security/2015-5/incomplete-wps-and-p2p-nfc-ndef-record-payload-length-validation.txt и http://www.openwall.com/ списки / oss-security / 2015/11/02/5 :

Примечание. Никакая реализация стека NFC еще не была идентифицирована с возможностью передачи неверно сформированной записи NDEF в hostapd / wpa_supplicant. Таким образом, неизвестно, может ли эта проблема срабатывать на практике.

Как всегда, безопасность связана с управлением рисками. Уровень риска из-за этой ошибки звучит довольно низко для меня.

  • Sshd_config TPCKeepAlive по-прежнему использует незашифрованный канал и, следовательно, уязвим
  • yum install http - это безопасно?
  • Перемещение / var, / home для отдельного раздела
  • Является ли мой Linux-ящик уязвимым для атак Shell-Shock? Как я могу это исправить?
  • Как безопасно передавать пароль через SSH для использования удаленной команды
  • Блокировать отдельную команду в Linux для конкретного пользователя
  • Это MAC или DAC
  • правило modsecurity для блокировки wordpress / joomla admin login - другие
  • fail2ban ip заблокирован, но все еще попытки входа в систему
  • Debian не вошел в систему с надлежащим паролем после обновления
  • Как перечислить все открытые порты после блокировки портов с помощью iptables?
  • Linux и Unix - лучшая ОС в мире.