The OpenNET Project / Index page

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



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

"Предложен метод эксплуатации разыменования NULL-указателей в ядре Linux"  +/
Сообщение от opennews (??), 20-Янв-23, 10:11 
Исследователи из команды Google Project Zero разработали метод эксплуатации уязвимостей в ядре Linux, вызванных разыменованием указателей NULL. До сих пор проблемам в ядре, связанным с разыменованием указателей NULL, не уделялось должного внимания, так как доведение таких проблем до атак, приводящих к повышению привилегий или выполнению своего кода, считалось нереалистичным (непривилегированным процессам запрещён маппинг в нижней области адресного пространства). Как правило подобные ошибки приводят к генерации ядром oops-предупреждений, после которых проблемные задачи завершаются и состояние восстанавливается без необходимости остановки работы системы...

Подробнее: https://www.opennet.me/opennews/art.shtml?num=58518

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

Оглавление

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


1. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +43 +/
Сообщение от Аноним (1), 20-Янв-23, 10:11 
Что-то решение с лимитом oops'ов, после которых следует panic, выглядит каким-то жутким костылищем.
Ответить | Правка | Наверх | Cообщить модератору

3. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (3), 20-Янв-23, 10:18 
Стандартная проблема. Типа если вместо этого везде напихать проверок на NULL, то производительность понизится.
Ответить | Правка | Наверх | Cообщить модератору

35. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +6 +/
Сообщение от InuYasha (??), 20-Янв-23, 12:15 
Просто обнулить refcount, как я понял, нельзя? Не понимаю проблемы с событием, которое УЖЕ ловится и спокойно предотвращается. :-/
Ответить | Правка | Наверх | Cообщить модератору

61. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +2 +/
Сообщение от Аноним (61), 20-Янв-23, 13:31 
Более практичный способ: отслеживать долгие чужие процессы... Ой! А откуда взялся чужой процесс? Кто принёс файл эксплоита и сделал его исполняемым?
Ответить | Правка | Наверх | Cообщить модератору

147. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Бил Гейтс (?), 22-Янв-23, 11:37 
Осталось понять какой процесс "чужой"
Ответить | Правка | Наверх | Cообщить модератору

161. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (61), 23-Янв-23, 14:55 
Ну смотри, есть сервер, как на него попадают программы? Либо ты сам поставил (в этом случае защищать что-то бесполезно от ССЗБ), либо кто-то как-то по сети... Отсюда и начинаем плясать: почему есть дыра для установки троянов?!
Ответить | Правка | Наверх | Cообщить модератору

160. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (61), 23-Янв-23, 14:51 
> везде напихать проверок на NULL

Для начала - замораживать счётчик на -1, чтобы не было переполнения.

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

7. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +1 +/
Сообщение от Аноним (7), 20-Янв-23, 10:37 
Что-то подсказывает, что refcount должно сделать 64-битным...
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

53. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +3 +/
Сообщение от Аноним (61), 20-Янв-23, 13:00 
> особенности обработки состояний "oops", в результате которых можно добиться увеличения значения счётчика

Что-то подсказывает, что копать надо ^^^туда^^^. Что значит "можно добиться"?!

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

56. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +1 +/
Сообщение от warlock66613email (ok), 20-Янв-23, 13:11 
Вот это как раз вообще не решение. И 64-битный счётчик может переполнится, просто на это нужно чуть больше времени.
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

70. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +2 +/
Сообщение от Аноним (7), 20-Янв-23, 14:00 
Да. примерно на 8 * 2^32 дней.
Ответить | Правка | Наверх | Cообщить модератору

73. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +3 +/
Сообщение от Аноним (73), 20-Янв-23, 14:03 
ага, тока если с 32 разрядами они справились за 8 дней, то с 64 разрядами уйдёт всего лишь 2^35 дней, что займёт больше 90 миллионов лет
Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

77. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +6 +/
Сообщение от Массоны Рептилоиды (?), 20-Янв-23, 14:28 
А мы никуда не торопимся
Ответить | Правка | Наверх | Cообщить модератору

102. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +1 +/
Сообщение от Аноним (-), 20-Янв-23, 19:11 
А типичный компьютер проработает 90 млн лет? Вам придется землянам технологии проапгрейдить малость на более надежные.

// учитесь нубы как алиенов на технологии разводить надо!

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

104. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от warlock66613email (ok), 20-Янв-23, 19:58 
Хороший программист и хороший код не должен опираться на такие соображения. Дело не в том, проработает компьютер или нет. Дело в том, что если программа предполагает что не проработает, ей место в мусорке.
Ответить | Правка | Наверх | Cообщить модератору

112. "Предложен метод эксплуатации разыменования NULL-указателей в..."  –1 +/
Сообщение от Аноним (73), 20-Янв-23, 21:41 
90 миллионов лет без единого разрыва !!!
== Антон Уральский ==
Ответить | Правка | Наверх | Cообщить модератору

113. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (113), 20-Янв-23, 22:00 
Вот это ты щас быканул на всю криптографию, которая и опирается на то, что единственный гарантированный способ взлома (брутфорс) на текущих возможностях электронно-вычислительной техники займет нецелесообразное количество времени (миллионы лет). Опора на "соображения" зависит от предметной области и "правила игры" в ней. Но я согласен с одним из предыдущих комментаторов, что лимит oops это инфернальный костыль и нормальные люди тупо расширяют диапазон значений до 64 бит. В цифровую эпоху многие проблемы прямее всего решаются расширением диапазона - Unicode, IPv6, например.
Ответить | Правка | К родителю #104 | Наверх | Cообщить модератору

115. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от warlock66613email (ok), 20-Янв-23, 22:17 
Вопрос в том, что значит "опирается". Что случится если кто-то забрутфорсит пароль? Ничего, всё будет работать нормально. Это штатная ситуация для ПО. А тут произойдёт нарушение внутреннего инварианта программы. Вот этого быть не должно. Ожидать что временный файл созданный с помощью гуида не совпадёт с существующим файлом никогда — это нормально. Не вписать проверку и не предусмотреть действий в случае если всё же гуиды совпали — не нормально.
Ответить | Правка | Наверх | Cообщить модератору

121. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (121), 20-Янв-23, 23:11 
> Вопрос в том, что значит "опирается". Что случится если кто-то забрутфорсит пароль?

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

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

125. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от warlock66613email (ok), 21-Янв-23, 01:10 
Вы смотрите с точки зрения пользователя, а я с точки зрения программиста, которому не платят за работу. С точки зрения программиста мне надо чтобы моя программа работала правильно, а кто там к чему получит доступ мне не важно.
Ответить | Правка | Наверх | Cообщить модератору

132. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (-), 21-Янв-23, 18:16 
> а я с точки зрения программиста, которому не платят за работу.

В этих допущениях можно довольно далеко зайти.

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

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

> а кто там к чему получит доступ мне не важно.

Сферический перфекционизм в вакууме. Ну понятно, небось еще и бсды используете, с таким паттерном мышления было бы не удивительно.

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

133. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от warlock66613email (ok), 21-Янв-23, 19:27 
> Ну понятно, небось еще и бсды используете, с таким паттерном мышления было бы не удивительно.

Бинго!

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

141. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (-), 21-Янв-23, 22:25 
Булшит бинго. Возможно бесконечное количество абстракций, а идеал недостижим. Поэтому главное во всей этой гонке за идеалом - уметь вовремя остановиться, зафиксировать достижения, и сделать из этого что-то практически полезное. Иначе может так получиться что нео сольется с матрицей, релиз чего-то адекватного не состоится никогда, ведь в погоне за идеалом можно забыть зачем вся эта канитель вообще затеяна. И вот именно BSD явяляют собой очень хороший пример вот этого вот. Где-то в своих кельях господа из Беркелея давно забыли зачем люди пользуются компьютерами, имея на этот счет какие-то свои, весьма синтетические идеи.

...поэтому я предпочитаю уметь вовремя остановиться в гонке за абстракциями. И если программа сломается через 100 лет - мое чувство идеала останется недовольным, но, а знаете что, проблемы лучше решать по мере их поступления. Может, программа через 100 лет никому не потребуется. Ну, мало ли, появится пять штук лучше. Или квантовые компьютеры сменят некоторые парадигмы. Или AI всех двуногих в зоо определит, и будет ржать с потуг "этих примитивных амеб". Ну и зачем мне спрашивается мое время здесь и сейчас на полирование хрома тратить? Пусть кому актуально и потратит его - когда - и если - это станет актуально.

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

146. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от warlock66613email (ok), 21-Янв-23, 23:11 
> Где-то в своих кельях господа из Беркелея давно забыли зачем люди пользуются компьютерами, имея на этот счет какие-то свои, весьма синтетические идеи.

Именно так рождался Линукс и много другого замечательных вещей, без которых была бы одна винда.

> сделать из этого что-то практически полезное

Сделать что-то практически полезное — это замечательно, но сделать что-то практически бесполезное, по-моему, гораздо круче.

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

150. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +1 +/
Сообщение от Аноним (-), 22-Янв-23, 19:03 
> Именно так рождался Линукс и много другого замечательных вещей,

Линукс появился, когда некий студент устал ждать когда его осчастливят академики. Одни академики в лице таненбаума занимались черти чем, наворачивая концепции с ... рестриктивной лицензией и игнором насущных проблем пользователей. Другие пшикали на то что 386 это фи, покупайте другие процы. Третьих судил AT&T за то что они посмели возомнить себя равными с коопорацией и играть не в одни ворота, взяв их код. Куда бедному студню было податься? Он послал этот бред в пень да и сделал свое, как работало.

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

> без которых была бы одна винда.

NT так то нормальное ядро, деланое командой VAX, чтоли. Но маркетинг все изгадил, разумеется. Если кто думает что линух нельзя изгадить так же, может посмотреть на андроида. Но там в силу опенсорсности больше возможностей потрепыхаться.

> Сделать что-то практически полезное — это замечательно, но сделать что-то практически
> бесполезное, по-моему, гораздо круче.

Ну тут уж кому что. Мне интересны работающие компьютерные системы решающие те или иные задачи, чтобы sci-fi стал реальностью, все такое. Для этого мне нужны цифровые инженерные и компьютерные системы. И совсем уж бесподезные системы мне не интересны. Странно понимать прелести электричества и магнитизма и при этом сидеть в пещере у костра.

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

118. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (118), 20-Янв-23, 23:02 
> Хороший программист и хороший код не должен опираться на такие соображения. Дело
> не в том, проработает компьютер или нет. Дело в том, что
> если программа предполагает что не проработает, ей место в мусорке.

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

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

154. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от (?), 23-Янв-23, 01:35 
блин, это теперь везде регексп 20[0-9]{2}-[0-9]{2}-[0-9]{2} везде переписывать, и что писать то?
2[01][0-9]{2}, или [0-9]{4,}-[0-9]{2}-[0-9]{2}, да ну бред же, и так полно корявого ПО которое допускает ввод дат из других веков, а ты блин сиди и думай где и как опечатка была.
Ответить | Правка | К родителю #104 | Наверх | Cообщить модератору

155. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от warlock66613email (ok), 23-Янв-23, 02:36 
> блин, это теперь везде регексп 20[0-9]{2}-[0-9]{2}-[0-9]{2} везде переписывать

Зачем? Ограничение, разумное или даже нет, — это нормально. Программа не обязана поддерживать произвольные даты. Никакие внутренние инварианты от этого не нарушатся, и программа будет одинаково хорошо (или плохо) работать что в 20 веке, что в 100-м и это никак не помешает ей быть запущенной в 20 веке и проработать непрерывно до сотого.

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

167. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от (?), 25-Янв-23, 09:19 
> Зачем? Ограничение, разумное или даже нет, — это нормально.

Ну это вроде стеб был, у всего есть границы применимости

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

78. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +2 +/
Сообщение от Аноним (78), 20-Янв-23, 14:44 
А если каждый упс добавить паузу в 0.1 секунду
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

162. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от pavlinux (ok), 23-Янв-23, 22:44 
а я кол-во тредов увеличу на 10
Ответить | Правка | Наверх | Cообщить модератору

165. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от _kp (ok), 24-Янв-23, 01:44 
Ну может и не каждый чих, а то такие ли драйвера бывают, да ещё умудряются как то работать с мешком ошибок, но ход мысли нормальный.
Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

11. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +6 +/
Сообщение от topin89 (ok), 20-Янв-23, 11:00 
Это он и есть. И это замена шила на мыла теперь это DoS-атака.

> После достижения лимита, который по умолчанию выставлен в 10 тысяч oops (при желании можно изменить через параметр oops_limit), ядро будет инициировать переход в состояние "panic" с последующей перезагрузкой

10000 срабатываний это примерно 2**log2(10000) ~= 2^13 срабатываний. Простая арифметика говорит, что если 2^32 делает систему уязвимой за 8 дней, то с патчем система вешается за 8 * (2^13/2^32) * 24 * 60 * 60 == 1.3 секунды. Отличное исправление, что тут скажешь. С другой стороны, хотя бы о попытке станет известно мгновенно

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

120. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +2 +/
Сообщение от Аноним (118), 20-Янв-23, 23:03 
Не вешается а паникует. Ну и собственно если у вас 10K OOPSов вылезло, у вас точно что-то идет сильно не так и вы врядли хотите чтобы это продолжало работать. OOPS для начала означает ошибку ядра после которой гарантии корректной работы системы уже нет.
Ответить | Правка | Наверх | Cообщить модератору

124. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (124), 21-Янв-23, 01:09 
В новости же написано, что можно выставить кастомное количество упсов.
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

14. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +2 +/
Сообщение от Бывалый смузихлёб (?), 20-Янв-23, 11:15 
иначе слишком ресурсоёмко чужие серваки ронять
а тут - по быстрому прогнал, в лимит упёрся и система ушла в перезагрузку
причём, можно умудриться чтобы из цикла перезагрузки система практически не выходила - только загрузилась - загрузилась вирусяка - опять лимит - опять перезагрузка
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

26. "Предложен метод эксплуатации разыменования NULL-указателей в..."  –3 +/
Сообщение от Аноним (26), 20-Янв-23, 11:54 
Это костыльное решение проблемы oopsов в неподдерживаемых драйверах. Ибо нефиг деньгой поддерживать корпорации, которые проприетарные драйверы делают, но не делают их качественно. И ибо нефиг в ядре держать неподдерживаемые драйвера, делающие oopsы. С растом их станет меньше.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

43. "Предложен метод эксплуатации разыменования NULL-указателей в..."  –1 +/
Сообщение от Деанон (?), 20-Янв-23, 12:28 
Ключевое слово, что станет меньше. И хакать смогут лишь те, кто может это финансово и по мощностям это себе позволять.
Ответить | Правка | Наверх | Cообщить модератору

62. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +1 +/
Сообщение от Аноним (61), 20-Янв-23, 13:32 
> С растом их станет меньше.

Естественно, меньше. Нет кода - нет проблем.

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

79. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +2 +/
Сообщение от Аноним (79), 20-Янв-23, 14:47 
С растом будут новые проблемы, скорее всего даже хуже
Потом не говорите что я не предупреждал.
Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

83. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Admino (ok), 20-Янв-23, 15:54 
Десять тысяч упсов у ядра само по себе уже достаточный повод для паники.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

4. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (4), 20-Янв-23, 10:26 
Гугл молодец, хороших спецов нашёл. Прямо уважение им от анонима.
Ответить | Правка | Наверх | Cообщить модератору

5. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +5 +/
Сообщение от аноним2 (?), 20-Янв-23, 10:31 
Работал, сервер, работал и вдруг перезагрузился.
Oops it did it again, this limit system reboot this world.
Ответить | Правка | Наверх | Cообщить модератору

46. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +10 +/
Сообщение от Zenitur (ok), 20-Янв-23, 12:34 
10000 kernel oops = 1 kernel ёпс
Ответить | Правка | Наверх | Cообщить модератору

48. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (48), 20-Янв-23, 12:37 
Значит нужно настроить лимит на 20000000000 упсов
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

63. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (61), 20-Янв-23, 13:34 
> Работал, сервер, работал

Вопрос: как на сервере оказался исполняемый эксплоит и кто его запустил?

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

64. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +2 +/
Сообщение от Аноним (61), 20-Янв-23, 13:36 
Вдогонку: а никого не будет смущать, что на сервере 8 дней вертится какой-то левый юзер?
Ответить | Правка | Наверх | Cообщить модератору

103. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +1 +/
Сообщение от Аноним (-), 20-Янв-23, 19:13 
Алсо с таким числом oops'ов на диске, вероятно, закончится место под логи. О том что это будет дико грузить систему даже упоминать неудобно. Перцы из гугли возвели хакеров и солонки на новый уровень.
Ответить | Правка | Наверх | Cообщить модератору

131. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (131), 21-Янв-23, 16:31 
Это смотря сколько серверов. Если один-два, то конечно. А если сотни тысяч, как у гугла, то никто и не заметит.
Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

138. "Предложен метод эксплуатации разыменования NULL-указателей в..."  –1 +/
Сообщение от Аноним (61), 21-Янв-23, 22:13 
> никто и не заметит

Ну да, там в гугле только вручную ходят по компам в ДЦ и проверяют, тыкая в клавиши...

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

142. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (-), 21-Янв-23, 22:27 
> Это смотря сколько серверов. Если один-два, то конечно. А если сотни тысяч,
> как у гугла, то никто и не заметит.

Кроме аналитики и логинга ловящих аномалии и сбои, ога.

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

6. "Предложен метод эксплуатации разыменования NULL-указателей в..."  –53 +/
Сообщение от pashev.ru (?), 20-Янв-23, 10:32 
Надопросто добавить ещё один счётчик, который увеличивается на единицу, когда счётчик oops переполняется. Назовём новый счетчик wtf.
Ответить | Правка | Наверх | Cообщить модератору

8. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от 1 (??), 20-Янв-23, 10:45 
Ну дык - в 2.7 это и предложено ...
Я бы сделал счётчик oops 256 битным
Ответить | Правка | Наверх | Cообщить модератору

9. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (9), 20-Янв-23, 10:46 
называй, разрешаю
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

18. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (18), 20-Янв-23, 11:22 
Выше предложили более лочичное увеличение разрядности существующего.
Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

25. "Предложен метод эксплуатации разыменования NULL-указателей в..."  –1 +/
Сообщение от pashev.ru (?), 20-Янв-23, 11:53 
> Выше предложили более лочичное увеличение разрядности существующего.

Лол. Я предложил то же самое. Вон из профессии! 🤗

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

95. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Конь (?), 20-Янв-23, 18:22 
Создать второй счётчик и сменить тип у первого, это не одно и тоже, поэтому это тогда тебя нужно гнать
Ответить | Правка | Наверх | Cообщить модератору

123. "Предложен метод эксплуатации разыменования NULL-указателей в..."  –1 +/
Сообщение от pashev.ru (?), 20-Янв-23, 23:29 
> Создать второй счётчик и сменить тип у первого, это не одно и
> тоже, поэтому это тогда тебя нужно гнать

Ты и верно конь. Давай, ещё мой код покритикуй (которого я не писал) 😂

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

151. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (151), 22-Янв-23, 20:45 
Тебя забыл спросить насчёт вон.
Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

10. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +7 +/
Сообщение от ИмяХ (?), 20-Янв-23, 10:55 
Предложен новый способ ронять сервера конкурентам.
Ответить | Правка | Наверх | Cообщить модератору

17. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от oops_limit (?), 20-Янв-23, 11:17 
После достижения лимита, который по умолчанию выставлен в 10 тысяч oops (при желании можно изменить через параметр oops_limit), ядро будет инициировать переход в состояние "panic" с последующей перезагрузкой, что не позволит добиться необходимого для обнуления refcount числа итераций.
повторяю, для ИмяХ: "при желании можно изменить через параметр oops_limit".
Ответить | Правка | Наверх | Cообщить модератору

23. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (23), 20-Янв-23, 11:42 
Почему нельзя по достижению лимита выставить это значение опять в 0? Или почему бы не перестать его прибавлять при достижении лимита?
Ответить | Правка | Наверх | Cообщить модератору

27. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +1 +/
Сообщение от Аноним (27), 20-Янв-23, 11:56 
это счетчик ссылок. Зачем тогда вообще счетчик, если по описанным тобой правилам там будет неизвестно что?
Ответить | Правка | Наверх | Cообщить модератору

33. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +1 +/
Сообщение от Аноним (23), 20-Янв-23, 12:14 
Статья говорит что это счетчик предупреждений. Кому теперь верить? Это я уже не говорю на что он должен ссылаться на завершенные задачи?
Ответить | Правка | Наверх | Cообщить модератору

51. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (27), 20-Янв-23, 12:43 
статья явно говорит, что используется переполнение счетчика ссылок
> метод атаки основывается на особенности обработки состояний "oops", в результате которых можно добиться увеличения значения счётчика ссылок (refcount), что в свою очередь может привести к переполнению счётчика и освобождению памяти, связанной с refcount.
Ответить | Правка | Наверх | Cообщить модератору

60. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (61), 20-Янв-23, 13:27 
> переполнение счетчика ссылок

ссылок - куда? какой объект?

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

76. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (27), 20-Янв-23, 14:17 
на объект типа mm_struct
Ответить | Правка | Наверх | Cообщить модератору

87. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +1 +/
Сообщение от Аноним (61), 20-Янв-23, 17:14 
кто владелец? каковы условия срабатывания счётчика? куда "передаётся" структура, раз срабатывает счётчик? Что за NULL? Куда указывает? Кто хранит?
Ответить | Правка | Наверх | Cообщить модератору

90. "Предложен метод эксплуатации разыменования NULL-указателей в..."  –2 +/
Сообщение от Аноним (27), 20-Янв-23, 17:37 
> кто владелец?

я. Комп мой, ячейка памяти ссылающаяся на структуру тоже куплена за мои деньги

дружище, ты пьян, ты на каникулах или тебе не с кем поговорить?
В первой же ссылке из новости расписаны условия срабатывания счетчика, а так же, что и почему происходит. Если информации недостаточно, то могу подсказать ссылку на исходники ядра.

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

28. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +1 +/
Сообщение от Аноним (28), 20-Янв-23, 11:59 
>Или почему бы не перестать его прибавлять при достижении лимита?

И выдавать You sick bastard

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

37. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +3 +/
Сообщение от Аноним (23), 20-Янв-23, 12:18 
Да это называется умный счетчик.

Если у тебя так много "проблемных задач" которые завершаются и тебе для чего-то надо знать их количество это уже вызывает вопросы. Всё что надо делать это сравнивать это значение с нулем зачем его бесконечно прибавлять ещё и без проверки переполнения ума не приложу.

Можно делать метрику oops за последние 24 часа. А потом хвастаться перед коллегами сколько у кого oops.

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

13. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +16 +/
Сообщение от Аноним (13), 20-Янв-23, 11:15 
То есть раньше надо было провести 4.3 миллиона oops (что потребует примерно 8 дней), чтобы эксплуатировать уязвимость.
Теперь надо 10 тысяч oops (что потребует примерно 10 минут), чтобы перезагрузить сервак.

Отлично пофиксил. Идеально, я бы сказал.

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

19. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (18), 20-Янв-23, 11:26 
Верни старое поведение oops_limit=0xFFFFFFFF
Ответить | Правка | Наверх | Cообщить модератору

41. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Деанон (?), 20-Янв-23, 12:26 
oops_limit можно изменить
Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

42. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Деанон (?), 20-Янв-23, 12:26 
(но в прочем, свобода выбора она такая, что выбирают то, что навязывают в результате ограниченности мировоззрения)
Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

57. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от onanim (?), 20-Янв-23, 13:14 
то есть получение хакером рутового доступа к серверу лучше, чем просто перезагрузка этого сервера?
Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

65. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (61), 20-Янв-23, 13:39 
Откуда взялся хакер на сервере? Как он смог сделать исполняемый файл? Где он его разместил, что смог запустить?
Ответить | Правка | Наверх | Cообщить модератору

71. "Предложен метод эксплуатации разыменования NULL-указателей в..."  –1 +/
Сообщение от Аноним (48), 20-Янв-23, 14:01 
Загрузил в папочку cgi-bin
Ответить | Правка | Наверх | Cообщить модератору

88. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (61), 20-Янв-23, 17:15 
> в папочку cgi-bin

Откуда у левого юзера, непонятно ещё как попавшего на сервер, права на запись туда?!

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

96. "Предложен метод эксплуатации разыменования NULL-указателей в..."  –1 +/
Сообщение от Аноним (96), 20-Янв-23, 18:28 
вы таки хотите сломать чей-то сервер, что так интересуетесь?

Заказываете виртуалку с доступом в интернет и ставите на нее вордпресс. Так чтобы можно было картинки загружать, плагины всякие ставить, обновлять его одной кнопкой из его же админки, ну и просматривать без ограничений. Обычное использование в общем, как у всех.

Потом расскажете, откуда там права на запись взялись.

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

106. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (61), 20-Янв-23, 20:13 
ну сломаешь ты сам свою виртуалку... у тебя и так туда доступ есть. Это как локалхост молотком расфигачить.
Ответить | Правка | Наверх | Cообщить модератору

109. Скрыто модератором  +/
Сообщение от Докерёнок (?), 20-Янв-23, 20:41 
Ответить | Правка | Наверх | Cообщить модератору

111. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (111), 20-Янв-23, 21:27 
Кому нужен вордпресс от пыхающих. Прогрессивные посоны на Раст пишут. Там exec и eval нет, а все пути к точкам входа к бинарнику гвоздями прибиты.
Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

157. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от pilat66 (?), 23-Янв-23, 12:30 
Украл ключи у разработчика, как обычно. Пропатчил библиотеку, которую ленивый нодовец тащит не глядя. Сынишка похвастался что с папиного компа играть лучше. И тд
Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

89. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +2 +/
Сообщение от Аноним (61), 20-Янв-23, 17:16 
Опять для получения рута нужен рут?!
Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

168. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (168), 04-Янв-24, 01:28 
Сидят два бурундука на берегу реки и вяжут шапочки. Подходит слон и спрашивает:
- Река глубокая?
Первый бурундук:
- Глубокая, очень...
Слон:
- А дно как?
Первый бурундук:
- Песочек, отличное дно...
Ну слон разбегается, ныряет, в реке ударяется головой об камни, застревает, ноги торчат, везде кровь..
Второй бурундук первому:
- Зачем ты слона обманул?
- А зачем ты вчера мою шапочку распустил???

Вы ведь понимаете что речь не о сервере вообще. Вы знаете что Linux имеет модель колец защиты. И если такая модель применяется, то она должна работать как положено.

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

68. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от topin89 (ok), 20-Янв-23, 13:47 
Ток если строго по формулам, то примерно одну-две секунды
Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

15. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (15), 20-Янв-23, 11:16 
Типа теперь можно на изи вызывать панику ядра? Это они починили или доломал?
Ответить | Правка | Наверх | Cообщить модератору

21. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +3 +/
Сообщение от Аноним (21), 20-Янв-23, 11:37 
DoS как способ защиты от разыменования NULL
Ответить | Правка | Наверх | Cообщить модератору

22. "Предложен метод эксплуатации разыменования NULL-указателей в..."  –2 +/
Сообщение от Аноним (23), 20-Янв-23, 11:41 
Я вот прям совсем не специалист, по почему бы это число при достижении лимита просто не обнулить? Даже если лимит поставить максимально возможным.
Ответить | Правка | Наверх | Cообщить модератору

24. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +2 +/
Сообщение от Самый Лучший Гусь (?), 20-Янв-23, 11:45 
В реальном мире не бывает нулей.
Ответить | Правка | Наверх | Cообщить модератору

94. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +1 +/
Сообщение от Аноним (94), 20-Янв-23, 17:54 
Других чисел и математики в реальном мире тоже нет. С другой стороны, если мы все сидим в Матрице, то нули и единицы более реальны чем всё что нас окружает.
Ответить | Правка | Наверх | Cообщить модератору

122. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (121), 20-Янв-23, 23:15 
> В реальном мире не бывает нулей.

Вот те раз, компьютерам это расскажи с их двоичной системой счисления.

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

139. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +1 +/
Сообщение от Аноним (61), 21-Янв-23, 22:19 
Вообще "ноль" - философическая проблема. Вот лежит яблоко на столе - это 1. А если стол пустой, сказать, что ноль яблок? А почему яблок, а не арбузов? Их же тоже нету. Видите, как при нуле сразу потерялись единицы измерения? Получается, ноль не имеет измерения, что уже делает его гипотетическим.
Ответить | Правка | Наверх | Cообщить модератору

148. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (-), 22-Янв-23, 17:32 
В вашей философии явно не было "типов данных" и "auto", когда оно соответствует чему угодно. Если вам нужны арбузы, 0 арбузов столь же валидно как 0 яблок или межгалактических сверхсветовых крейсеров. Универсальный тип, подходит ко всему.

А так то компьютеры много чего "гипотетического" делают. Скажем GPS - рисует некую виртуальную координатную сетку, грубо говоря. Ее нет. Но если допустить что она все же есть, в ней можно адресовать объекты. И это работает.

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

159. "Предложен метод эксплуатации разыменования NULL-указателей в..."  –1 +/
Сообщение от Аноним (61), 23-Янв-23, 14:48 
> 0 арбузов столь же валидно как 0 яблок

Вот ты и подтвердил, что 0 не имеет типа, а значит, не существует.

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

130. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (130), 21-Янв-23, 12:17 
Давай, расскажи мне, сколько в реальном мире живых тилацинов.
Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

44. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +2 +/
Сообщение от Аноним (18), 20-Янв-23, 12:29 
А refcount продолжит щёлкать дальше. Дальше последствия описаны во 2-м абзаце новости.
Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

29. "Предложен метод эксплуатации разыменования NULL-указателей в..."  –2 +/
Сообщение от Oe (?), 20-Янв-23, 12:01 
Видимо замораживать процесс вызывающий oops на секунду (а после некого лимита и вовсе убить, пусть переписывают на раст если с первого раза не доходит) звучит как что то очень умное и не приходящее в голову, вместо этого лучше внедрить возможность DoS атаки
Ответить | Правка | Наверх | Cообщить модератору

69. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +1 +/
Сообщение от Аноним (48), 20-Янв-23, 13:58 
Пришлите им свою реализацию
Ответить | Правка | Наверх | Cообщить модератору

47. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +2 +/
Сообщение от Hck3r (?), 20-Янв-23, 12:35 
Когда уже научат что-то вроде 0dayGPT - чтобы нашла все уязвимости (на основе находимых ранее идей) - исправила бы всё разом.
В любого размера кодовой базе
Ответить | Правка | Наверх | Cообщить модератору

49. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (49), 20-Янв-23, 12:40 
> ядро будет инициировать переход в состояние "panic"

Вместо rce будет dos. Поменяли понос на золотуху.

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

58. "Предложен метод эксплуатации разыменования NULL-указателей в..."  –1 +/
Сообщение от onanim (?), 20-Янв-23, 13:16 
то есть лучше, чтобы вместо dos был rce? вы что, совсем тупые?
Ответить | Правка | Наверх | Cообщить модератору

67. "Предложен метод эксплуатации разыменования NULL-указателей в..."  –1 +/
Сообщение от Аноним (67), 20-Янв-23, 13:47 
Тупой здесь ты. Читай внтмательно:
> счётчик ссылок становится равен нулю, память освобождается, но фактически остаются рабочие ссылки

Правильное решение - при обнулении счётчика удалять "осиротевшие" ссылки.

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

72. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +3 +/
Сообщение от Аноним (72), 20-Янв-23, 14:01 
Счетчик как раз и используется для определения наличия используемых указателей. Нулевое значение счётчика показывает, что память уже не используется и ссылок не осталось.
Ответить | Правка | Наверх | Cообщить модератору

99. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (67), 20-Янв-23, 18:48 
> ссылок не осталось
> но фактически остаются рабочие ссылки

Может быть, всё-таки попробуешь прочитать текст новости?

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

108. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (72), 20-Янв-23, 20:32 
Нулевой счётчик показывает, что ссылок не осталось и память можно считать свободной, но так как значение счётчика изменено  на ноль внешним воздействием он уже не отражает реальную ситуацию и на деле ссылки остаются и память продолжает использоваться, в этом и суть уязвимости.

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

86. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Омномним (?), 20-Янв-23, 16:57 
Это вам не питончик с хрустяшкой, на минуточку, "ссылку" может не получиться удалить вообще.
Допустим ссылка лежит в других структурах, на которые завязаны ещё структуры. Будем все удалять?
Что будем делать с процессами, держащими хендля или ссылкась на эти структуры? Прибивать?
Что будем делать, если у нас ссылка в DMA ушла? :D
Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

100. "Предложен метод эксплуатации разыменования NULL-указателей в..."  –3 +/
Сообщение от Аноним (67), 20-Янв-23, 19:04 
В ядре линуха всё настолько плохо? Ну офигеть...
Ответить | Правка | Наверх | Cообщить модератору

110. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Омномним (?), 20-Янв-23, 21:04 
Ещё раз, ссылочка ушла в DMA, и вот прямо сейчас внешнее устройство забрасывает в эту область памяти данные.
Остановить этот процесс никак. Чего где будем удалять?
Ответить | Правка | Наверх | Cообщить модератору

149. "Предложен метод эксплуатации разыменования NULL-указателей в..."  –1 +/
Сообщение от Аноним (-), 22-Янв-23, 17:34 
> Ещё раз, ссылочка ушла в DMA, и вот прямо сейчас внешнее устройство
> забрасывает в эту область памяти данные.
> Остановить этот процесс никак. Чего где будем удалять?

Вообще, если ссылка на число оопсов ушла в DMA, Торвальдсу кому-то надо 314-ы дать - и спросить какого черта в их коде творится вообще.

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

153. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Омномним (?), 22-Янв-23, 21:59 
Я про структуры с рефкаунтом.
Ответить | Правка | Наверх | Cообщить модератору

50. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +1 +/
Сообщение от Аноним (48), 20-Янв-23, 12:42 
Можно ронять сервера виртуального хостинга, делаешь аккаунт даже бесплатный. Делаешь 10000 разименований за 2 секунды. Сервер уходит в перезагрузку на 10-20 минут.
А с kvm такая фича работает? Можно ли за 10000 разьименований положить хостовую ос?
Ответить | Правка | Наверх | Cообщить модератору

66. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +2 +/
Сообщение от Аноним (61), 20-Янв-23, 13:40 
> Можно ли за 10000 разьименований положить хостовую ос?

Об этом гугл расскажет потом, когда выполнит задачу по взлому целевых серваков.

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

59. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +1 +/
Сообщение от Аноним (61), 20-Янв-23, 13:22 
> требуется около 8 дней непрерывной генерации состояний "oops". В случае успеха эксплоит позволяет добиться выполнения своего кода на уровне ядра

Чем определяется вероятность успеха? Что-то в статье много мутных мест. Не сказано даже, какие версии ядра подвержены.

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

82. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +6 +/
Сообщение от Омномним (?), 20-Янв-23, 15:29 
> для проведения атаки при помощи предложенного эксплоита требуется около 8 дней непрерывной генерации состояний "oops"

...
...
Ну так-то примерно на 7 дней Зоркий Глаз всё-таки что-то заметит, если он не девляпс, конечно же :)

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

91. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +2 +/
Сообщение от Аноним (94), 20-Янв-23, 17:44 
У меня куча вопросов в связи с этой проблемой и её гениальным "решением". Зачем вообще в ядре на таком низком уровне выделение памяти и счётчики ссылок? Почему нельзя просто молча прибить процесс, без игр с кусками памяти? Почему нельзя сразу при старте ядра зарезервировать минимально нужный кусок памяти и не "удалять" его никогда?

Это убогое проектирование. Как это на тех же на встраиваемых устройствах должно работать?

Вообще, судя по всяким OOM killer'ам разработчики линукс ядра относятся к памяти абсолютно расхлябанно, как к какому-то бесконечному ресурсу. "Падает из-за нехватки памяти? Ну так просто купи_новый_телефон/доставь_ещё_терабайт_в_сервак"

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

114. "Предложен метод эксплуатации разыменования NULL-указателей в..."  –1 +/
Сообщение от Аноним (113), 20-Янв-23, 22:13 
Ну не будем забывать, что сам линь начинался как proof-of-concept финского студента для поднятия ЧСВ, и которому не жалко было дать отдушину нёрдам планеты всей, которые в свободное от работы на дядю время оттачивали навыки использования нестандартных структур данных (интрузивные списки, например) на уровне ring0. Да и для встраиваемых систем есть более подходящие вещи типа FreeRTOS и Zephyr.
Ответить | Правка | Наверх | Cообщить модератору

107. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +1 +/
Сообщение от Спили мушку сынок (?), 20-Янв-23, 20:31 
Ждём, когда с автообновлениями сделают неотключаемый таймер перезагрузки в пять минут. Вышел сервер в интернет, понюхал обновлений и в ребут.
Ответить | Правка | Наверх | Cообщить модератору

137. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +1 +/
Сообщение от Аноним (137), 21-Янв-23, 21:05 
Ну и правильно. Ставишь балансировщик на винде, чтоб не перезагружался, а за ним зоопарк линуксовых машин. Представь как будут хакеры материться, когда таргет постоянно ребутается :)
Ответить | Правка | Наверх | Cообщить модератору

117. "Предложен метод эксплуатации разыменования NULL-указателей в..."  –1 +/
Сообщение от Ivan_83 (ok), 20-Янв-23, 22:51 
1. Поменять счётчик на size_t и для 64х систем оно станет 64 битным.
2. Собирать с -fno-delete-null-pointer-checks и добавить проверки в код.
Ответить | Правка | Наверх | Cообщить модератору

119. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +2 +/
Сообщение от Аноним (61), 20-Янв-23, 23:02 
0. Сделать, как в паскале длинные строки: если счётчик -1 (FF...F), это константный объект, счётчик не трогаем. И сразу все проблемы снимутся.
Ответить | Правка | Наверх | Cообщить модератору

126. "Предложен метод эксплуатации разыменования NULL-указателей в..."  –1 +/
Сообщение от Xasd8 (?), 21-Янв-23, 01:27 
> если счётчик -1 (FF...F), это константный объект

не сработает.

в этом случае увеличение количество ссылок а потом уменьшение их на тоже самое (больше) значение -- заставит пройти через нуль (не в том месте)

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

128. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +1 +/
Сообщение от Аноним (61), 21-Янв-23, 11:05 
> а потом уменьшение

Прочитай статью внимательно.

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

164. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +1 +/
Сообщение от Омномним (?), 24-Янв-23, 00:15 
Ну как сказать, снимутся. Превратятся в протечки.
Хотя чтобы FFFFFFFF рефкаунтов набрать - это надо очень постараться.
Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

129. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от eganru (?), 21-Янв-23, 11:13 
Как не специалист, не понимаю, почему нельзя в случае достижения MAX_REFCOUNT заблокировать счетчик ссылок на этом значении? Это имеет какие-то серьезные побочные эффекты(в и без того явно плохом сценарии)?
Ответить | Правка | Наверх | Cообщить модератору

135. "Предложен метод эксплуатации разыменования NULL-указателей в..."  –4 +/
Сообщение от Аноним (135), 21-Янв-23, 20:31 
SystemD + Ubuntu + Gnome + P A С Т = Лучшая ОС на свете!!!
Ответить | Правка | Наверх | Cообщить модератору

136. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +1 +/
Сообщение от Аноним (137), 21-Янв-23, 20:32 
а если занулить?
Ответить | Правка | Наверх | Cообщить модератору

140. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +2 +/
Сообщение от Аноним (61), 21-Янв-23, 22:22 
у тебя ошибка в формуле: несоответствие единиц измерения.
Ответить | Правка | К родителю #135 | Наверх | Cообщить модератору

144. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (-), 21-Янв-23, 22:43 
Я понял, это команда фуксии собирается подмять под себя команду ведроида и заложила в ведро бабах на упсы. Дёрнешь тамошний bus1 не так и телефон регулярно перезагружается.

А циркон, как понимаете, не падает, потому что такой фичи в нём нет.

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

152. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +1 +/
Сообщение от Аноним (-), 22-Янв-23, 21:29 
> Я понял, это команда фуксии собирается подмять под себя команду ведроида и
> заложила в ведро бабах на упсы.

Поэтому другая команда заложила бабах в их менеджмент - опа, 16% команды фуксии уволены?!

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

145. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Анонимemail (145), 21-Янв-23, 23:03 
Правильнее было бы завершать с соответствующим кодом ошибки приложение, пытающееся разыменовать NULL. И тогда код проверки не будет потреблять чрезмерно ресурсов.
Ответить | Правка | Наверх | Cообщить модератору

156. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (156), 23-Янв-23, 10:12 
Интересно, что на этот счёт думаю Кен с Ритчи, они же ещё живы. Может убрать уже эти указатели из Си? Одни проблемы от них.
Ответить | Правка | Наверх | Cообщить модератору

158. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +/
Сообщение от Аноним (61), 23-Янв-23, 14:44 
> Может убрать уже эти указатели

Может, убрать уже эти процессоры, одни проблемы от них.

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

163. "Предложен метод эксплуатации разыменования NULL-указателей в..."  +1 +/
Сообщение от pavlinux (ok), 23-Янв-23, 22:48 
Этот refcount  интересен только в состояниях 0 (никого) и 1 (кто-то есть),
все что больше 1 расценивается так же как и 1.  


В ядре есть лимиты, pid_max, max_map_count, от них и надо прыгать.
Если refcount начал переваливать за эти пределы, прибивать нахрен процесс
с сообщением  "Тюнюнгуй свой хелловорд, пейсатель".  


Домашнее задание:  

Найти там же, в mm_struct,  Sequence counter и создать похожий эксплойт.

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

166. "Предложен метод эксплуатации разыменования NULL-указателей в..."  –1 +/
Сообщение от _kp (ok), 24-Янв-23, 01:48 
Стоп, refcount 32х битный?
Да поставить 128 битный. Обязательно временно.
Склеенное скотчем держится веками.
И проблема решена! ;)
Ответить | Правка | Наверх | Cообщить модератору

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

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




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

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