В сетевой подсистеме ядра Linux выявлена уязвимость (CVE-2023-42752), позволяющая через манипуляции с сетевыми сокетами в пространстве пользователя перезаписать содержимое памяти ядра, что потенциально может использоваться для организации выполнение непривилегированным пользователем своего кода на уровне ядра. Уязвимость является локальной и не может быть эксплуатирована удалённо по сети. Включение механизма защиты SMAP (Supervisor Mode Access Prevention) в ядре блокирует проблему...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=59798
Хорошая демонстрация к недавней новости: https://www.opennet.dev/opennews/art.shtml?num=59791 "Модель полного переноса изменений выгодна прежде всего с точки зрения безопасности, так как, при выборочном переносе исправлений не всегда очевидна связь исправления с устранением потенциальных проблем с безопасностью. При полном переносе изменений проблема часто оказывается решена ещё до того, как появляется информация о том, что исправление блокирует уязвимость."С одной стороны, молча исправили 5 сентября и об уязвимости стало известно только 20 сентября, т.е. те кто переносят все исправления перенесли к себе исправление и оказались защищены.
C другой стороны, баг вызывающий уязвимость, бэкпортировали в старые LTS-ветки и т.е. кто переносят все исправления успешно перенесли к себе и баг с уязвимостью.
Получается палка о двух концах :-)
Любая палка она о двух концах. Палка о трёх концах это, как минимум, рогатка =)
Чтобы каждая палка была третьей..
Первое утверждение верно и для рогаки и для любой другой палки где N-концов > 2. ж)
Они, видимо, имели в ввиду отсутствие кровавого мерджинга изменений. Нам приходится тащить для особенных клиентов древние версии софта и это то ещё удовольствие патчи мержить по частям.
А у меня уже 2 недели как 6.5.3 :).
Нормальные посоны уже давно на 6.5.4 сидят.)
На 6.(9)
> Нормальные посоны уже давно на 6.5.4 сидят.)Федороводы? :)
На этой неделе не обновлялся, может уже и приехало в xanmod-оверлей.
>>давнотри дня как )))
нормальные пацаны на 3.10 сидят )))
Это какие-то ортодоксальные староверы.:)
староверы сидят на 2.6.х и 2.4 ))
(относительно) недавно была тема про дроп i386, от там они ныли и возбухали
А они что-то важное держат на старом селероне или туроне? Не знаю что даже сказать — разве что переходить на MenuetOS
Не могут себе позволить апгрейд на железо хотя бы прошлого десятилетия
День назад поставил 7.8.5, жизнь стала реально лучше.
А волосы шелковистые и не секутся? Поздравляю.
> Переполнение возникает из-за отсутствия должной проверки получаемых от пользователя параметровhahaha, classic
Ага, надо переписать на Rust ;)
Раст не защищает от логических ошибок (такие вещи автоматически можно отслеживать разве что в каких-нибудь языках с зависимыми типами а-ля Idris)
И Rust как не странно в этой проблеме не поможет. Тут только мозги человеческие нужны..
Баги тоже нужно бэкпортировать!
зато почти каждый день новое ядро
Мерилом работы считаем усталость.
Это про других же
> Включение механизма защиты SMAP (Supervisor Mode Access Prevention) в ядре блокирует проблему.А какие ещё механизмы затыкания пальцем уязвимостей они придумали?
> механизмы затыкания пальцем уязвимостейсанитайзеры, рандомайзеры, обнуляторы, WxorX, закладки в стек.
по-моему все.
Комитетов и ревьюаеров лишить премии!
Коммитера и ревьюверов
Как лешить нуля?
В минус
Похоже я знаю как сделать шаражку.
Что такое 'лешить'?
Отправить к лешему
4.19 божественен.
Нет, 5.4 и 5.10.
Игры хуже работает у которых как пояснили есть ограничение кадров в секунду.
>>Нет, 5.4 и 5.10.прикола ради перепрыгнул с 6.1 на 6.5,
такое впечателение, что с трактора на самолёт.
Считаешь с 2.6.32 уже можно переходить?
Господа, а в Gentoo (и возможно в арче) ванильное ядро? А то я убунтоид сижу аж на 20.04 в браузере новости ютуб телеграм всё работает и слоупочу со старым дырявым ядром и хочу стать прогрессивным как вы тут(((
20.04 до середины 24го года если авто-обновление настроено и комп перезагружаешь хоть иногда, то можешь не париться, будут фиксы приходить, а эту уязвимость тебе даже не бэкпортировали
Перезагрузка - после linux обновления - опасное действие, ну по крайней мере в Ubuntu.
И чем же оно опасно?
так не перезагружайся сразу, выжди сутки. В течении суток обычно на Манджаре прилетают хот фиксы, не знаю как в Бубунте
В Gentoo ядра на любой вкус, включая ванильные.
xanmod не очень.
> xanmod не очень.Чем именно? Стоит не гавкается.
Тем же,что описал выше. Как по мне так лучше РТ патчи накатить на 4.19
Чтобы свежее ядро собрать не обязательно быть на Gentoo. Скачать с kernel.org и собрать. Как собрать, статей найдётся предостаточно.
> Господа, а в Gentoo (и возможно в арче) ванильное ядро? А то
> я убунтоид сижу аж на 20.04 в браузере новости ютуб телеграм
> всё работает и слоупочу со старым дырявым ядром и хочу стать
> прогрессивным как вы тут(((У генты сейчас есть своё бинарное дистроядро, 6.4.16, если eix не врёт. Есть и всякие оверлеи + флаги - у меня например xanmod подключен, оттуда на момент послденего системного обновления приехало 6.5.3.
В раче есть rt, zen, libre, xanmod и ванильное, на любой вкус, в общем.
А я даже не знаю на каком я сижу ядре. Там в "О системе" наверняка написано, но что-то мне лениво туда заходить. Всё работает как всегда. Скучно.. :(
Ну как так то! Ну классика проверки же:
if (a + b < a)
/* overflow */
>if (a + b < a)Наивный...
Почитайте, как в Си работает undefined behavior. В вашем случае если оба значения signed integer (не важно какого размера, главное что не unsigned), то signed integer overflow является UB, и в лучшем случае компилятор должен выдать warning когда такое делают, в худшем случае уберёт эту проверку и грубо говоря подставит if (1).
Сильно изменится ситуация с unsigned вне дебага?
В случае беззнакового оно просто начнет считать с нуля, оно как бы не ub, но смысл тот же.Но на многих ЦП, на х86 всех точно, ЦП выставляет флаги в случае переполнения. Почему сишка не может их читать я не знаю. Но видимо нужно писать на ассемблере...
"Почитайте, как в Си работает undefined behavior." - после этого дальше можно не читать. Вы не очень понимаете, что такое undefined behavior.
Компилятор случаем не схлопывает такие проверки с флагами выше -O0 по принципу "сумма беззнаковых всегда больше слагаемого, а знаковое переполнение UB"?
а это может зависить от версии копилятора)
Теоретически может, но при разработке ядра (для ядра) есть описание по флагам и т.п., что включаем, а что нет. Известен же эпический rant Линуса по поводу какой-то новой на тот момент версии gcc, генерирующий дичь.
Вроде было про включенный по дефолту strict aliasing, с его запретом привычного type punning)
эта ситуация опять напомнила, что UB это костыли и злоизвестный пример https://godbolt.org/z/9j3Pxz
if (number > 0) {
number += 1;
if (number > 0) {
std::cout << number << " is a positive number.\n";
}
else {
std::cout << number << " is NOT a positive number.\n";
}
}в зависимости от уровня оптимизации -O0 или -O2 результат получается противоположный(!)
было бы классно чтобы программеры, которые это придумывали, зарплату получали в зависимости от фазы луны и подбрасывания монетки
Я так понимаю, что этот UB для того и сделан, что бы можно было оптимизацию производить.
ты это же не серьезно? правда?накой нужны такие оптимизации, которые полностью меняют поведение программы?
если нельзя написать код который "гарантированно и однозначно" сложит 2 инта...
"это просто какой-то позор" (с)
> если нельзя написать код который "гарантированно и однозначно" сложит 2 инта...У тебя поведение зависит от архитектуры (железа) и оно однозначно: результат то сложения одинаков.
Вот сравнение да - для его выполнения идет учет UB.
UB дает возможность как угодно оптимизироватьКак хотим так и делаем.
Хочешь повторяемости - не дай оптимизации использовать UB;
Сделай так:number += 1;
int number1 = number;
if (number1 > 0)
{
}
Т.е выход из ситуации, просто подстраиваться под так называемый "стандарт"?> У тебя поведение зависит от архитектуры (железа) и оно однозначно: результат то сложения одинаков.
Я вот это не очень понимаю ¯\_(ツ)_/¯
У меня есть мой код и железо;
Железо и код не поменялись, но компилятор обновил мажорную версию;
Прога которая просто одевала ботинок, теперь отстреливает ногуИли я просто скомпилил один и тот же код, в дебаге и релизе (что может менять уровень оптимизации).
> Т.е выход из ситуации, просто подстраиваться под так называемый "стандарт"?Выхода 2:
1. Ты знаешь стандарт и работаешь по нему. Тут тебе по-барабану тонкости работы с железом.
2. Ты знаешь железо и компилятор и работаешь по ним. Так работают в ядре, потому что тонкости работы с железом, тут черезвычайно важны.Ну и третий. Работай с другим языком. Там будут свои трудности и ограничения, но это уже другая история.
понятно
тогда я наверное предпочту сменить язык)потому что проверять список UB при написании простейших "a + b" не слишком хочется
вот список УБшек для "стандарта" С99 https://gist.github.com/Earnestly/7c903f481ff9d29a3dd1
всего-то 193 штуки
думаю для 17 и 2х список еще большехорошо, что в последннее время все больше людей убеждаются, что "дальше так жить нельзя"
надеюсь такие подходы уйдут в лету вместе с языком
> хорошо, что в последннее время все больше людей убеждаются, что "дальше так жить нельзя"
> надеюсь такие подходы уйдут в лету вместе с языкомА вот это вряд ли. Тут или переносимость и возможности оптимизации, тогда UB необходим.
Или все регламентировано, но тогда не переносимости, не возможностей оптимизации.Переносимость еще можно добавить, используя свой рантайм. За счёт производительности естественно.
Но это если с железом работать не надо, если надо, тогда ОЙ!Выбирая язык другого типа ты меняешь нишу программирования.
> тогда UB необходим.А давно у нас #ifdef запретили?
Пиши валидный код без UB, просто для каждой платформы.
>> тогда UB необходим.
> А давно у нас #ifdef запретили?
> Пиши валидный код без UB, просто для каждой платформы.Вы КО.
Это и есть способ обрабатывать UB.Вот только есть языки, с жесткой заточкой на безопасность программирования, у них игры с #ifdef становятся неподъемными.
> есть языки, с жесткой заточкой на безопасность программирования,например? MISRA C? ADA?
поэтому у нас будут UB и код без безопастности)
отличный план, надежный как швейцарские часы!
Для каждой комбинации железа версии и типа компилятора и флагов оптимизации.
А можно подробнее про "поведение зависит от архитектуры (железа)"?
Для какого железа из такого кода нельзя получить одинаковые результаты?Т.е. напр. мы хотим получить saturating add, но один проц так не делает по умолчанию, а другой делает.
Что мешает просто для первого заменить маш код нативной суммы на нужное нам поведение во время компиляции?
Тогда на всех платформах будет однозначное поведение, а не вот это вот.
> заменить маш код нативной суммы на нужное нам поведение во время компиляции?Зачем тогда ориентироваться на железо? Таскай свой рантайм и работай на нём. Тогда всегда всё будет предопределено.
возможно это будет лучше чем получение уязвимостей
> возможно это будет лучше чем получение уязвимостейВозможно.
Если бы победил, какой-либо рантайм и десятилетиями потом не менялся. Почти как java, в свое время.Но есть и другая сторона.
Множество разных рантаймов для разных языков приводит к нехватке ресурсов на разработку необходимого.К обилию плохого качества повторно используемого кода.
А вот тут уже есть варианты относительно "возможно".
Рантайм то тут причем?Переполнение и интовая арифметика банальная и очень болезненная проблема.
Сделать гарантированные функции и функции на прямую дергаюшие железо.
И все будут довольны.
Ну и при проверке размера буфера какая ориентация на железо вообще может быть? Оно должно считать правильно всегда и везде простую арифметику.
А в чем собственно оптимизация?
Тут выхлоп в виде ассемблера не смотрел, но очевидно, перенос сравнения на этап компиляции.
префразирую классику
те кто разменивают скорость на безопастность, получают и уязвимости, и тратят время на их исправление
> префразирую классику
> те кто разменивают скорость на безопастность, получают и уязвимости, и тратят время
> на их исправлениеСледует уточнить, что скорость - скорость выполнения кода.
Время - время разработки.
Уязвимости - слишком сужено. Ошибки, среди которых могут быть и уязвимости.
Ну а как бороться с ошибками?
Тесты, тесты и еще раз тесты. Причём в разном окружении. Что там насчёт CI?
неа, время - это не только разработка
это еще время на фикс, на тестирование, на обновление кода на уязвимых машинах
если тебе нужно обновить ядро на серваке тк уязвимость с повышением привилегий - то время простоя, это потерянные деньги> Ошибки, среди которых могут быть и уязвимости
логические ошибки к ub не относятся, так код будет работать однозначно неправильно
но если посмотреть на CVEшки через которые напр. получается рут - то там по большей часть проблемы с памятью, bout-of-bounds, ase-after-free и тднапример в С++ Dereferencing a NULL pointer это UB
> Что там насчёт CI?
хз, если честно
надеюсь там тесты есть, включая фаззинг, но тесты пишут люди и часто на том же языке
UB это наследие тех времён, когда на некторых архитектурах байты были 9 бит, а слова - 36. И каждый из производителей железа тащил в свою сторону. Это сейчас, по большому счёту осталось только 2 платформы - x86_64 и ARM. У которых и индейцы совпадают, и float IEEE-шный, но так было не всегда..Если Вам надо гарантировано обрабатывать переполнение, в случае gcc добавьте -fwrapv. Кроме того, можно воспользоваться __builtin_sadd_overflow()/__builtin_ssub_overflow(). В стандарте С23 эту функциональность стандартизируют в форме ckd_add()/ckd_sub().
> В стандарте С23 эту функциональность стандартизируют в форме ckd_add()/ckd_sub().Ура! Не прошло и 30 лет.
спасибо, спасибо очень помогловот только ядро до сих пор на древнем С11 (и перешли они туда в 22м году!)
причем не на стандартном ISO С, а на богомерзких гнутых расширениях gnu11
> вот только ядро до сих пор на древнем С11 (и перешли они туда в 22м году!)ну, как-бы, после C11 был C17, в котором ничего нового не добавили, а просто поправили накопившиеся замечания. А в C11, по сравнению с C99, имхо, более-менее полезными были alignas/alignof и анонимные структуры и объединения (которые существовали в виде расширений уже довольно давноЮ по-моему ещё в древнем bcc 3.1 уже были)ю
> причем не на стандартном ISO С, а на богомерзких гнутых расширениях gnu11
ну, как-бы builtin-ы, насколько я помню не зависят от версии языка, а -fwrapv существует уже очень давно, как минимум точно есть в gcc 4.8+.
"Я тебя полюбил, я тебя научу" (с)
См. флаг -fwrapv
тормозить будет(
хотя да, предлагали
https://bugzilla.kernel.org/show_bug.cgi?id=12597
Пользуйтесь статическими анализаторами, и Раст будет не нужен.
Да, пользуйтесь статическими анализаторами!
И тогда вам не только придется фиксить классический баг, но и бекпортить еще в кучу старых веток.
но тогда придется переписать почти все ядро, тк там дидами хаков закопано %(
Вот поэтому раст и не взлетел - мешает работать, уязвимости оставлять!
>Пользуйтесь статическими анализаторами, и Раст будет не нужен.Так обычно пишут на форумах люди, которые сами ни разу статическими анализаторами не пользовались.
> статическими анализаторамиКроме нас двоих остальные и слов то таких не знают, так что твой коммент это крик в пустоту.
ну так ядро ими со всех сторон обмазано? обмазано же?
так чего столько CVEшек ?
гугл, собрав свою статистику по си/плюсовым проектам, заявляет, что использование разных техник программирования, всевозможных анализаторов и фаззинг-тестирования не очень помогает:"...We continue to invest in tools to improve the safety of our C/C++. Over the past few releases we’ve introduced the Scudo hardened allocator, HWASAN, GWP-ASAN, and KFENCE on production Android devices. We’ve also increased our fuzzing coverage on our existing code base. Vulnerabilities found using these tools contributed both to prevention of vulnerabilities in new code as well as vulnerabilities found in old code that are included in the above evaluation. These are important tools, and critically important for our C/C++ code. However, these alone do not account for the large shift in vulnerabilities that we’re seeing, and other projects that have deployed these technologies have not seen a major shift in their vulnerability composition. We believe Android’s ongoing shift from memory-unsafe to memory-safe languages is a major factor... "
Отсюда:
"Memory Safe Languages in Android 13"
https://security.googleblog.com/2022/12/memory-safe-language...гуглу я доверяю в _этом_ вопросе гораздо больше, чем тебе, брат аноним.
> ... We believe Android’s ongoing shift from memory-unsafe to memory-safe languages is a major factor... "
> гуглу я доверяю в _этом_ вопросе гораздо больше, чем тебе, брат аноним.Ну, а на чём основано доверие им в *этом* вопросе? -
Может они просто обставляют ситуацию для перетягивания всего что можно в "memory-safe languages"?Кто-то писал (не могу найти кто) - что какой-то чудак (автор?) убедил гугел что разработка языка Gо решит какие-то вопросы с параллелизмом, а на самом деле - просто протащил финансирование своих идей.
Думаю что нужно смотреть - "кому выгодно". И исходя уже из этого знания (а не из *какогототамдоверия*) делать выводы.
Блин, а где нормальный список уязвимых версий посмотреть? В ветку v5.15 этот коммит походу не был бэкпортирован.
а зачем? ты что не любишь сюрпризы?
тебе это дает невереоятную возможность почиатать релиз ноуты, посмотреть код,
возможно даже самостоятельно что-то бекпортнуть и собрать ядро ручками!просто манна небесная для пользователя линукса!
Ну я уже порадовался что надо разобраться что есть в `torvalds/linux`, и что есть в `stable/linux`, и освежил в памяти что существует `git tag --contains`. Но видимо что-то не докопал, откуда-то же взялось 5.15 в новости?
>Уязвимость вызвана изменением, внесённым в ядро 6.2, но данное изменение было бэкпортировано во все LTS-ветки, поэтому уязвимость проявляется и в более ранних выпусках поддерживаемых стабильных веток ядра.Обожаю такое!
Ничего необычного просто результат деградации специалистов.
Да, при чём эта деградация началась ещё в 1972 году.
Просто какое-то сишное бинго.
буффер + Integer overflow + UB = LCE
>Включение механизма защиты SMAP (Supervisor Mode Access Prevention) в ядре блокирует проблему.Ну значит можно и не фиксить. Те, у кого камень без поддержки SMAP, сами виноваты и могут идти туда, куда Полонский послал.
а много ли таких хотя бы более-менее актуальных процов есть?
так всё было понятно,
в репах Gentoo появились ревизии 6.1.53-r1, 6.5.3-r1.это значит - срочно латали дыру.
вот, теперь выяснили в чём дело.