В библиотеке libssh (не путать с libssh2), предназначенной для добавления клиентской и серверной поддержки протокола SSHv2 в программы на языке Си, выявлена уязвимость (CVE-2021-3634), приводящая к переполнению буфера при инициировании процесса смены ключа (rekey) с использованием механизма обмена ключами, применяющего другой алгоритм хэширования. Проблема устранена в выпуске 0.9.6...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=55698
Ну сколько можно... без радикального переписывания не обойтись.
Не ной, займись этим, замаял уже!
Согласен, слишком много фрактальных недостатков накопилось.
> Согласен, слишком много *ректальных недостатков накопилосьhotfixed
Здесь вам не тут!
Тут вам не здесь!
хитрый какой анон. всем известного стоп-слова нет - жаловаться модеру нет оснований.
Вот кто тут значит настукивает
> Вот кто тут значит настукиваети не скрываю. по-моему я всех предупредил. кто не внял - ССЗБ.
Обычно уязвимости приводят к взлому системы.
А тут к переполнению буфера.А в старые добрые времена переполнение буфера приводило к уязвимостям, эх.
Убийство привело к смерти жертвы.
> в старые добрые временаВ школу собирайся, а не вспоминай про "старые добрые времена".
Новость надо читать полностью, а не по диагонали. Так как в буфере размещается криптографический хеш, то, по определению, за обозримое время невозможно сделать его содержимое предсказуемым. Так как эта задача сведется к операции создания строки по хешу, что имеет слишком высокую вычислительную сложность.
Может просто указать размер буфера по максимально длинному хэшу в системе? Это самое простое и вообще не затратное решение, да и памяти экономит текущий способ максимум пару байт на ключ, что можно легко наверстать в другом месте.
А ещё можно просто проверять в коде поступающее снаружи.Аксиома со школы, но многих потом учат не делать проверок на годность данных и прочие проверки на ошибки в вводе со стороны/от пользователя. И привычка-то меняется в худшую сторону, инженегр деградирует.
Ну, вы если бы писали подобное, я уверен предприняли все необходимые проверки и защиты. К счастью вас не пускают к написанию такого кода. Почему к счастью? Потому что тогда вы бы были заняты делом, и не могли из-за нехватки времени общаться с нами тут...
Это на какой такой галере люди пашут 24\7?
Ну что вы, что вы, хозяин добр - на большинстве галер рабы могут пару часиков поспать, поесть и поменять носки чтоб хозяину в нос не шибало.
Не, не, не, ты что, нельзя так делать! Такие проверки лишние, они только жрут ценное процессорное время и оно может тормозить на каком-то говне мамонта. Поэтому и не включают всякие stack-protector. Достаточно заявы погромиста "мамой клянусь, тут все ок" и можно сразу в прод!
Толи дело электрон.. вот в нем все хорошо... он просто не запускается на говне мамонта и можно делать все необходимые проверки...
А причем тут электрон? Вам религия не позволяет прописать нужные флаги при компиляции?
Или ваш говнокод просто не скомпилируется с ними или будет падать на каждый чих?))
Или 1% производительности вам важнее безопасности?
> Или 1% производительности вам важнее безопасности?Откуда такая большая цифра? На фоне подсчета самого хеша, проверка размера буфера и прочей обвязки теряются.
Заметны будут (в большинстве случаев ненужные, но обычно все время педалируемые в качестве эталонного примера "жырножручести проверок" местными Ылитистами) проверки на выход за границу массива в циклах ...
Потому что писать меньше одного процента как-то некомильфо))
У этих ребят https://nvlpubs.nist.gov/nistpubs/TechnicalNotes/NIST.TN.186... просадка производительности вообще получилась на уровне погрешности измерений.
> А ещё можно просто проверять в коде поступающее снаружи.Во-первых ключ меняется самой библиотекой, а не "приходит снаружи". Но надеюсь вы хотя бы саму новость прочитали.
Во-вторых не вижу никаких проблем выделять максимальное место для хэша сразу, вместо того чтобы (а) перевыделять память для одной и той же сущности на пару байт, (б) вообще иметь в этом случае дело с динамической памятью, когда речь идёт об одном слепке одного ключа, который в идеале в структуре должен находится как обычное число.
Переполнения, переполнения, переполнения... Эээх! А ведь есть просто решение. Начинается на R, заканчивается на ust
Так уже написаны библиотеки и на Rust. Просто тут речь про другую библиотеку. В общем, не очень понятно, что вы предлагаете.
Он предлагает всё везде заменить на раст. Не взирая ни на что. Любой ценой.
Но ведь раст в FF и Редох показал, что растаманы тоже ошибаются при проверке индексов массива и вылетают, текут, падают...
Лучше упасть на переполнении сразу, чем heartbleed
Он, вроде, такого не говорил. Этот риторический приём называется соломенное чучело.
LibSSH работает на всех (почти) платформах. Ваш любимый язык, к сожалению, покрывает только процентов 5 от нужного количества.Впрочем, никто не мешает вам взять, и переписать libssh на rust. Сделайте доброе дело.
А почему свет раста есть не на всех платформах? Ллвм разве не это самое?
Конечно нет, llvm или сам тулчейн раста вполне может не поддерживать какую-то богом забытую маргинальную платформу из 90х, которую поддерживает CGG или какой-то другой компилятор, но "ЭТО ОЧЕНЬ ВАЖНО!!111" и используется как аргумент почему Си это тру, а раст это отстой.
Одна архитектура, одна система, один владелец? Где-то я это уже слышал, не напомните?
Хаха, щютка на уровне Петросяна. Впрочем... глупо было ожидать большего.
Архитектур и платформ больше десятка, а на счет владельцев... напомните сколько владельцев у ядра линукса? То-то же...
Вы не видите разницы между "собирается" и "работает"?Сходите на https://doc.rust-lang.org/nightly/rustc/platform-support.html и посмотрите, что раст обещает работать(!) только на двух платформах
1) ARM64 (Linux), причем с ядром не ниже 4.2(!!), при этом винда под армы идет лесом.
2) х86/64 (Linux, Windows, macOS).Две. Архитектуры. А с учетом отсутствия поддержки винды для армов - вообще по честному полторы.
При этом С покрывает (https://en.wikipedia.org/wiki/GNU_Compiler_Collection#Archit...) десятки архитектур. О чем еще можно тут говорить?
> что раст обещает работать(!) только на двух платформах1. Это враньё, там куча поддерживаемых платформ.
2. Гарантированная работа тулзоф раста на платформе и вашей программы написанной на расте - разные вещи.
> при этом винда
> под армы идет лесомОпять враньё
aarch64-pc-windows-msvc
Поддерживаемая платформа с гарантированным бинарными релизами и тестами.> Две. Архитектуры. А с учетом отсутствия поддержки винды для армов - вообще
> по честному полторы.Наглая безумная иступлённая ложь.
> При этом С покрывает (https://en.wikipedia.org/wiki/GNU_Compiler_Collection#Archit...)
> десятки архитектур. О чем еще можно тут говорить?Только кроссплатформенность сишки миф.
Для каждой платформы нужно писать специфический код и строить замки из ифов в системе сборки, которая частью компилятора не является, как и система отладки, которая на разных платформах разная.Ну и Вишенка на торте из ваших экскрементов:
https://gcc.gnu.org/install/binaries.html
>Please note that we did not create these binaries, nor do we support them. If you have any problems installing them, please contact their makers.Тоесть тир 1 и 2 в gcc отсутствует как явление.
> Это враньё, там куча поддерживаемых платформ.Понятно. Значит разницы между "работать" и "компилироваться" растишечка таки не видит. Ну кто бы удивлялся.
А по-английски наш маленький растик уже умеет читать, или в школе еще нету уроков английского? Сможет понять разницу между
tier 1) - automated testing ensures that each tier 1 target builds and passes tests after each change.
и
tier 2) - automated tests are not always run so it's NOT GUARANTEED to produce a working build
или не сможет?
> Наглая безумная иступлённая ложь.
"Аааааа, мама, меня обидели! Так не может быть! Я не вееееееееерю!"
Иди поплачь, может полегчает.> Только кроссплатформенность сишки миф.
Муа-ха-ха-ха-ха-ха. Эй, Линус, Майкрософт, Амуде, Ленова, и еще более 20 тысяч компаний разного размера, и не знаю сколько инди девов - тут какой-то да***йоп утверждает, что ваш миллиард строк (даже чуть больше) ни разу не собирается под почти все существующие платформы с помощью gcc и не работает на ойой скольки миллиардах устройств по всему миру.
Анонимы опеннета пробивают новые днища. Надо себе в закладки этот комментарий добавить. Буду коллег смешить по пятницам.
> или не сможет?Именно что ты не можешь. Потом что для GCC написано то же самое.
secondary platforms are:
The compiler bootstraps successfully, and the C++ runtime library builds.
The DejaGNU testsuite has been run, and a substantial majority of the tests pass.На вторичных платформах оно должно просто скомпилиться и пройти некий majority тестов. И все. Насколько ответственно. Потому что это тоже не ГАРАНТИРУЕТ что оно работает. Более того, это даже может быть знаком что проблема есть. Удивительно что ты это не знаешь. Оказывается сишники тоже не видят разницу между работать и пройти только часть тестов.
В расте "automated tests are not always run" ("автоматические тесты не всегда запускаются") это проблема, а у божественного гцц - "мы допускаем что не все тесты пройдут" - это все норм, упавшим тестом больше, упавшим тестом меньше, работаем дальше. Ваше двоемыслие начинает утомлять.
> Буду коллег смешить по пятницам.
В перерывах между исправлениями double free?
Растообиженка вертится как угорь на сковороде. Приятно посмотреть.
Ахаха, ну ты даешь))Ты вкинул в тему цифру про пять процентов и ушел от ответа с просьбой перечислитью их.
Ты налажал с двумя платформами потому что не отличает работу компилятора и от работы тулзов.
Ты слился когда тебе указали что в гцц поддержка тиер2 аналогичная.А теперь все что ты можешь сказать "растообиженка вертится как угорь"? Серьезно?
Это самый отстойный слив за последний месяц!
> Ты вкинул в тему цифру про пять процентов и ушел от ответа с просьбой перечислитью их.?? где просьба?
Ну и кроме того - что, своих мозгов не хватает по картинке оценить?
> Ты налажал с двумя платформами потому что не отличает работу компилятора и от работы тулзов.
Я уже исправился - не две, а полторы. Прошу запротоколировать.
> Ты слился когда тебе указали что в гцц поддержка тиер2 аналогичная.
Ээээ. Не видел у gcc никаких tier - ни 1, ни 2. Можно тыкнуть прямой ссылкой на https://gcc.gnu.org/ ?
> А теперь все что ты можешь сказать "растообиженка вертится как угорь"? Серьезно?
Да. А ты предлагаешь мне вот эту написанную чушь на серьезных щах разбирать?
> Это самый отстойный слив за последний месяц!
Самый банальный способ разрешить когнитивный диссонанс - заявить "это не я тупой, это все вокруг дураки".
> где просьба?
>> "что же такое важное и значимое не поддерживается на уровне Tier 1-2 и занимает аж 95%?"к твоему сообщение написан текст и там даже знак вопроса... что же это может быть?
или ты ожидал что-то вроде "Уважаемый Урри, не могли бы Вы сообщить значимый источник данного утверждения?"> Ээээ. Не видел у gcc никаких
https://gcc.gnu.org/gcc-11/criteria.html
"We have classified these platforms into three categories: primary, secondary, and tertiary"> "это не я тупой, это все вокруг дураки".
Так ты с похом (при условии что это разные люди) всю тему этим занимаетесь.
> >> "что же такое важное и значимое не поддерживается на уровне Tier 1-2 и занимает аж 95%?"Ааааа. Да все, что не 5%. Начиная с iot, пробегая через мобильные девайсы и заканчивая мейнфреймами. Я думал это шутка такая, а это действительно был вопрос? Пххххх.
> "We have classified these platforms into three categories: primary, secondary, and tertiary"
А, ну ок. Пускай это будет некий аналог "tier".
Тогда в tier1 входит девять платформ, а не две.> Так ты с похом (при условии что это разные люди) всю тему этим занимаетесь.
Разные, не сомневайся. Мы с ним недавно неплохо так поср.. поспорили.
>что ваш миллиард строк (даже чуть больше) ни разу не собирается под почти все существующие платформы с помощью gcc и не работает на ойой скольки миллиардах устройств по всему миру.Внезапно да, на одной конкретной платформе не собирается миллиард строк кода от всех других платформ.
И уж точно на роутере у меня всего этого кола нет, как и процентов 80-90 всего вообще ПО невозможно под него собрать.
И что же у вас за платформа такая?
> И что же у вас за платформа такая?Хайку ос на эльбрусе!
>Понятно. Значит разницы междуЯ то разницу вижу.
А вот вы подменяете понятия, тир 2 это то же поддержка.
Ит то, что гарантий не дают, не означает что оно не работает.Вас сейчас за руку словили как дебильного ребёнка, на глупой лжи, а вы вместо извинений права качаете, мол тупой Аноним не понимает ваши стройные остроумные приёмы недобросовестного диалога.
> Ит то, что гарантий не дают, не означает что оно не работает.Че, реально? А-ха-ха-ха-ха-ха.
Впрочем... не хотите купить у меня программу, которая создает идеальные бекапы - ничто и никогда у вас не потеряется, я гар... не, не гарантирую. Но то, что я это не гарантирую, ведь не значит, что оно не работает?
> вы вместо извинений права качаете, мол тупой Аноним не понимает ваши стройные остроумные приёмы недобросовестного диалога.
Цитировать источник - это "остроумный приём недобросовестного диалога"?
И вы действительно настолько тупой, что не понимаете тех элементарных вещей, о которых я вам пишу?Ну нет, так нет. Примите мои глубочайшие извинения.
Да ну, аж интересно что же такое важное и значимое не поддерживается на уровне Tier 1-2 и занимает аж 95%? Заодно и с пруфцами что LibSSH там есть. А то цифра звучит... ну скажем взятой с потолка))Список поддерживаемыъ платформ можно увидеть тут https://doc.rust-lang.org/nightly/rustc/platform-support.html
Для хрустобоя все что не поддерживается - неважное и незначимое.> Список поддерживаемыъ платформ можно увидеть тут https://doc.rust-lang.org/nightly/rustc/platform-support.html
ожидание - список на пару страниц. Реальность: в tier1 восемь строчек. Винда, винда, винда и винда. 64 bit only. И еще, вот, нате-подавитесь - линoops и максось. В единственно-верных позах.
Нда, с другой стороны - а чего еще от макак ждать...
Про tier2 не будем - мне ваши "guaranteed to build" нафиг не упали. ЭТУ гарантию обеспечивает llvm, угу. А вот что _ваша_ поделка что-то там build после этого, а не "такая херня, такая херня получается" - никто, похоже, не гарантирует вовсе.
Разумеется это то что нужно для low-footprint библиотечки собирающейся везде где вообще есть поддержка posix.
> Win 64 bit only.Разумеется, потому что 32бит в тиер2. Мамонтам там и место - последний интеловый 32bit only проц вышел 10 лет назад (атом), а последний нормальный десктопный - в далеком 2006. Но если найдется тот кто это поддержит и протестит - это будет просто прекрасно.
> нате-подавитесь - линoops и максось.
В tier1 линуксов всего на один меньше чем вариантов винды - 4 vs 3. Так что мимо.
Столько буков написал, а ни одной значимой архитектуры так и назвал.
А теперь глянем на божественный ГЦЦ.
https://gcc.gnu.org/gcc-11/criteria.htmlPrimary Platform List.
"ожидание - список на пару страниц", реальность: линь, линь, бздя, линь, мипсы, линь, линь, солярка, линь... Очень разнообразно однако. Ни макоси, ни винды. Печалька.Secondary Platform List: о, надо же, макось и винду добавили.
А где андроид, где ios? Хотя бы на уровне "guaranteed to build"? Слабенько как-то.
> i586-unknown-freebsd
> бздяДаже в консервативной фре - ожидаемый по умолчанию класс ЦПУ теперь i686 и вообще, x86 перевели в Tier2.
Но 3d-party си-компилятор для нее, как видишь - пока еще не сломали. Потому что без него не будет ничего работать вообще, кроме голой фри, которая никому не нужна ни на 586, ни на чем другом.
> Мамонтам там и местозначит хрустикам вскоре найдется место на помойке - вместе с модными еще в прошлом году штанами от усраччи.
> Но если найдется тот кто это поддержит и протестит - это будет просто прекрасно.
не найдется - ваш хруст не нужен никому кроме ошпаренных макак, любителей свежайшего. А те не умеют в долгосрочные сложные проекты, если их не финансирует гугль, или, например, гугль.
И это в общем-то хорошо. Очередная антитехнология далеко не уйдет с винды, винды, винды, и винды.
> https://gcc.gnu.org/gcc-11/criteria.html
а вот это, чувак, не "кое-как собирается сам бинарник". Это проходят тесты DejaGNU - гарантирующие не сборку бесполезного компилятора, а то что этот компилятор хотя бы периодически после этого компилит работающий на этой платформе код - причем всеми своими фронтендами. Для начала - на этой платформе они вообще должны работать, что не очень просто, операционная система нужна (а не ведроид).
При том что это gcc11, то есть снова нечто уже маловостребованное за пределами линoops под единственноверную архитектуру из-за троянцев в механизме.
К счастью, libssh пока вроде не требует для своей сборки моднейших версий компилятора - соберется и устаревшей на десять лет.
> Ни макоси, ни винды. Печалька.
диствительна. У них ведь, бедолажек, нет своего си компилятора?
А вот своего хруста, не завязанного на llvm единственноправильной версии - действительно нет и не будет никогда и нигде.
Т.е. его не будет никогда и нигде кроме платформ, куда эппл захочет спортировать свой код, и при этом еще сами хрустики осилят на него портироваться.
Закапывайте...
> если их не финансирует гугль, или, например, гугль.
> не уйдет с винды, винды, винды, и винды.Э... гугль или гугль? Винды и винды?
Дед, ты опять забыл таблетки выпить?Но дело в том что их и так финансирует гугл. В Rust Foundation - как раз google, facebook, microsoft, aws, huawei, а в спонсорах - arm, github и еще кто-то.
Т.е. те же самые google, facebook, microsoft, huawei которые являются Platinum и Gold members в Linux Foundation))) Так что можешь не беспокоиться.
> Но дело в том что их и так финансирует гугл.ну так под платформы, одобряемые гуглем (и да, это винда - ему же нужно чтоб у раба все работало и на десктопе тоже) - оно и будет работать. Вот те пять штук из списка.
А солярисы эти ваши - пустое, как и 32битные системы. Их гугль оплачивать не планирует, и там ничего работать не будет. И тем более не будет во всякой мелкой фигне, для которой подобные библиотеки и актуальны.
Одно радует - гугль похоронил уже великое множество прожектов, так что и этому рано или поздно крышка.
> Разумеется, потому что 32бит в тиер2. Мамонтам там и место - последний интеловый 32bit only проц вышел 10 лет назад (атом), а последний нормальный десктопный - в далеком 2006. Но если найдется тот кто это поддержит и протестит - это будет просто прекрасно.Да вы профи. А ну брысь в школу, каникулы уже кончились.
https://gcc.gnu.org/install/binaries.html
>Please note that we did not create these binaries, nor do we support them. If you have any problems installing them, please contact their makers.У GCC нет тир 1 и 2 как явления.
бть... какие ж вы все же ди-лы...У gcc есть tier1 и 2. Как раз тем и отличаются, что одно тестируют, а другое - собралось, ну уже хорошо. Но он не распространяется в бинарниках, как и _любой_ gnu софт - ждите, д-лы. gnu распространяется своими разработчиками в виде исходников. Традиция тех времен, когда их принято было собирать у себя и для себя.
Придут добрые дяденьки и за вас все соберут, только к проекту они не имеют никакого отношения.
Может даже тесты запустят, прежде чем вам эту сборку вывалить на лопате.А может нет, вы ж д-лы, вы и так схаваете.
Это прекрасно.Я прямо заворожен и лишился слов.
Так вот. Это не то, что под тир 1 подразумевается обычно.
кем "подразумевается" - хрустиками?Вы и из этого новую религию сделали?
P.S. еще вон у freebsd tier'ы есть. И снова это ничуть не про бинарники.
>P.S. еще вон у freebsd tier'ы есть. И снова это ничуть не про бинарники.Ну и зачем вы так с разбегу в лужу садитесь сразу?
https://docs.freebsd.org/en/articles/committers-guide/#archs
>The FreeBSD Project provides the following guarantees to consumers of Tier 1 platforms:
>Official FreeBSD release images will be provided by the release engineering team.
>Binary updates and source patches for Security Advisories and Errata Notices will be provided for supported releases.
>Binary updates and source patches for cross-platform Security Advisories will typically be provided at the time of the announcement.
>Official binary packages for third party software will be provided by the ports team. For embedded architectures, these packages may be cross-built from a different architecture.Да конечно, бинарники необязательны, однако, тяжело обеспечить *первоклассную поддержку* когда нет официальных бинарников на которые можно ссылаться в саппорте/багрепорте.
Как-то в целом не очень первоклассно получается когда для первого класса нет официально собранных бинарников.
Проект GNU в первую очередь предоставляет поддержку свободы предоставляемого софта, это то-же нужно понимать, и только во вторую очередь всех остальных качеств.
пох, ты конечно идиот. Но здесь отлично выступил.
Зацени как у народца подгорает-то, что их любимый растик полторы платформы всего поддерживает.
Ну а какие ещё платформы нужны, вот по-честному? Кроме икс 86-64 и арм? Лигаси платформы не нужны, потому что кто под них будет переписывать? Надо новый код писать. А какой-нибудь авз микроконтроллер можно и на Си делать, там всё-таки проги должны быть маленькими и с памятью штык в штык работать (хотя кто-то вроде и Раст на микроконтроллеры запихивает).
> Ну а какие ещё платформы нужны, вот по-честному? Кроме икс 86-64 и
> арм?Растишечным хелловорлдам, действительно, и одного windows/x86_64 хватать должно.
Даже не могу поспорить, все так.
А не хелловордам? Ну хоть одна платформа не лигаси и не нишевая есть?
В продакшн версиях приложений на расте нет никаких проверок переполнения.
Откуда инфа? В расте вроде проверки никто вменяемый не выключает в сейф коде
Переполненые буфера - это прекрасно!
а кто юзал полноценно и libssh b libssh2? Первый я покурил хорошо, написал класс для работы с pty, реализовал sudo -u ser -i. В целом достаточно удобно. Единственное пришлось подумать как фиксировать конец потока, sleep не вариант ) пока не нулевая длинна блока тоже. Но там есть калбэки, возможно они вызываются когда происходит реальный конец вывода.
На libssh2 затэстил простой пример но не через pty. по факту что интереснее не сравнивал. У кого есть опыт с либами?
Расскажите, как ограничить возможность их использования в системе по максимуму, если их удалить нельзя, так как другие программы не работают без них.
Вероятно, пора перевестись в класс умственно отсталых по информатике и ВТ.
> Расскажите, как ограничить возможность их использования в системе по максимуму, если их
> удалить нельзя, так как другие программы не работают без них.Не совсем понимаю вопрос. вам для чего их удалять? Просто отключите сервис в системе и будет вам счастье.
"В качестве запасного метода защиты можно ограничить список поддерживаемых методов обмена ключами только алгоритмами с одинаковым размером хэша" - это же для решения проблем на сервере?
Можно перейти на telnet внутри vpn
> операция смены ключа допускает применение криптографических
> хэшей с размером слепка, отличающимся от первоначально использованного алгоритмаКто вообще придумал такое переобувание в полете?