Ubuntu 12.04, PCI и CVE-2015-5352

Question 1

Соответствие PCI не удастся при наличии уязвимости CVE-2015-5352. OpenSSH 6.9 устраняет эту уязвимость, но ни одна из поддерживаемых версий Ubuntu (12.04, 14.04, 15.04 и 15.10) не была исправлена.

Каков наилучший способ устранения этой уязвимости?

Question 2

У меня такая же проблема. В то время как я жду исправления от ubuntu, я также решил, что это проблема, с которой я бы обращался с моей CSA; по этой причине.

Если я понимаю представленную проблему, проблема возникает только в том случае, если пользователю root на зараженном компьютере разрешено пересылать соединения X11. В моей среде одни и те же пользователи root на затронутых компьютерах имеют доступ к корневому каталогу любой системы, доступной с этого компьютера, поэтому, если они будут вести вредоносную активность, эта потенциальная уязвимость не поможет ни помешать этому пользователю.

Во-вторых, если проблема связана с возможностью переадресации соединений X11, то не следует ли отключать эту функцию с «ForwardX11Trusted no» и «ForwardX11Timeout 0» как правильное исправление конфигурации? Это моя текущая конфигурация, и поскольку у меня нет установки X11, похоже, она подходит.

Question 3

Question 4

Это действительно плохое исследование со стороны того, кто добавил эту проблему в сканеры соответствия PCI. В моих проверках проблема описана следующим образом:

Синопсис. На SSH-сервере, запущенном на удаленном узле, влияют многочисленные уязвимости. Описание. Согласно своему баннеру, версия OpenSSH, работающая на удаленном хосте, до 6.9. Вследствие этого уязвимы следующие уязвимости: существует ошибка в функции x11_open_helper () в файле 'channels.c', которая позволяет разрешать соединения после того, как «ForwardX11Timeout» истекло. Удаленный злоумышленник может использовать это для обхода тайм-аутов и ограничений XSECURITY. (CVE-2015-5352). Различные проблемы были устранены путем устранения слабости блокировки агента за счет увеличения задержки сбоя, сохранения засоленного хеша пароля и использования функции сравнения по времени. При обработке неправильной длины шаблона существует ошибка чтения за пределами границ. Удаленный злоумышленник может использовать это, чтобы вызвать отказ в обслуживании или разглашение конфиденциальной информации в памяти. При анализе опции конфигурации «EscapeChar» существует ошибка чтения за пределами границ. Рекомендация Перейдите на OpenSSH 6.9 или новее.

Давайте сломаем его:

Сводка

В функции x11_open_helper () существует недостаток (CVE-2015-5352)

Были устранены различные проблемы, устраняя слабость блокировки агента

. Эта уязвимость относится к клиентам SSH, а не к серверам SSH (desc). Клиент SSH с окружением X становится уязвимым при подключении к злоумышленному SSH-серверу с использованием пересылки X11. Сканер по своей сути сканирует серверы, а не клиенты ... В большинстве случаев X даже не будет установлен на удаленном сервере, а соединения будут сделаны только для доверенных серверов, поэтому сценарий, который требуется этой уязвимости, невозможно реплицировать.

Различные проблемы были устранены путем устранения слабости блокировки агента

Опять же, ssh-agent - это клиентская программа, поэтому эта ошибка не влияет на безопасность проверяемого сервера и обновление до OpenSSH 6.9 не сделало бы ничего, чтобы предотвратить его использование, если только сервер не был взломан и не использовался для входа в систему на других машинах с помощью ssh-agent.

Ошибка чтения за пределами границ существует, когда разбор параметра конфигурации «EscapeChar»

Ошибка обработки за пределами границ при обработке неправильных длин шаблонов

Ошибка чтения за пределами границ при разборе Параметр конфигурации «EscapeChar»

. Изучение исходного кода показывает, что co de, который содержит ошибку, даже не присутствует в OpenSSH 6.6, поэтому ошибка OpenSSH 6.8 не применима. CVE-2015-5352 изменяет способ использования метода match_pattern_list(), но этот метод не существует в OpenSSH 6.6.

Raymond · Answer 1 · 23 May 2018 в 18:51

У меня такая же проблема. В то время как я жду исправления от ubuntu, я также решил, что это проблема, с которой я бы обращался с моей CSA; по этой причине.

Если я понимаю представленную проблему, проблема возникает только в том случае, если пользователю root на зараженном компьютере разрешено пересылать соединения X11. В моей среде одни и те же пользователи root на затронутых компьютерах имеют доступ к корневому каталогу любой системы, доступной с этого компьютера, поэтому, если они будут вести вредоносную активность, эта потенциальная уязвимость не поможет ни помешать этому пользователю.

Во-вторых, если проблема связана с возможностью переадресации соединений X11, то не следует ли отключать эту функцию с «ForwardX11Trusted no» и «ForwardX11Timeout 0» как правильное исправление конфигурации? Это моя текущая конфигурация, и поскольку у меня нет установки X11, похоже, она подходит.

Вероятно, лучше всего просто отключить доступ root к ssh целиком и потребовать использования sudo для выполнения действий, требующих root на машинах. Однако кажется, что проблема не ограничивается пользователем root, но что X11-соединения могут быть разрешены даже после таймаута. — dobey, 24 July 2015 в 17:09

ColinM · Answer 2 · 23 May 2018 в 18:51