The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

В ядре Linux выявлены эксплуатируемые уязвимости в POSIX CPU timer, cls_route и nf_tables, opennews (??), 10-Авг-22, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


63. "В ядре Linux выявлены эксплуатируемые уязвимости в POSIX CPU..."  +/
Сообщение от Анонн (?), 11-Авг-22, 10:53 
> при обработке нулевого дескриптора старый фильтр не удалялся из хэш-таблицы до очистки памяти
> приводит к обращению к освобождённой области памяти после удаления данной таблицы
> остаётся в списке, несмотря на очистку выделенной для хранения памяти

Пока что амна покушали сишники.
Добавление контейнеров, как и изменение любой логики, никак не должно влиять на такое. Это же классические проблемы с памятью. Они написали г0внокод и он просто не выстреливал им в ногу до поры до времени.
Но день настал))

В расте оно бы или просто не дало бы дважды обратиться к области памяти или бы запаниковало с выводом трейса (и эта паника скорее всего была бы перехвачена ядром чтобы не падать, а дальше залогированно и напр. перезапущен упавший сервис)
Что легко бы нашли во время тестирования или уже у юзеров (прям как сейчас))). Только на много лет раньше.

Ответить | Правка | Наверх | Cообщить модератору

69. "В ядре Linux выявлены эксплуатируемые уязвимости в POSIX CPU..."  –1 +/
Сообщение от Аноним (50), 11-Авг-22, 11:14 
В расте оно бы никогда не было написано.
Ответить | Правка | Наверх | Cообщить модератору

101. "В ядре Linux выявлены эксплуатируемые уязвимости в POSIX CPU..."  +1 +/
Сообщение от сишник (?), 11-Авг-22, 13:43 
Ну что, получается затролели вас растоманы, раз при любой уязвимости вы начинаете оправдываться?
Ответить | Правка | Наверх | Cообщить модератору

93. "В ядре Linux выявлены эксплуатируемые уязвимости в POSIX CPU..."  +/
Сообщение от Аноним (85), 11-Авг-22, 13:21 
Как я уже писал все структуры ядра сложные и связные. В расте в таких случаях unsafe сплошной. Кто там и что не дал бы сделать?
Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

106. "В ядре Linux выявлены эксплуатируемые уязвимости в POSIX CPU..."  +1 +/
Сообщение от сишник (?), 11-Авг-22, 14:17 
Затролен.
Ответить | Правка | Наверх | Cообщить модератору

116. "В ядре Linux выявлены эксплуатируемые уязвимости в POSIX CPU..."  +1 +/
Сообщение от Аноним (85), 11-Авг-22, 15:25 
Спасибо, что отчитываешься.

Но нам не интересно, затролен ты или нет.

Ответить | Правка | Наверх | Cообщить модератору

153. "В ядре Linux выявлены эксплуатируемые уязвимости в POSIX CPU..."  +/
Сообщение от Аноним (152), 12-Авг-22, 13:08 
> Пока что амна покушали сишники.

Да вообще охренеть внезапность! А кто еще? Ну не фуксики же, с их драйвером фата на игогошке? И не хрустики с редоксом, которые до такой крути всерьез если и дорвутся то лет так через много? Сейчас они явно не в форме ТАКИЕ фичи кодить.

> Добавление контейнеров, как и изменение любой логики, никак не должно влиять на такое.

С хрена ли? Это вся модель пермиссий и все допущения имеющие хоть какое-то отношение к всему этому идут лесом. В системе без контейнеров вон то по сути не вулн, ибо обладатель CAP_NET_ADMIN может пялить систему в хвост и гриву, чаще всего это рут же. А в контейнерах оно, видите ли, немного "виртуальное" и по задумке CAP_NET_ADMIN с гуеста уже хренсгары на хосте. И если он может что-то еще получить с этого - вот тут это рут, но не тот рут, и вот тут некоторые допущения не удержались. И как ты понимаешь есть сотни кода писаные ДО эпохи контейнеров, где допущения при кодинге про модель безопасности и результирующие проблемы сильно другие.

> Это же классические проблемы с памятью. Они написали г0внокод и
> он просто не выстреливал им в ногу до поры до времени.

Вон то скорее гибридное комбо, наполовину вылезающее из смены парадигм от реализации контейнеров.

> Но день настал))

Вокруг namespaces в линухе наверняка водится много всякого интересного. Потому что изначально его не кодили с namespaces in mind, а столь резкое изменение допущений в середине пьесы вообще-то провернуть проблематично, когда это не было частью дизайна сразу.

> скорее всего была бы перехвачена ядром чтобы не падать,

И чего при этом было бы? Я так понимаю что в хрусте нет способа корректно продолжить операцию если он panic() захотел. Парадигма у них вроде бы такая. Собственно 9 итерация патчей хруста состоят из борьбы с подобной хренью чуть менее чем полностью. В процессе оказалось что патчи стали огромные и начали напоминать месиво.

> а дальше залогированно и напр. перезапущен упавший сервис)

Это какой такой сервис вы собрались перезапускать при хрустиковом panic()-е в ядре? Кернел то? Ну да, юзеры обожают ребуты и паники.

> Что легко бы нашли во время тестирования или уже у юзеров (прям
> как сейчас))). Только на много лет раньше.

А вот это - ну не факт. Если кто хочет про память попиндеть, ядро под kasan и т.п. сейчас гоняют и он таки фатально валится при детекте проблем с памятью. А гугл и ко это к тому же делают под syzcaller'ом к тому же. У них там вообще забавная штука есть, syzbot. Сам fuzz'ит сам bisect'ит, сам баги пишет... небось и вон то отловлено какой-нибудь автоматикой типа этого.

Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру