В ядрах Linux начиная с выпуска 3.3 и заканчивая 3.8 выявлена (http://www.openwall.com/lists/oss-security/2013/02/24/2) локальная уязвимость (CVE-2013-1763), которая может привести к выполнению кода с правами ядра. Уязвимость вызвана ошибкой в реализации подсистемы sock_diag, в которой не осуществлялась должная проверка выхода за границы массива sock_diag_handlers. В итоге непривилегированный локальный пользователь мог через отправку специально оформленного netlink-сообщения переписать своими данными область за пределами массива sock_diag_handlers и организовать запуска своего кода в пространстве ядра.Сообщается, что проблеме подвержены ядра из состава Fedora 18 и Ubuntu 12.10 (+ ядро 3.5, подготовленное для Ubuntu 12.04.2). Концептуальный прототип эксплоита можно найти здесь (https://rdot.org/forum/showthread.php?p=30828). Примечательно, что ошибка присутствовала и в ядрах младше ветки 3.3, но возможность эксплуатации отмечается (http://www.openwall.com/lists/oss-security/2013/02/25/2) только для ядер начиная с версии 3.3. При этом использование ограничения mmap_min_addr помогает лишь некоторых техник эксплуатации и не исключает проведение атаки. Исправление уязвимости пока доступно в виде патча (http://thread.gmane.org/gmane.linux.network/260061). Пакеты с устранением уязвимости пока недоступны, проследить за появлением обновлений для популярных дистрибутивов можно на данных страницах: Ubuntu (https://lists.ubuntu.com/archives/ubuntu-security-announce/2.../), Gentoo (http://www.gentoo.org/security/), Slackware (http://www.slackware.com/security/list.php?l=slackware-secur...), openSUSE (http://lists.opensuse.org/opensuse-security-announce/2013-02/), Fedora (https://admin.fedoraproject.org/updates/F18/security) (в RHEL и Debian используются ядра не старше 3.2).
URL: http://www.openwall.com/lists/oss-security/2013/02/24/2
Новость: http://www.opennet.me/opennews/art.shtml?num=36220
Почему бы не сделать язык со статической типизацией, но без указателей и необходимости каждый раз выделять и освобождать память? Чтобы при этом не было тормозного сборщика и Jit-компилятора. Тогда все эти проблемы уйдут как страшный сон
Действительно! Как это раньше никому в голову не пришло?
> Действительно! Как это раньше никому в голову не пришло?Это вы просто ручник медленно отпускаете - http://en.wikipedia.org/wiki/MISRA_C
Внезапно, достаточно просто соответствовать набору правил и обычный си вполне прокатит даже для очень критичных применений. Просто надо задаться такой целью. И все.
где найти? там написано что это закрытый платный документ
Так и есть, но нагуглить можно. Результат будет, понятно, нелицензионным.
Судя по вышеприведенной статье, там следует ожидать капитанства типа "пишите программы хорошо".
> Судя по вышеприведенной статье, там следует ожидать капитанства типа "пишите программы хорошо".Да, там всего лишь наборы правил. Существуют также и автоматические валидаторы под таковые. И если что - эти парни как раз щелкают ABSом, выпускают подушки безопасности и прочая. По поводу чего они как раз и подозревают, что лажа в их программах - немного не то с чем хотел бы столкнуться их клиент.
> где найти? там написано что это закрытый платный документ...но сам набор правил - гуглится, если что.
Много там полезных правил, но по сути это обман - т.к. вместе с полезным, идёт много таких ограничений которые сильно усложнят разработку. Например:
- Не использовать stdio и malloc
- Нельзя включать locale.h и вызывать setlocale()
- Функции поддержки времени из библиотеки time.h не должны использоваться?
- Не использовать функции с переменным числом аргументов - прощай sprintf()
Самый лучший способ обмануть - это смешать правду с ложью. (древняя мудрость)
С каких пор стабильность и безопасность идут рука-об-руку со скоростью разработки?
Угу. А еще интересно почему бы не сделать асинхронный CPU и не париться с oscillator-ом и clock-рейтом, не забить хрен на DDR RAM и не использовать SRAM, и не синтезировать C вообще прямо в hardware, имея половину CPU выполненного в виде большого FPGA? :)
>и не синтезировать C вообще прямо в hardwareSystemC ?
Внезапно! Уже сделано. Так давно, что даже забыто. http://old.computerra.ru/vision/641905/
> Внезапно! Уже сделано. Так давно, что даже забыто. http://old.computerra.ru/vision/641905/Спасибо за линк! Удивительно, что на опеннете еще остались люди, комментирующие по делу.
а если учесть тактовую частоту самого FPGA.... ;) и ограниченность числа логических блоков
> Почему бы не сделать язык со статической типизацией, но без указателейЧто-то пхпшникам, рубистам, питонистам и прочим все это нифига не помогло. В смысле, ломают их постоянно.
и у кого из перечисленных статическая типизация ?
> и у кого из перечисленных статическая типизация ?У них таки динамическая, увы. Это к тому что у них нет переполнений буферов и работы с указателями. На которые они так любят кивать. Что им почему-то нифига не помогает в плане дыр класса "хакер может выполнить произвольный код".
Это защищает от широкого класса багов, очевидно, что от всех без исключения багов избавление от указателей не принесет (в противном случае это означало бы что слова баг и указатель тождественны). Поэтому исполнение произвольного кода в том же питоне крайняя редкость, в отличие от сей, для которых это обыденная повседневность. Проблемы похапе же это отдельная тема, к указателям имеющая мало отношения.
> Это защищает от широкого класса багов, очевидно,И порождает 100500 новых классов багов. Вот в си например не бывает выполнения кода из ремотных инклюдов. И выполнение файла залитого через форму влобешник для сей тоже как-то малохарактерно. А для скриптоязыков это например вполне обычное явление. Ну заменили шило на мыло, и чего? Вебня в целом тем не менее намного дырявее. В силу низкой квалификации программеров, разумеется. В ней например регулярно находят инициируемое ремотно выполнение кода. А в линевом кернеле, с кучей кода, все дела, на небезопасном си - я уж и не помню даже, когда было ремотно инициируемое по сети выполнение кода в последний раз.
> что от всех без исключения багов избавление от указателей не принесет
Разумеется. Более того - не понятно почему это надо вообще запрещать. А может, запретим дровосеку использовать бензопилу? Пораниться же можно! Пилот обойдется без руления потенциально опасным самолетом. И машинисту потенциально опасный электровоз не дадим. Автомобилисты обойдутся без потенциально опасных автомобилей. Строители - без потенциально опасных инструментов. В общем сядем в безопасную песочницу и будем дружно в безопасные куличики играть.
> (в противном случае это означало бы что слова баг и указатель тождественны).
> Поэтому исполнение произвольного кода в том же питоне крайняя редкость,Что-то не заметно - moinmoin на питоне в последнее время хакают довольно конкретно. Ремотно, по сети. А линуксный кернел ремотно по сети слабо хакнуть?
> в отличие от сей, для которых это обыденная повседневность.
Да? Ну тогда вы покажете нам взлом именно линевого ядра ремотно, по сети? А то для питонятины в виде moinmoin это как раз таки нынче обыденность.
> Проблемы похапе же это отдельная тема, к указателям имеющая мало отношения.
А чем он такой особенный? Вон moinmoin на питоне - разломали. Рельсы на рубях - разломали. Редкость? Прикалываетесь7 Вебня давно стала типовым вектором атак нехороших парней.
> Вебня в целом тем не менее намного дырявее. В силу низкой квалификации программеров, разумеется.ну а что было бы, если бы они писали на сях? стало бы от этого кому-то безопаснее?
> ну а что было бы, если бы они писали на сях? стало бы от этого кому-то безопаснее?ИМХО было бы довольно однофигственно. Просто потому что програмеры и их квалификация не изменились.
И кстати да, в похапе указатели же вроде только недавно отменили, до версии 5.3, если память не изменяет, они там вполне себе присутствовали.
1) как вам поможет типизация, если у вас программа использует либо и дырка в них?
2) как вам поможет типизация, если у вас баг в вашем коде?
3) как вам поможет типизация, если у в вашем коде нет обработки нетипичных ситуаций или они покрыты не полностью?
Вообще-то, типизация, как и проверяемые исключения, нужна для верификации ИСХОДНОГО кода на предмет непротиворечивости присваиваний и обработки объектов на этапе компиляции. То есть как только получен блоб, то мы можем быть уверены, что нету никаких незамеченных программистом присваиваний целых чисел параметру типа "указатель", параметризованные массивы хранят параметры одного типа, а не различных. Интерпретация строки в качестве аргумента целочисленного типа невозможна в принципе. Иначе компиляция просто не пройдёт и укажет на ошибку в исходном тексте программы.
> 1) как вам поможет типизация, если у вас программа использует либо и дырка в них?Как, как. Компилер лишний раз футбольнет при сомнительных действиях. Языки с динамической типизации без вопросов сконвертят яблоки в сапоги и что-то будет делать с всем этим дальше. Ну а поскольку такая конверсия не несет никакого физического и логического смысла, результатом станет замаскированный баг, который где-нибудь потом вылезет через полчаса работы, и удачи найти место где он на самом деле возник.
> 2) как вам поможет типизация, если у вас баг в вашем коде?
Завернет некоторые классы багов типа суммирования яблок с сапогами неизвестно зачем. Куда-то туда же и использование незадекларированных переменных, приводящее к тому что глотаются опечатки в коде, а в результате - опять же, через полчаса работы где-то выплывает трудноуловимый баг.
> 3) как вам поможет типизация, если у в вашем коде нет обработки
> нетипичных ситуаций или они покрыты не полностью?А никак. Разве что уменьшит число таковых.
> Почему бы не сделать язык со статической типизацией, но без указателейДля этого самого си между прочим есть стандарт для особо критичных применений, где кроме всего прочего запрещается использование адресной арифметики. И компилеры в этом режиме считают это деяние за ошибку. Так что все хорошее уже изобрели до вас. Просто кернел без указателей будет уже не торт. Он с памятью активно работает, без указателей это превратится в костыли и воркэраунды.
> запрещается использование адресной арифметикиА к элементам массива оно как обращается?
> А к элементам массива оно как обращается?Так же как и обычно. Запрещается именно математика в указателях. Которая может при безбашенном использовании прострелить пятку не самым очевидным програмеру образом.
Вы же понимаете, что доступ к элементам массива реализуется через адресную арифметику и что фактически a[3] транслируется перед компиляцией в "*(a+3)"?
> Вы же понимаете, что доступ к элементам массива реализуется через адресную арифметику
> и что фактически a[3] транслируется перед компиляцией в "*(a+3)"?Ну разумеется. Более того - указатели всего лишь адреса в памяти. Вы знаете, довольно сложно запретить процессору работать с адресами памяти. Потому что это весьма базовые основы работы с памятью.
Это все замечательно, но на мой изначальный вопрос вы не ответили.
Как можно запретить адресную арифметику, не запрещая такую основополагающую вещь, как обращение к элементу массива?
Посмотрите на массивы в паскале
Мне интересно, как это предлагается сделать именно в С исключительно с помощью какого-то непонятного "специального стандарта".Паскаль и его особенности меня не интересуют и совершенно не имеют отношения к теме.
> Как можно запретить адресную арифметику, не запрещая такую основополагающую вещь, как обращение
> к элементу массива?Ну вот так вот и можно - запретить именно операции с указателями, на которых чаще всего простреливают пятки не слишком очевидным образом. А так если программер задастся целью пальнуть себе в пятку - он по любому ее прострелит и автоматического метода поймать ВСЕ методы прострела пяток априори не существует. Пардон, Тюринг доказал что невозможно даже вынести вердикт закончится ли произвольная программа за конечное время или нет.
Просто в упомянутом случае это уже будет достаточно явный прострел пятки, который намного сложнее сделать непреднамеренно.
>Ну вот так вот и можно - запретить именно операции с указателямиЕще раз, для непонятливых:
обращение к элементу массива - это операция с указателями.
Можно рекомендовать или не рекомендовать что-то, прописывая это в каких-нибудь своих "Code style guidelines", точно так же, как величину отступов или расположение фигурных скобок, но запретить это на уровне компилятора невозможно.
Или возможно написать свой компилятор, но это уже будет не С, а узкоспециализированный язык, лишь внешне похожий на C.
>>Ну вот так вот и можно - запретить именно операции с указателями
> Еще раз, для непонятливых:
> обращение к элементу массива - это операция с указателями.Нет, если индекс - константа (или вычисляемое в константу на этапе компиляции).
Во-первых, вы пытаетесь умничать, придираясь к словам, не видя сути того, что я хочу сказать.А во-вторых:
int n = 5;
int *a = (int*)malloc(n*sizeof(int));
a[3] = 777; /* не вычисляется в константу несмотря на константный индекс */
> Во-первых, вы пытаетесь умничать, придираясь к словам, не видя сути того, что
> я хочу сказать.
> А во-вторых:
> int n = 5;
> int *a = (int*)malloc(n*sizeof(int));
> a[3] = 777; /* не вычисляется в константу несмотря на константный
> индекс */Где в твоём куске говнокода массив?
вот в древнем дельфи решили проблему, RangeChecking в свойствах компилятора, и за пределы массива по индексу не выйти, так что можно и это ограничить, проблема в том что все эти ограничения "искуственные" ( т.е. создаются с помошью кода компилятора ( интерпретатора ) и т.д. ) который в свою очередь так же не идеален ( проблемы с безопасностью интерпретируемых языков часто связаны не с мастерством пишуших на этих языках, а с качеством кода интерпретатора )
> вот в древнем дельфи решили проблему, RangeChecking в свойствах компилятора, и за
> пределы массива по индексу не выйти, так что можно и это
> ограничить, проблема в том что все эти ограничения "искуственные" ( т.е.
> создаются с помошью кода компилятора ( интерпретатора ) и т.д. )
> который в свою очередь так же не идеален ( проблемы с
> безопасностью интерпретируемых языков часто связаны не с мастерством пишуших на этих
> языках, а с качеством кода интерпретатора )Не в дельфи, а турбо паскале
>> запрещается использование адресной арифметики
> А к элементам массива оно как обращается?А к элементам массива адекватные Си-программеры обращаются только через указатели.
> Для этого самого си между прочим есть стандарт для особо критичных применений, где кроме всего прочего запрещается использование адресной арифметики.Ну и oт чего это может помочь ? Вот вам пример переполнения буфера без использования указателей:
unsigned int i, x[256];
i = 100500;
x[i] = 0xf0000000;
Если бы у нас в армии (30 лет назад) старшина умел программировать на C, он бы сказал на это (извините за натурализм): "Сдуру можно ... сломать".
Ясное дело. Товарищ хотел сказать, что запрещать адресную арифметику в С настолько же эффективно, насколько вешать стальной замок на трухлявую дверь с еле живыми петлями.
> Ясное дело. Товарищ хотел сказать, что запрещать адресную арифметику в С настолько
> же эффективно, насколько вешать стальной замок на трухлявую дверь с еле живыми петлями.Учитывая что этот код рулит всякими ABSами, подушками безопасности и прочая - я бы не вякал столь оптимистично. Вы реально не хотели бы чтобы этот код дал маху - от него сохранность ваших тушек зависит.
Oт этого потуги объявить адресную арифметику вселенским злом и пытаться ее запретить не становятся менее идиотскими.
> Oт этого потуги объявить адресную арифметику вселенским злом и пытаться ее запретить
> не становятся менее идиотскими.И тем не менее, в коде с повышенными требованиями к надежности она не приветствуется. Просто потому что в этом случае можно относительно легко обратиться к некорректному адресу в памяти.
>> Для этого самого си между прочим есть стандарт для особо критичных применений, где кроме всего прочего запрещается использование адресной арифметики.
> Ну и oт чего это может помочь ? Вот вам пример переполнения
> буфера без использования указателей:
> unsigned int i, x[256];
> i = 100500;
> x[i] = 0xf0000000;man gcc
на предмет -Warray-bounds
> на предмет -Warray-boundsИ как это поможет если i - входной параметр функции ?
> И как это поможет если i - входной параметр функции ?От вообще всех выходок програмера априори нельзя защититься. Но от некоторых наиболее вероятных и типовых ошибок - можно попробовать.
>> на предмет -Warray-bounds
> И как это поможет если i - входной параметр функции ?Ты пробовал?
Возьмите С++ и пользуйтесь, не понадобится ничего изобретать. Современный С++ совершенно не требует ни использования "сырых" указателей, ни возни с выделением и освобождением памяти. И компилятор не JIT, и мусор существует не дольше, чем нужно.Правда, для ядра системы, где нужно работать на более низком уровне, этот вариант совершенно не подходит %)
> Возьмите С++ и пользуйтесь, не понадобится ничего изобретать. Современный С++ совершенно
> не требует ни использования "сырых" указателей, ни возни с выделением и
> освобождением памяти. И компилятор не JIT, и мусор существует не дольше,
> чем нужно.
> Правда, для ядра системы, где нужно работать на более низком уровне, этот
> вариант совершенно не подходит %)Явное освобождение памяти - нормальный принцип программирования. Пос..л - убери за собой. Все иное - костыли и бред.
>> Возьмите С++ и пользуйтесь, не понадобится ничего изобретать. Современный С++ совершенно
>> не требует ни использования "сырых" указателей, ни возни с выделением и
>> освобождением памяти. И компилятор не JIT, и мусор существует не дольше,
>> чем нужно.
>> Правда, для ядра системы, где нужно работать на более низком уровне, этот
>> вариант совершенно не подходит %)
> Явное освобождение памяти - нормальный принцип программирования. Пос..л - убери за собой.
> Все иное - костыли и бред.Это пока нет взаимодействия между процессами... а так часто очень сложно понять кто должен высвобождать и когда...
Именно поэтому желательно оставлять эту работу компьютеру, а не программисту.
> Именно поэтому желательно оставлять эту работу компьютеру, а не программисту.Ага, судя по многим современным "программистам" (всяким питонистам, жабистам и рубистам) - там вообще всю работу надо компьютеру отдавать. А программист пусть валит метлой махать.
Простите, но либо "без <...> необходимости каждый раз выделять и освобождать память", либо "не было тормозного сборщика".А вообще, Вас Эрланг по идее интересует...
тут как-то, года 4-5 назад, жабакодеры тоже призывали переписать. правда, у них даже браузер за всё это время так толком и не написался. пичалька. ну и так, пару важных нюансов у таких революционеров просто выпадают из вида. слона упорно не замечают.
Вообще, умиляют идиоты полагающие что некая автоматика сможет решить за програмера все проблемы и позволит даже обезьяне писать надежный код. Это при том что Тюринг доказал что одна программа не может полностью проанализировать произвольную другую программу и выдать относительно ее поведения определенный вердикт (например, завершается ли она за конечное время или нет). Забавно смотреть как не понимающие этого простого момента чудаки ищут большую красную кнопку "сделайте мне за...сь" в языках программирования. А бабушки все падали. Не на сях, так на питоне, руби, пыхе... да в общем то на всем что позволяет писать программы, если посмотреть внимательнее :)
у этих "спецов" элементарная некомпетенция, теоретические знания, ноль практики, или обитание в среде написания тривиальных программ, алгоритм которых помещается на паре листов бумаги.
> Почему бы не сделать язык со статической типизацией, но без указателей и
> необходимости каждый раз выделять и освобождать память?Здравствуйте, мы только что вас разморозили! Знакомьтесь, ЯЗЫК ДИ! http://dlang.org
RHEL - нет заголовочных фалов типа sock_diag.h и эксплоит не собирается, протестированно на последнем обновлении 6.4
> RHEL - нет заголовочных фалов типа sock_diag.h и эксплоит не собирается, протестированно
> на последнем обновлении 6.4Энтерпрайзофагам не везёт. У них "начиная с выпуска 3.3 и заканчивая 3.8" появится лет через пять после _починки дыры.
я порой убедился - чем старее у тя ядро тем менее подвержено оно эксплоитам новеньким )))))пс: эксплоиты узаю тока для сброса рутового пароля )))
Угу, а init=/bin/sh придумали трусы…
> Угу, а init=/bin/sh придумали трусы…Это слишком просто и неспортивно.
> я порой убедился - чем старее у тя ядро тем менее подвержено
> оно эксплоитам новеньким )))))Странно, а хацкерье с https://rdot.org/forum/forumdisplay.php?f=24 почему-то очень плюется на как раз то что кернель новый часто выпускают и публичные ядерные руткиты регулярно перестают работать - stable api nonsense мешается :). Так что пожалуй stable api nonsense даже за фичу сойдет, киддям оказывается неудобно скачаными нахаляву руткитами долбаться. А корректно патчить руткиты кидисы понятное дело в общей массе не в состоянии.
> я порой убедился - чем старее у тя ядро тем менее подвержено
> оно эксплоитам новеньким )))))
> пс: эксплоиты узаю тока для сброса рутового пароля )))А просто запомнить пароль рута для Вас представляет неразрешимую проблему?
>> я порой убедился - чем старее у тя ядро тем менее подвержено
>> оно эксплоитам новеньким )))))
>> пс: эксплоиты узаю тока для сброса рутового пароля )))
> А просто запомнить пароль рута для Вас представляет неразрешимую проблему?pADqk25XW5eM78Ym1boBsI-R ? Вот это запомнить?
Я запомнил, ваш IP не подскажете? :)
>>> я порой убедился - чем старее у тя ядро тем менее подвержено
>>> оно эксплоитам новеньким )))))
>>> пс: эксплоиты узаю тока для сброса рутового пароля )))
>> А просто запомнить пароль рута для Вас представляет неразрешимую проблему?
> pADqk25XW5eM78Ym1boBsI-R ? Вот это запомнить?Этот пароль конечно же записан на бумажке и приклеен к монитору?!
Ах нет, этот пароль записан в суперсекретный файл, под паролем 123
На самом деле, очень удобно носить пароли с собой на флешке в обычных текстовых файлах.
Достаточно просто создать контейнер TrueCrypt на флешке и класть эти файлы туда...
> На самом деле, очень удобно носить пароли с собой на флешке в
> обычных текстовых файлах.
> Достаточно просто создать контейнер TrueCrypt на флешке и класть эти файлы туда...Я понимаю, но пароль к трукрипту такой же аль "123"?
Вся фигня в том, что при использовании метода не запоминаемых паролей,
слабое звено перемещается в другую часть системы безопасности, которое
должно иметь, как минимум туже степень защищенности.Переносные ключи хороши только для хранения в защищенном помещении,
c выдачей за подписью, в пределах предприятия/офиса, на период рабочего дня.
> Я понимаю, но пароль к трукрипту такой же аль "123"?А это даже похрен если ты флешку вовремя отключаешь. При условии что ты ее съешь при попытке ее отобрать :)
Они, собаки, разные по всему Пентагону! ;)
А это чё, AF_NETLINK надо в ядро вкомпиливать?
А его где-то в популярных пакетных нет?
> А его где-то в популярных пакетных нет?А я чего-то проспал, оно уже давно подефолту везде суётся.
Раньше отдельный параметр в конфиге был.Кстати, старый костыль
alias net-pf-16 off
И сломать всю следующую дребедень, простите за быдлокод:
# pids=$(cut -f4 -d' ' /proc/net/netlink | sort -u | grep -Ex '[0-9]{2,5}')# for i in $pids; do lsof +c 0 -p $i | grep netlink; done
X 1358 root 11u netlink 0t0 20469 KOBJECT_UEVENT
X 1358 root 12u netlink 0t0 20473 KOBJECT_UEVENT
kded4 1577 user 14u netlink 0t0 23463 KOBJECT_UEVENT
upowerd 1597 root 11u netlink 0t0 23867 KOBJECT_UEVENT
upowerd 1597 root 13u netlink 0t0 23424 KOBJECT_UEVENT
udisks-daemon 1642 root 10u netlink 0t0 23485 KOBJECT_UEVENT
knotify4 1651 user 9u netlink 0t0 23526 KOBJECT_UEVENT
plasma-desktop 1654 user 13u netlink 0t0 23547 KOBJECT_UEVENT
krunner 1675 user 9u netlink 0t0 25736 KOBJECT_UEVENT
kate 1677 user 12u netlink 0t0 24503 KOBJECT_UEVENT
kmix 1686 user 13u netlink 0t0 26372 KOBJECT_UEVENT
krusader 1690 user 9u netlink 0t0 25305 KOBJECT_UEVENT
pulseaudio 1742 user 14u netlink 0t0 26145 KOBJECT_UEVENT
psi-plus 1981 user 31u netlink 0t0 281559 KOBJECT_UEVENT
NetworkManager 720 root 5u netlink 0t0 13740 ROUTE
NetworkManager 720 root 6u netlink 0t0 13741 ROUTE
NetworkManager 720 root 14u netlink 0t0 15841 KOBJECT_UEVENT
NetworkManager 720 root 15u netlink 0t0 16525 GENERIC
systemd-logind 758 root 6u netlink 0t0 15517 KOBJECT_UEVENT
systemd-logind 758 root 7u netlink 0t0 15518 KOBJECT_UEVENT
modem-manager 808 root 6u netlink 0t0 15866 KOBJECT_UEVENT
modem-manager 808 root 7u netlink 0t0 16494 KOBJECT_UEVENT
modem-manager 808 root 8u netlink 0t0 16495 KOBJECT_UEVENT
modem-manager 808 root 9u netlink 0t0 16496 KOBJECT_UEVENT
modem-manager 808 root 10u netlink 0t0 16497 KOBJECT_UEVENT
modem-manager 808 root 11u netlink 0t0 16498 KOBJECT_UEVENT
modem-manager 808 root 12u netlink 0t0 16499 KOBJECT_UEVENT
modem-manager 808 root 13u netlink 0t0 16500 KOBJECT_UEVENT
modem-manager 808 root 14u netlink 0t0 16501 KOBJECT_UEVENT
modem-manager 808 root 15u netlink 0t0 16502 KOBJECT_UEVENT
modem-manager 808 root 16u netlink 0t0 16503 KOBJECT_UEVENT
modem-manager 808 root 17u netlink 0t0 16504 KOBJECT_UEVENT
modem-manager 808 root 18u netlink 0t0 16505 KOBJECT_UEVENT
modem-manager 808 root 19u netlink 0t0 16506 KOBJECT_UEVENT
modem-manager 808 root 20u netlink 0t0 16507 KOBJECT_UEVENT
modem-manager 808 root 21u netlink 0t0 16508 KOBJECT_UEVENT
modem-manager 808 root 22u netlink 0t0 16509 KOBJECT_UEVENT
modem-manager 808 root 23u netlink 0t0 16510 KOBJECT_UEVENT
modem-manager 808 root 24u netlink 0t0 16511 KOBJECT_UEVENT
modem-manager 808 root 25u netlink 0t0 16512 KOBJECT_UEVENT
modem-manager 808 root 26u netlink 0t0 16513 KOBJECT_UEVENT
> И сломать всю следующую дребедень, простите за быдлокод:# pids=$(cut -f4 -d' ' /proc/net/netlink | sort -u | grep -Ex '[0-9]{2,5}')
# for i in $pids; do lsof +c 0 -p $i | grep netlink; done
#Пичалька, да?! :)
Ага. Но там cut мог сломаться :) Плюс у меня там еще и баг с разным количеством разделителей, короче вот так уже пусть:
pids=$(awk '{print $3}' /proc/net/netlink | sort -u | grep -Ex '[0-9]{2,5}')
for i in $pids; do lsof +c 0 -p $i | grep netlink; doneИ старый lsof семейство netlink не понимает, с ним работать не будет. Какая точно версия — не скажу.
> Пакеты с устранением уязвимости пока недоступныПатченое ядро в репах арча было ещё вчера вечером, как бы до публикования новости.
Всё-таки консервативность дистрибутивов - это хорошо.
В ядре досих пор не исправили уязвимость - при вводе рутпароля можно делать что хочеш!
> В ядрах Linux начиная с выпуска 3.3 и заканчивая 3.8 выявлена [...] CVE-2013-1763В альте вчера заткнули, сегодня уже в обычных местах (сизиф, экспериментальные ядра из p6; в t6 протормозил сразу скопировать, должны быть завтра; в более ранних бранчах неактуально).
[ 1 ] Bug #911473 - CVE-2013-0290 kernel: net: infinite loop in __skb_recv_datagram()
https://bugzilla.redhat.com/show_bug.cgi?id=911473
[ 2 ] Bug #906309 - CVE-2013-0228 kernel: xen: xen_iret() invalid %ds local DoS
https://bugzilla.redhat.com/show_bug.cgi?id=906309
еще стопка дырок в ядре..
> net: infinite loop in __skb_recv_datagram()
> xen: xen_iret() invalid %ds local DoS
> еще стопка дырок в ядре..Человеку, который называет DoS'ы дырками, лучше на эти темы помалкивать, простите. (спорить со мной тут не о чем, можно сразу со старым bugtraq@)
>> net: infinite loop in __skb_recv_datagram()
>> xen: xen_iret() invalid %ds local DoS
>> еще стопка дырок в ядре..
> Человеку, который называет DoS'ы дырками, лучше на эти темы помалкивать, простите. (спорить
> со мной тут не о чем, можно сразу со старым bugtraq@)Ему можно. Если этот оракловый звездун diff между двумя тарболами от RedHat называет "разбром блоба на коммиты", то осталное всё - мелочи:)
Тем более, что налое враньё здесь поощряется, если оно "от оракла" и его полуграмотных представителей.
> Если этот оракловый звездун diff между двумя тарболами от RedHat
> называет "разбром блоба на коммиты", то осталное всё - мелочи:)Чтобы было в контексте: заинтересованные могут глянуть https://oss.oracle.com/git/?p=redpatch.git;a=commit;h=4a75b5...
> Тем более, что налое враньё здесь поощряется, если оно "от оракла" и
> его полуграмотных представителей.Нет, конечно. См. http://wiki.opennet.ru/ForumHelp (п. 6, 7).
diff? ты в своем уме? в составе этого дифа - далеко не 1 патч, и Oracle разбирает их по частям - со ссылками на комиты в upstream...вот до чего доводит людей подлизывание шапке...
> diff? ты в своем уме? в составе этого дифа - далеко не
> 1 патч, и Oracle разбирает их по частям - со ссылками
> на комиты в upstream...Тебе прямую ссылку привели на такой "разбитый по частям diff", болезный:)
> diff? ты в своем уме? в составе этого дифа - далеко не 1 патч,Блобом он от этого не становится, так что подмены понятий это не отменяет.
> вот до чего доводит людей подлизывание шапке...
"вот до чего доводит людей подлизывание Ораклу", вы хотели сказать?
>> net: infinite loop in __skb_recv_datagram()
>> xen: xen_iret() invalid %ds local DoS
>> еще стопка дырок в ядре..
> Человеку, который называет DoS'ы дырками, лучше на эти темы помалкивать, простите. (спорить
> со мной тут не о чем, можно сразу со старым bugtraq@)вы знаете - хостеру который пускает на shell - пофик.
Главное что ему уронили сервак этим.Можете дальше пытаться выкручиваться определениями - но суди не меняет - это локальная дыра в безопастности - через создание DoS.
или линукс уже DoS за дыры не считает ?:) их так много - что уже не сосчитать ?
>> Человеку, который называет DoS'ы дырками, лучше на эти темы помалкивать, простите.
> вы знаете - хостеру который пускает на shell - пофик.Вы мне это будете рассказывать? Сами-то хостер?
> Можете дальше пытаться выкручиваться определениями
Есть определения и разница между их значением, а Вы пытаетесь всё в кучу смешать да ещё и хамите в ответ на указание ошибки.
> - но суди не меняет - это локальная дыра в безопастности - через создание DoS.
Нет.
> или линукс уже DoS за дыры не считает ?:)
Домашнее задание: найти проект свободной ОС или вендора проприетарной ОС, который считает DoS за дыру в безопасности. Подсказка: фряшники несколько лет тому не считали в явном виде.
> вы знаете - хостеру который пускает на shell - пофик.
> Главное что ему уронили сервак этим.Ну так пусть апдейтится вовремя. На то и щука чтоб карась не дремал. И да, солярису все это ни разу не поможет, спасибо конским условиям от оракла. Тем более что гарантий что там дыр меньше - никто не даст. Просто в силу политики оракла он нынче стал неуловимым джо, тихонько околевающим у старых кастомеров.
> или линукс уже DoS за дыры не считает ?:)
Что значит не считает? Идентификатор CVE- вроде как подразумевает проблему безопасности.
kernel tried to execute NX-protected page - exploit attempt? (uid: 1000)
BUG: unable to handle kernel paging request at c1527b40
IP: [<c1527b40>] 0xc1527b3f
ну... как всегда, не пнешь не поедет :)
> kernel tried to execute NX-protected page - exploit attempt?Да, вот как-то так :)