Опубликован выпуск проекта Dropbear 2025.88, развивающего сервер и клиент SSH, получивший распространение в беспроводных маршрутизаторах и компактных дистрибутивах, подобных OpenWrt. В новой версии устранена уязвимость (CVE-2025-47203) в реализации SSH-клиента (программа dbclient), позволяющая выполнить shell-команды при обработке специально оформленного имени хоста. Уязвимость вызвана отсутсвием экранирования спецсимволов в имени хоста и использованием командного интерпретатора при запуске команд в режиме multihop (несколько хостов, разделённых запятой). Уязвимость представляет опасность для систем, запускающих dbclient с непроверенным именем хоста...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63223
Опять на Си
Удивительно. Уязвимости находят в кодовых базах одного из самого распространённого из системных языков. Вот это да!
> Удивительно. Уязвимости находят в 100500ом переизобретении лисапедаПоправил, не благодари.
Кстати, да, это существенно выправляет смысл
А так в этом и проблема, родной! Про "системный" язык - это такая придумка, чтобы наделить сишку новыми полномочиями и в этих рамках разматывать аргументы. По факту Си - это никакой не "системный" (что вообще значит это определение?), а ЯП для написания ядер ОС. Для написания прикладного софта (а ssh это прикладной софт) есть языки гораздо более подходящие. Так что вопрос именно в этом - что взяли неподходящий инструмент.
> Так что вопрос именно в этом - что взяли неподходящий инструмент.не подходящий для бекдоров? именно для этого и его в штатах форсили, а ведь эпоху начинали европейские языки. А сейчас такая же история с растом, это мнимая обманка безопасТности.
раст это торговая марка, а не язык
> А так в этом и проблема, родной! Про "системный" язык - это такая придумка,
> чтобы наделить сишку новыми полномочиями и в этих рамках разматывать аргументы.
> По факту Си - это никакой не "системный"По факту на си написана почти вся реально исползуемая системщина, от фирмварей в самых мелких MCU до эвон каких операционок и core-софта для них. Без си вы просто пискнуть на этот форум - не сможете. На самом базовом уровне, от кучи фирмварей без которых у вас не будет ни винча/ssd, ни видяхи, ни даже клавы и монитора - до BIOS/UEFI и далее - ОС.
> Для написания прикладного софта (а ssh это прикладной софт) есть языки гораздо более подходящие.
Вот конкретно тому ssh надо быть - мелким и с минимумом зависимостей. Чтобы даже в мелкий роутер с 32 мегами оперативы на все лезть. Если этого не будет - этот проект просто никому даром не сдастся тогда.
А вы с вашими супер яп можете прийти и показать вон тем мастеркласс. Делом. Если вы тоже сможете жрать менее мега RSS - может и у вас будет какая-то ниша. Все познается в сравнении.
> Удивительно.А чего тут удивительного, если мне нужен софт с бекдором и я буду писать на Си, так как его (Си) мало кто "знает" :)
Причем тут си, если проблемы в неверном экранировании символов для шела? Точно такие же проблемы будут если переписать и на расте, и на js и на java.Си головного мозга
> Си головного мозгаУ Свидетелей Rust такого диагноза быть не может.
Конечно, там же всё безопасно
> Причем тут си, если проблемы в неверном экранировании символов для шела?Если вместо традицинно опеннетного "да как он посмел катить бочку на любимую (и в последний раз использованную в laba3.c) сишечку!!1" глянуть в патч, то можно увидеть традиционно-сишное переизобретении лисапедов, не?
> Точно такие же проблемы будут если переписать и на расте, и на js и на java.
Я тебя сильно удивлю, но ... "готовые" (и массово используемые) либы намного менее проблематичны. Тупо потому что даже если авторы изначально тоже "не очень шарили" в предмете, то все же грабли всей толпой пользователей - выловливаются намного быстрее, чем в 100500й реализации "сугубо для внутреннего пользования".
> "готовые" (и массово используемые) либы намного менее проблематичны.На C или расте?
> На C или расте?Разумеется не на си. В сишке нормальных либ для такого нет, а стандартная либа убогая до нельзя. Поэтому каждый пишет свой велосипед, вплоть до сплита строки. А потом оказывается что в нем дырень дарящая рут.
>> "готовые" (и массово используемые) либы намного менее проблематичны.
> На C или расте?Э-э, и много ты знаешь много готовых (и используемых массово) сишных либ для экранирования символов?
Это с учётом использования гугла или нет?
>использованием командного интерпретатора при запуске командСколько раз твердили миру: за использование `exec` для чего-либо кроме запуска команд, которые пользователь приказал запустить, нужно к стенке ставить.
>>использованием командного интерпретатора при запуске команд
> Сколько раз твердили миру: за использование `exec` для чего-либо кроме запуска команд,
> которые пользователь приказал запустить, нужно к стенке ставить.Скорее за system(). Exec значительно безопаснее. Но ssh с его юниксвеем так работает что вот именно ssh сделать именно безопасно - и не встав на грабли - не очень просто. Допушения неудобные, и от клиента и от сервера требуется жесткая валидация все и вся, иначе те два самосвала грабель в полях - заедут ручкой по лбу, и еще скажите спасибо если оптимизаторы топор не насадили.
Shell-out — самый обычный unix-way, в TAoUP это описано и именно в этом ключе. Ты сейчас фактически предложил поставить к стенке тех самыд дидов, которые юниксы сваяли и их ортодоксию^Wфилософию заложили.
Знаешь, unix-way - это вообще не об использовании баша. Он о декомпозиции. Более того, под "программами" "диды" понимали в том числе библиотеки. Это винда приучила всех делить на "приложение" и "компонент приложения" (dynamic-link-library). Академия, откуда родом "диды" - называла библиотеки библиотеками подПРОГРАММ, то есть "библиотека" - это на самом деле жаргон, ставший нормой. Unix-way не говорит нам завязываться на баш. Шелл вообще может быть полностью объектно-ориентированным, где вообще никаких пайпов, да и вообще никаких программ, а одни библиотеки, которые можно комбинировать любым способом. Причём безопасно (если без бэкдоров, но есть способы сделать так, что безопасно будет даже с бэкдорами ... и всё равно в рамках одного процесса!).А использование шелла везде где попало - это просто тараканы в головах некоторых.
> Шелл вообще может быть полностью объектно-ориентированнымВообще-то McIlroy прямо требует:
"Write programs to handle text streams"Так что объектно-ориентированный уже будет нарушением unix-way.
Обмен сериализованнымт в текстовое представление объектами — это всё ещё unix-way, определение которого если и существует, то только вот в этих самых свидетельствах апостолов и толкованиях муллы, или уже нет?
Ты крайне плохо представляешь о чём ты говоришь. Когда концепцию назвали shell out, баш ещё не начали даже писать. Но мой тезис про ортодоксию ты таки подтвердил, молодец.
Так уязвимость получается не для серверов (маршрутизаторов), а для клиента.
> Уязвимость вызвана отсутсвием экранирования спецсимволов в имени хостаКак же это замечательно. Зато, наверняка, и по типам всё проверяется и всё норм и всевозможные интеграции-тестирования успешно проходит и разработчики всевозможные КоК'и соблюдают да кодят "согласно регламентам и требованиям к оформлению"
Только, дыра есть. Точнее, дырища прямо на месте парадного входа, через которую и авианосец пролезет. Но это - мелочи. Главное - всё по регламентам. А остальное - мелочи
А как надо?
Главное что контроль за софтом - кого надо. От вредоносной функцио-анальности внесённой самим автором не защитит ничего. И у автора есть железобетонная отмазка: "проект делался исключительно для себя, я вас не заставлял его юзать"
Правильная система типов, с введением типа наподобие ExecArgumentString, который можно получить только как результат экранирования (function escapeExecArgument(string): ExecArgumentString), и который требуется сигнатурой exec(), проблему как раз решает.Но про типы в этом контексте почему-то редко думают.
Правильная система типов, с введением типа наподобие ExecArgumentString, который можно получить только как результат экранирования (function escapeExecArgument(string): ExecArgumentString), и который требуется сигнатурой exec(), проблему как раз решает.Но про типы в этом контексте почему-то редко думают.
Пффф... О каких типах может идти речь,
если в том коде они вручную считали длину с magic numbers- len += 4 + strlen(key->filename);
С другой стороны, что от сишки можно ожидать. Какие-то типы? Они даже строки нормальные не осилили.
> Правильная система типов, с введением типа наподобие ExecArgumentString, который можно
> получить только как результат экранирования (function escapeExecArgument(string): ExecArgumentString),
> и который требуется сигнатурой exec(), проблему как раз решает.
> Но про типы в этом контексте почему-то редко думают.Во-первых, в си - слабая типизация, с неявными приведениями и прочим (как и куча легаси)
Во-вторых -- ошибка там как раз в (самопальной) функции экранирования.
Я специально псевдокодом, синтаксически далёким от C, написал, чтобы было понятно, что я не про конкретный язык, а про то, что в типизации важна не только техническая, но и смысловая сторона. 10 долларов и 10 яблок - это разные вещи. Так же как и строка, несмотря на то, что это просто массив байт технически, может нести совершенно разную смысловую нагрузку.Я такой подход называю "типизация вместо валидации". Провалидировать строку можно забыть. А если у меня тип Email, то я уверен, что этот массив байт прошёл валидацию и содержит валидный Email. А если окажется невалидный, то единственное проблемное место - это конструктор типа (emailFromString).
> Я специально псевдокодом, синтаксически далёким от C, написал, чтобы было понятно, что
> я не про конкретный язык, а про то, что в типизации
> важна не только техническая, но и смысловая сторона....
> А если у меня тип Email, то я уверен, что этот
> массив байт прошёл валидацию и содержит валидный Email. А если окажется
> невалидный, то единственное проблемное место - это конструктор типа (emailFromString).Это-то понятно, но как раз без "технической стороны" (т.е. поддержки ЯП/компилятором) привычку к такому подходу выработать довольно сложно, как и следовать ему (если только ты не единственный разработчик или не начнешь костылять с помощью struct и прочего, потому что сишный typedef - просто алиас).
Т.е. пишущие в основном на Си (в лучших традициях "Настоящий Погроммист может писать программы на Фортране^W Си на любом языке!") зачастую просто не в курсе, что "так тоже можно было" ...
> Во-первых, в си - слабая типизация, с неявными приведениями и прочим (как
> и куча легаси)Можно и не очень слабую сделать.
1) -Werror в хороших проектах так то норма.
2) typedef struct ... something_t - и теперь вообще попробуйте вместо something_t или такого указателя что-то другое дать вообще.
3) Со строками 2) кстати прекрасно катит и можно завести строки с .len.> Во-вторых -- ошибка там как раз в (самопальной) функции экранирования.
#define "самопальный" :)
> Уязвимость вызвана отсутсвием экранирования спецсимволов в имени хостаПодозреваю, что надо сказать спасибо дидам, которые накалякали невнятные RFC с взаимоисключающими определениями, какие символы допустимы, а какие нет.
Opennet, это такой большой багтреккер.
Баттхерт-треккер, я бы сказал)
> Баттхерт-треккер, я бы сказал)Или просто батт-трекер, я бы сказал. Даже индекс топа a$$h0l3z интернета запросто может быть.
Мда, всегда лично смотрел с подозрением на сабж, а после новости, тем более нафиг. Лучше уж что то стандарное, но протестированное.
Поднимите руки те, кто использовал их клиентскую реализацию
Серверная в том же OpenWRT и всех прошивках на нем базирующихся(в том числе у Сяоми, у Тенды и прочих бюджетных роутерах), а вот где и кто использует их клиент вместо нормального из OpenSSH я не знаю и не встречал, если честно
Никогда не приходилось заходить по ssh прямо с роутера по link-local IP на полуживой хост? Хотя, глядя на OpenWRT, понимаю, что быстрее под кровать залезть и моник с клавой подключить, чем что-то там реанимировать как будто бы это unmanned pop за тридевять земель. Пожалуй ты прав, клиентом мало кто пользуется за пределами локалхоста, так что проблема несущественная. Поправили, и на том спасибо. Удивительно, что вообще заметил кто-то.
Знаешь, у меня у всех роутеров с ОпенВРТ достаточный объем накопителя и я всегда просто его собираю с клиентом от OpenSSH, вот и вообще не видел клиент от dropbearНе, я помню как пару лет назад зачем-то пытался вспомнить как этот клиент вообще зовут, сидел и минут пять тупил, без гуглежа так и не мог вспомнить
Но по факту клиент вообще не используют же. Сервер да, много где и все такое, а клиент вообще по нулям. Так что и правда хорошо, что нашелся единственный пользователь и он нашел ошибку.
Dropbear в реальных системах вроде облаков популярен. Ну, в целом его любят за то, что он минималистичный и стабильный, чего про openssh никак не скажешь. Кто любит? Разные серьёзные дяди с датацентрами.
Фантазер, мы тебя называли фантазер
dropbear это игрушка чисто для SOHO-роутеров, нет его нигде больше
Майкрософт для тебя роутеры?
Дорогой, если ты клиент вручную можешь запустить, то и ту команду, которую ты в имя хоста зачем-то воткнул, можешь и так запустить. Не понимаю чего все так возбудились. Уязвимость скорее из категории когда клиента невозможно запускать вручную (нет шелла, только вэбморда какая нибудь которая дергает клиент для заданного хоста). Вот тогда приплетаешь хитрым образом шелл к имени хоста - и вуаля.
Набирать dbclient для ssh клиента... ШТА ?
Какой гений выбирал имя команды ?
Я если бы даже захотел - в жизнь бы не догадался.
Вот! Ты меня понимаешь, вот и я как-то даже захотев не мог вспомнить как его зовут