Серьезность проблемы
Прежде всего: не паникуйте! Это не уязвимость в openssh , поэтому она не влияет на ssh, который мы используем каждый день. libssh2 - это клиентская библиотека C, которая позволяет приложениям подключаться к SSH-серверу. Во-вторых, это не уязвимость в libssh , которая не связана с библиотекой C, которая предоставляет функциональность, аналогичную libssh2.
Уязвимость существует в libssh2 версии 1.8.2 и более ранних версиях. Она фиксируется в libssh2 версии 1.9.0 . Мне не известны какие-либо способы устранения этой уязвимости, кроме обновления до версии 1.9.0.
Это уязвимость (out-of-bounds read), она может привести к удаленному доступу к информации. Она запускается, когда libssh2 используется для подключения к вредоносному SSH-серверу. Переполнение происходит во время обмена ключами Диффи-Хеллмана , что означает, что уязвимость может быть вызвана на ранней стадии процесса подключения, до того, как аутентификация будет завершена. libssh2 получает от вредоносного сервера
Нахождение уязвимости
18 марта 2019 года Крис Коулсон из Canonical Ltd. обнаружил девять уязвимостей в libssh2 ( CVE-2019-3855 - CVE-2019-3863 ). Эти уязвимости были исправлены в libssh2 v1.8.1. В то время мой коллега Павел Августинов заметил, что коммит, который устранял уязвимости, представил несколько новых предупреждений на LGTM. Эти предупреждения были из-за кода, подобного этому :
Проблема в том, что
Проблема с этой функцией в том, что приведение к
Позже я узнал, что
Запрос отрицательных кодов ошибок
Когда мы с коллегами смотрели на код, который исправил уязвимости, обнаруженные Крисом Коулсоном, мы заметили распространенную ошибку: когда отрицательное возвращаемое значение является unsigned. Эта ошибка является идеальным кандидатом для анализа вариантов, потому что ее легко допустить и (к нашему удивлению) ее не поймут стандартные предупреждения компилятора. Поэтому я написал этот простой запрос:
Этот запрос выглядит так :
Запрос ищет функции, которые иногда возвращают отрицательную целочисленную константу. Например,
Вы можете увидеть 9 результатов, которые этот запрос нашел здесь . Я включил эту ссылку в электронное письмо, которое я отправил команде libssh2 28 марта 2019 года. С тех пор они исправили все эти ошибки.
График
Команда libssh2 опубликовала исправление уязвимости на GitHub в течение нескольких дней после получения моего отчета, но на выпуск новой версии ушло почти 3 месяца. Когда я послал им PoC, я сказал им, что уязвимость находится в ревизии 38bf7ce . Оказывается, эта версия не была включена в релиз 1.8.2. Поэтому команда libssh2 исправила ошибку в своей ветке разработки и считала ее закрытой, пока я не попросил у них обновление более месяца спустя. Команда libssh2 полагала, что уязвимость не затронула 1.8.2, но я быстро обнаружил, что мой PoC также работает на версии 1.8.2. Они выпустили исправление в версии 1.9.0, не предупредив меня, поэтому я опубликовал в твиттере рекомендацию по безопасности .
● 2019-03-28: я в частном порядке раскрыл уязвимость команде libssh2.
● 2019-03-29: команда libssh2 отправила первоначальный ответ.
● 2019-04-05: команда libssh2 исправляет ошибку в своей ветке разработки: 08ef9b7 , 5929e26 , b4289ee .
● 2019-05-08: Я прошу обновить информацию о том, когда будет выпущено исправление.
● 2019-05-09: Команда libssh2 отвечает, что уязвимость когда-либо существовала только в ветке разработки и никогда не включалась в выпуск.
● 2019-05-11: Я сообщаю команде libssh2, что мой PoC также работает над релизом 1.8.2.
● 2019-05-16: команда libssh2 запрашивает исходное местоположение ошибки в версии 1.8.2.
● 2019-05-16: Я отвечаю с исходным местоположением ошибки в версии 1.8.2.
● 2019-06-17: Я предупреждаю команду libssh2, что наш 90-дневный срок раскрытия истекает 2019-06-26.
● 2019-06-20: выпущена версия 1.9.0 libssh2.
● 2019-06-30: CVE-2019-13115 назначен.
Переведено специально для https://xss.pro
Переводчик статьи - https://xss.pro/members/177895/
Оригинал - https://blog.semmle.com/libssh2-integer-overflow/
Прежде всего: не паникуйте! Это не уязвимость в openssh , поэтому она не влияет на ssh, который мы используем каждый день. libssh2 - это клиентская библиотека C, которая позволяет приложениям подключаться к SSH-серверу. Во-вторых, это не уязвимость в libssh , которая не связана с библиотекой C, которая предоставляет функциональность, аналогичную libssh2.
Уязвимость существует в libssh2 версии 1.8.2 и более ранних версиях. Она фиксируется в libssh2 версии 1.9.0 . Мне не известны какие-либо способы устранения этой уязвимости, кроме обновления до версии 1.9.0.
Это уязвимость (out-of-bounds read), она может привести к удаленному доступу к информации. Она запускается, когда libssh2 используется для подключения к вредоносному SSH-серверу. Переполнение происходит во время обмена ключами Диффи-Хеллмана , что означает, что уязвимость может быть вызвана на ранней стадии процесса подключения, до того, как аутентификация будет завершена. libssh2 получает от вредоносного сервера
uint32_t и не проверяет "границы" на нем. Затем libssh2 считывает память из смещения, указанного в uint32_t . Я написал "доказательство эксплойта" , в которой вредоносный сервер SSH возвращает очень большое значение смещения, которое вызывает libssh2 сбой из-за ошибки сегментации. Однако я считаю, что более тщательно выбранное смещение может привести к получению секретной информации, поскольку читаемая память впоследствии возвращается на сервер. Возможность использования будет зависеть от компоновки кучи. Поскольку libssh2 является только библиотекой, это будет зависеть от приложения, в котором она используется.Нахождение уязвимости
18 марта 2019 года Крис Коулсон из Canonical Ltd. обнаружил девять уязвимостей в libssh2 ( CVE-2019-3855 - CVE-2019-3863 ). Эти уязвимости были исправлены в libssh2 v1.8.1. В то время мой коллега Павел Августинов заметил, что коммит, который устранял уязвимости, представил несколько новых предупреждений на LGTM. Эти предупреждения были из-за кода, подобного этому :
if((p_len = _libssh2_get_c_string(&buf, &p)) < 0)Проблема в том, что
_libssh2_get_c_string возвращает -1 как код ошибки, но p_len не подписан, поэтому условие ошибки будет игнорироваться. Оказалось, что команда libssh2 уже исправила эти проблемы в последующем коммите, но это побудило нас поближе взглянуть на код, чтобы увидеть, не содержит ли он каких-либо других очевидных ошибок. Мы быстро обнаружили эту плохо реализованную функцию проверки границ:
Код:
int _libssh2_check_length(struct string_buf *buf, size_t len)
{
return ((int)(buf->dataptr - buf->data) <= (int)(buf->len - len)) ? 1 : 0;
}Проблема с этой функцией в том, что приведение к
int может вызвать переполнение. Левая сторона не является уязвимостью списать бесится нужно выбрать свой номер, поскольку поля buf являются доверенными значениями, но правая сторона проверки небезопасна, поскольку значение len не является доверенным. Было несложно создать эксплойт для проверки концепции, которая обходит эту проверку переполнения, делая значение len больше, чем buf-> len + 0x80000000 . PoC теперь доступен на GitHub .Позже я узнал, что
_libssh2_check_length была введена в основную ветку разработки после выпуска версии 1.8.2, поэтому такая проверка существует только в версии 1.8.2. К сожалению, версия 1.8.2 не содержит никаких проверок, поэтому PoC все еще работает. В версии 1.8.2 исходное местоположение уязвимости - kex.c: 1675 . Проблема в том, что p_len содержит недоверенное значение, поэтому последующее чтение из s может быть за пределами. Поскольку _libssh2_check_length не существует в версии 1.8.2, нет необходимости, чтобы значение p_len было больше 0x80000000, чтобы вызвать ошибку. Это означает, что гораздо меньшие значения len тоже подходят. Это означает, что ошибка ещё больше упрощает удаленный доступ к информации.Запрос отрицательных кодов ошибок
Когда мы с коллегами смотрели на код, который исправил уязвимости, обнаруженные Крисом Коулсоном, мы заметили распространенную ошибку: когда отрицательное возвращаемое значение является unsigned. Эта ошибка является идеальным кандидатом для анализа вариантов, потому что ее легко допустить и (к нашему удивлению) ее не поймут стандартные предупреждения компилятора. Поэтому я написал этот простой запрос:
Код:
import cpp
import semmle.code.cpp.dataflow.DataFlow
import semmle.code.cpp.rangeanalysis.SimpleRangeAnalysis
from Function f, FunctionCall call, ReturnStmt ret, DataFlow::Node source, DataFlow::Node sink
where call.getTarget() = f
and ret.getEnclosingFunction() = f
and ret.getExpr().getValue().toInt() < 0
and source.asExpr() = call
and DataFlow::localFlow(source, sink)
and sink.asExpr().getFullyConverted().getType().getUnderlyingType().(IntegralType).isUnsigned()
and lowerBound(sink.asExpr()) < 0
select sinkЭтот запрос выглядит так :
Код:
r_len = _libssh2_get_c_string(&buf, &r);
if(r_len <= 0)
return -1;Запрос ищет функции, которые иногда возвращают отрицательную целочисленную константу. Например,
_libssh2_get_c_string делает это в строке 773 . Затем он ищет вызовы этой функции, которые принимают возвращаемое значение и приводят его к типу unsigned.Вы можете увидеть 9 результатов, которые этот запрос нашел здесь . Я включил эту ссылку в электронное письмо, которое я отправил команде libssh2 28 марта 2019 года. С тех пор они исправили все эти ошибки.
График
Команда libssh2 опубликовала исправление уязвимости на GitHub в течение нескольких дней после получения моего отчета, но на выпуск новой версии ушло почти 3 месяца. Когда я послал им PoC, я сказал им, что уязвимость находится в ревизии 38bf7ce . Оказывается, эта версия не была включена в релиз 1.8.2. Поэтому команда libssh2 исправила ошибку в своей ветке разработки и считала ее закрытой, пока я не попросил у них обновление более месяца спустя. Команда libssh2 полагала, что уязвимость не затронула 1.8.2, но я быстро обнаружил, что мой PoC также работает на версии 1.8.2. Они выпустили исправление в версии 1.9.0, не предупредив меня, поэтому я опубликовал в твиттере рекомендацию по безопасности .
● 2019-03-28: я в частном порядке раскрыл уязвимость команде libssh2.
● 2019-03-29: команда libssh2 отправила первоначальный ответ.
● 2019-04-05: команда libssh2 исправляет ошибку в своей ветке разработки: 08ef9b7 , 5929e26 , b4289ee .
● 2019-05-08: Я прошу обновить информацию о том, когда будет выпущено исправление.
● 2019-05-09: Команда libssh2 отвечает, что уязвимость когда-либо существовала только в ветке разработки и никогда не включалась в выпуск.
● 2019-05-11: Я сообщаю команде libssh2, что мой PoC также работает над релизом 1.8.2.
● 2019-05-16: команда libssh2 запрашивает исходное местоположение ошибки в версии 1.8.2.
● 2019-05-16: Я отвечаю с исходным местоположением ошибки в версии 1.8.2.
● 2019-06-17: Я предупреждаю команду libssh2, что наш 90-дневный срок раскрытия истекает 2019-06-26.
● 2019-06-20: выпущена версия 1.9.0 libssh2.
● 2019-06-30: CVE-2019-13115 назначен.
Переведено специально для https://xss.pro
Переводчик статьи - https://xss.pro/members/177895/
Оригинал - https://blog.semmle.com/libssh2-integer-overflow/