The OpenNET Project / Index page

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



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

Оглавление

Уязвимости в беспроводном стеке ядра Linux, допускающие удалённое выполнение кода, opennews (??), 13-Окт-22, (0) [смотреть все]

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


18. "Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."  –6 +/
Сообщение от Шарп (ok), 13-Окт-22, 23:30 
>обращение к уже освобождённой области памяти (use-after-free)

rust

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

28. "Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."  +7 +/
Сообщение от Аноним (21), 14-Окт-22, 01:01 
А что насчёт использования файлового дескриптора после закрытия файла?
Использования ресурса после снятия эксклюзивной блокировки на него?
Удаление элемента из коллекции в процессе итерирования и неучёт этого при дальнейших итерациях?
Обращение к процессу после его завершения?

Это всё use-after-free в каком-то смысле. Раст от этого тоже защищает? Или он просто обучает программиста не париться по поводу use-after-free в случае с памятью, так что тот и в других похожих случаях не будет над этим заморачиваться.

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

30. "Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."  –7 +/
Сообщение от Шарп (ok), 14-Окт-22, 01:12 
> Удаление элемента из коллекции в процессе итерирования и неучёт этого при дальнейших итерациях?

Такое может произойти в связных списках. А раст не осилил связные списки. Так что мимо. Просто признай, что ты растохейтер.

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

38. "Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."  +2 +/
Сообщение от Аноним (38), 14-Окт-22, 01:52 
> раст не осилил связные списки

понятно, почему на расте сложнее хеловорлда не пишут.

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

219. "Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."  +/
Сообщение от Аноним (219), 18-Окт-22, 02:22 
Настолько не осилил, что LinkedList есть в стандартной библиотеке.
Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

31. "Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."  –4 +/
Сообщение от Rev (?), 14-Окт-22, 01:14 
Да, если канонично писать на Расте, то защищает.
Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

39. "Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."  +/
Сообщение от Аноним (38), 14-Окт-22, 01:53 
> канонично

причащаться и ходить на исповеди тоже надо?

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

43. "Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."  –1 +/
Сообщение от Аноним (43), 14-Окт-22, 04:17 
он имел ввиду тотальное использование C, асма и сишных библиотек, а раст юзать только в качестве обёртки, ну и чтоб скобочек больше было
Ответить | Правка | Наверх | Cообщить модератору

57. "Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."  +1 +/
Сообщение от Аноним (57), 14-Окт-22, 08:11 
Удалить элемент из коллекции при итерировании точно не получится - для этого должна быть одновременно mut ссылка (для удаления) и обычная для итератора. А такое отсекает компилятор легко. Это распространяется на все объекты(ресурсы, дескрипторы). На счёт завершенных процессов - хз, не сталкивался
Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

118. "Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."  +/
Сообщение от Аноним (118), 14-Окт-22, 17:27 
в расте Drain итератор есть
Ответить | Правка | Наверх | Cообщить модератору

89. "Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."  +/
Сообщение от Аноним (89), 14-Окт-22, 12:45 
Это всё моделируется через систему типов и дальше отслеживается при компиляции. См rust newtype pattern.
Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

91. "Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."  +3 +/
Сообщение от Аноним (91), 14-Окт-22, 12:57 
От всего перечисленного защищает, кроме последнего. Поскольку Inter process communication не определяется компиляторами и не должен.
Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

122. "Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."  +/
Сообщение от PnD (??), 14-Окт-22, 17:54 
Ещё можно права на записываемый файл в "-1" выставить. Как один новоиспечённый сотрудник micro$oft, года 3 назад, когда ещё в RH работал. (Не слышно пока о его творческих успехах на новом месте. Не иначе как NDA.)
А что такого, это ведь не ошибка?
Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

177. "Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."  +/
Сообщение от Аноним (192), 15-Окт-22, 17:55 
Можно. И нужно. Иначе как ты узнаешь, что твоё ядро и рантайм на самом деле из соплей и веток, и не защищают ни от чего вообще?
Ответить | Правка | Наверх | Cообщить модератору

187. "Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."  +1 +/
Сообщение от freecoder (ok), 15-Окт-22, 22:59 
> А что насчёт использования файлового дескриптора после закрытия файла?

Если использовать File из std, то он закрывается автоматически при уничтожении объекта. Уничтожить объект File - единственный способ закрыть файл. Так как объект уничтожен, то использовать после закрытия нечего.

> Использования ресурса после снятия эксклюзивной блокировки на него?

В std и прочих библиотеках в Rust примитивы синхронизации пишут так, что они владеют объектом, который синхронизируют. И API примитивов устроен таким образом, что невозможно получить доступ к объекту без того, чтобы не получить блокировку (если предполагается изменение объекта). Снятие блокировки происходит при уничтожении объекта-гарда, но именно через него только и возможен доступ к исходному защищенному объекту. После уничтожения доступ к объекту получить не откуда.

> Удаление элемента из коллекции в процессе итерирования и неучёт этого при дальнейших итерациях?

Со стандартными итераторами в Rust невозможно удалить объект в процессе итерирования. Дело в том, что вы когда итерируетесь, вы должны заимствовать коллекцию по ссылке (изменяемой или неизменяемой). Но для удаления объекта вам также необходимо иметь изменяемую ссылку на коллекцию. Но в процессе итерирования у вас уже используется одна ссылка, а правила заимствования разрешают мутабельной ссылке быть только уникальной. Так что компилятор не допустит изменяемого обращения по ссылке, когда в скопе уже есть другое заимствование (на сам итератор).

> Обращение к процессу после его завершения?

Поясните, какие обращения к процессу вы имеете ввиду?

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

69. "Уязвимости в беспроводном стеке ядра Linux, допускающие удал..."  +/
Сообщение от Аноним (69), 14-Окт-22, 09:52 
carbon
Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

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

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




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

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