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

В Android и старых ядрах Linux устранена уязвимость, эксплуа..., opennews (??), 04-Апр-17, (0) [смотреть все] По мере проникновения IoT и прочих устройств на Linux его активней начинают ковы, Аноним (-), 23:16 , 04-Апр-17, (1) +7 // Так ведь это же превосходно Только тут уже не палочкой ковыряют, а под микроско, Экспертуос (?), 23:29 , 04-Апр-17, (2) +18   // палочкой палочкой До мирокскопа не дожили Слишком уж дырявый - если посмотре, Аноним (-), 10:15 , 05-Апр-17, (33) –2   // всё не хорошо, но всё куда лучше чем во всех других альтернативахименно этим хор, J.L. (?), 12:47 , 05-Апр-17, (45)   чем лучше - чем в других Ничем не лучше, с тех пор как в головах разработчиков, пох (?), 13:47 , 05-Апр-17, (52) –3   следует понимать, что эти cотни на самом деле еще обычно очень непросто исполь, пох (?), 12:55 , 05-Апр-17, (47)   потыкав палочкой - если она вообще есть, то и в 6 есть - как это работает и по, пох (?), 13:04 , 05-Апр-17, (50)   а, вот оно что - оно просто второй раз ее считало, когда как раз валидна, при эт, пох (?), 13:12 , 05-Апр-17, (51)   или просто не знаешь как это использовать То есть бэкпорт security fix апсптрима, Аноним (-), 17:49 , 05-Апр-17, (64)   знаю, надо иметь уникальные компоненты в сервере, в системе и в инфраструктуре, , пох (?), 21:23 , 05-Апр-17, (69)   Гонишь крепко commit 4eb919825e6c3c7fb3630d5621f6d11e98a18b3aAuthor Rik van Ri, Аноним (-), 23:20 , 05-Апр-17, (70)   ну и какое милые, у вас, тыщелетье на дворе-то Речь шла о том, что из прямо вч, пох (?), 00:36 , 06-Апр-17, (80)   прямо вчера Это из все тех же патчей RHEL7 2- RHEL7 3 Открой глаза - то есть , Аноним (-), 07:33 , 06-Апр-17, (85)   А теперь и в относительных величинах покажите пожалуйста Анонутик Вы наш , vi (ok), 23:31 , 05-Апр-17, (72)   когда вас будут иметь через дыры - вас будет интересовать сколько всего патчей и, Аноним (-), 13:18 , 06-Апр-17, (88)   К сожалению, это заблуждение, которое развеивается простым разбором кода публику, добрый (?), 18:57 , 05-Апр-17, (65) +2   Наделла решил посетить форум и дать советы окружающим Давно ли шпионаж в винде, Гость (??), 20:36 , 05-Апр-17, (67) –1   что бы быть откровенными - в grsecurity тоже хватает ляпов и вполне не однозначн, Аноним (-), 23:31 , 05-Апр-17, (73)   Примеры ляпов и неоднозначных решений можете привести , добрый (?), 23:40 , 05-Апр-17, (74)   К примеру попытка создать свой аналог LSM, вместо того что бы брать адаптирова, Аноним (-), 23:57 , 05-Апр-17, (76)   Почему и зачем это сделано, можно прочитать здесь https www grsecurity net ls, добрый (?), 04:20 , 06-Апр-17, (83)   Так все пишут - нас старое не устраивает долой диктат - будем жить по новому , Аноним (-), 07:45 , 06-Апр-17, (86)   Это неконструктивный разговор Всю аргументацию по ссылке вы свели к нас не уст, добрый (?), 09:13 , 06-Апр-17, (87)   Вот вы еще раз и подчеркнули мой ответ Вместо того что бы развивать инфраструкт, Аноним (-), 13:27 , 06-Апр-17, (89)   Всё с вами ясно Если кому-нибудь ещё интересна данная тема, пишите свои вопросы,, добрый (?), 17:15 , 06-Апр-17, (91)   увы Не оценили Как и сама позиция закрывать патчи на GPL продукт Оно вроде бы , Аноним (-), 22:21 , 06-Апр-17, (92) –1   Ах, вот оно что , добрый (?), 01:57 , 07-Апр-17, (93)   а вы как хотели идете по стопам SWSoft Parallels и тп которые сначала сделали, Аноним (-), 17:28 , 07-Апр-17, (95)   в догонку ляп -862,7 877,7 static int userns_install struct nsproxy nspr, Аноним (-), 00:03 , 06-Апр-17, (78)   так это как раз - хороший, правильный баг, какие раз в пять лет бывают жаль тол, пох (?), 00:03 , 06-Апр-17, (77)   а если он есть вот бывает же и так что админишь не localhost , Аноним (-), 00:27 , 06-Апр-17, (79)   ну я вот админил нелокалхост, а Emulex 10Gbps iSCSI - BladeEngine 2 почему-то , пох (?), 13:36 , 06-Апр-17, (90)   а если у некоторых NAS - это так сказать жизнь причем это не самая плохая жел, Аноним (-), 02:10 , 07-Апр-17, (94)   Вы это серьёзно Даже опубликованных подобных уязвимостей нередко случается боль, добрый (?), 04:52 , 06-Апр-17, (84)   Linux на IoT не нужен Пусть лучше KasperskyOS используют , Tita_M (ok), 07:28 , 05-Апр-17, (13) –1 // BolgenOS для кого писали , A.Stahl (ok), 08:27 , 05-Апр-17, (19) +2 А сколько устройств не получают обновления Это проблемы пользователей Ну-, vitektm (?), 14:54 , 05-Апр-17, (57) // Пользователю отключают интернет за вредоносную активность, и проблема становится, L29Ah (ok), 04:18 , 06-Апр-17, (81) Если бы андроидные устройства большинство из них еще и получали обновления , Аноним (-), 00:29 , 05-Апр-17, (4) +13 // А ты бери те устройства, на которые можно установить правильное обновление сразу, Аноним (-), 09:04 , 05-Апр-17, (22) –2 // Ты бы сам этим попользовался как основным смартфоном этак хотя бы месяц, а потом, iPony (?), 09:38 , 05-Апр-17, (28) +1 Так продаж небудет , vi (ok), 23:47 , 05-Апр-17, (75) Жаль, что нет готового эксплоита, в публичном доступе, уже скомпиленного Это вы, Адекват (ok), 06:52 , 05-Апр-17, (11) –3 // Ну что за чушь Итак больше половины линуксовых серверов торчат с софтом, содерж, iPony (?), 06:58 , 05-Апр-17, (12) +2 // Что за ерунду вы все тут порете ВСЕ НОРМАЛЬНЫЕ КОНТОРЫ всегда выстраивают инфрас, Аноним (-), 08:11 , 05-Апр-17, (16) +1 // Ну да, в твоем идеальном мире существуют одни нормальные конторы с хорошим ит от, Аноним (-), 11:16 , 05-Апр-17, (38) где, где портал в этот мир В моем если они где-то и существуют, то очень хорошо, пох (?), 12:46 , 05-Апр-17, (44) так речь-то о том, что другие меньше половины все равно имеют не широко извест, пох (?), 12:41 , 05-Апр-17, (43) +1 // подробнее про улучшизмы можно о чём вообще речь , J.L. (?), 12:52 , 05-Апр-17, (46) Еще, еще, бро Еще немного - и пригласят в редмонд , Аноним (-), 09:30 , 05-Апр-17, (25) +1 Arch Linux на втором месте по скорости исправления уязвимостей, по мнению шефа с, iZEN (ok), 09:32 , 05-Апр-17, (26) –1 // А redhat в среднем исправляет за 80 дней , kerneliq (ok), 10:23 , 05-Апр-17, (34) Опять не смог прочитать новость дальше первого абзаца , angra (ok), 09:49 , 05-Апр-17, (30) судя по данным шапки - есть Бага в тихую поправлена в -327 16 O-Subject PATCH, Аноним (-), 10:07 , 05-Апр-17, (31) // Тесткейс 8212 это ещё не эксплойт , анонимус вульгарис (?), 12:59 , 05-Апр-17, (48) // хорошо повторяй как мантру - тест кейс это не эксплойт - ведь поможет и защит, Аноним (-), 17:17 , 05-Апр-17, (61) блин, это у шапки есть, а просили - в публичном доступе Я тоже хочу Можно даже , пох (?), 15:22 , 05-Апр-17, (60) // Тем кому нужен он есть и давно Ты так уверен то есть падение ядра это не , Аноним (-), 17:18 , 05-Апр-17, (62) мне, мне нужен, у меня нет у меня ж масса друзей вываливание трейса и даже , пох (?), 17:25 , 05-Апр-17, (63) там таки падение - но ты повторяй мантру все хорошо дыр в линуксе нету я в , Аноним (-), 23:22 , 05-Апр-17, (71) –1 Кстати как всегда жутко утрируешь Глянька лучше на IoT и ведрофоны Там как пра, Аноним (-), 11:31 , 05-Апр-17, (39) // про винду я ничего не сказал, я просто пальцем ткнул, а у фанатов опять бомбанул, Адекват (ok), 13:55 , 05-Апр-17, (53) +1 // ентож опеннет, ты чо хотел-то ну, не совсем Надо еще найти что-то, что слушает , пох (?), 15:04 , 05-Апр-17, (59) Ну взломают сервер А тебе-то что с этого В кармане прибавится Или завышенное , Гость (??), 20:39 , 05-Апр-17, (68) –1 // эмм если это банальный вебсервер конкурентов э lor,к примеру, vs opennet , Аноним (-), 03:24 , 08-Апр-17, (96) +1 Основные новости про open source в последнее время это обнаружена уязвимость , Джо (?), 07:50 , 05-Апр-17, (14) // Чистое вранье , Аноним (-), 08:15 , 05-Апр-17, (17) +3 // I Here we are in 2013 onwards ,,, I http www opennet ru openforum vsl, Andrey Mitrofanov (?), 09:46 , 05-Апр-17, (29) –1 // Глупости какие-то Эмблемы и логотипы получили реально стоящие уязвимости, а их , iPony (?), 12:04 , 05-Апр-17, (42) Азура Господи, не смешите, это на уровне сервелата, скоро сдoхнет, если еще не , Аноним (-), 20:11 , 05-Апр-17, (66) –2 3 из 5 новости в Последние новости opennet сейчас в топе - это обнаружена уяз, Джо (?), 10:24 , 05-Апр-17, (36) –1 // А я смог посмотреть на новости так что из 3 новостей нашел 3 про уязвимости Вид, Аноним (-), 14:29 , 05-Апр-17, (56) Всё больше глаз смотрят в код Если долго всматриваться в бездну, то бездна нач, iZEN (ok), 09:33 , 05-Апр-17, (27) Так замечательно же Не замалчивают, как некоторые , анонимус вульгарис (?), 13:01 , 05-Апр-17, (49) Интересно, есть ли и будут ли обновления безопасности для Nexus 5 Или Гугл таки, Аноним (-), 08:01 , 05-Апр-17, (15) // Не будет - три года прошло , iPony (?), 08:15 , 05-Апр-17, (18) // Модель не потеряла своей актуальности Я понимаю, если бы её аппаратные возможно, Аноним (-), 09:09 , 05-Апр-17, (24) А Что именно Nexus 5На руках у людей зачастую трубки, купленные два-три года и , mmm (??), 08:45 , 05-Апр-17, (20) http plasma-phone org nexus-5 только брать не старую, а свежею с новым ядром , Аноним (-), 09:08 , 05-Апр-17, (23) –1 // С таким же успехом можно выкинуть смартфон и купить звонилку Под это есть при, Аноним (-), 10:23 , 05-Апр-17, (35) // Вы не полняль Оно шутит , аж форсит, что под это есть _обновления безопасности, Andrey Mitrofanov (?), 10:26 , 05-Апр-17, (37) чихать гугл хотел на пользователей В отличие от яблока, они с его сервиса уже н, пох (?), 14:56 , 05-Апр-17, (58) Подробности http samtizen blogspot com 2017 04 tizen-os html, Yuri (??), 00:11 , 09-Апр-17, (97) // Amihai Neiderman не первый раз выступает на профильных конференциях и известен к, Аноним (-), 01:14 , 09-Апр-17, (98) // gt оверквотинг удален Спросите у знакомых евреев из IT-сферы что это за универ, Yuri (??), 01:47 , 09-Апр-17, (99) 1,4,11,14,15,97

Сообщения

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

	2. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	+18 +/–
	Сообщение от Экспертуос (?), 04-Апр-17, 23:29
	Так ведь это же превосходно! Только тут уже не палочкой ковыряют, а под микроскопом. Linux давно-давно вырос из студенческого проекта в проект всемирной значимости.
	Ответить | Правка | Наверх | Cообщить модератору

	33. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	–2 +/–
	Сообщение от Аноним (-), 05-Апр-17, 10:15
	> Так ведь это же превосходно! Только тут уже не палочкой ковыряют, а > под микроскопом. Linux давно-давно вырос из студенческого проекта в проект всемирной > значимости. палочкой.. палочкой. До мирокскопа не дожили. Слишком уж дырявый - если посмотреть на комит логи от шапки.. Там в каждом обновлении десятки-сотни дыр правят. Вот к примеру 514.2 -> 514.10 - поправлено 10 секурных багов, тихо.. без анонсов.. Краткий список acpi-acpi-ipmi-Fix-potential-response-buffer-overflow   block-blk-mq-Fix-NULL-pointer-updating-nr_requests scsi-be2iscsi-Fix-bad-WRB-index-error   x86-kvm-x86-Check-memopp-before-dereference vfio-pci-Fix-integer-overflows-bitmask-check   acpi-acpi-ipmi-Fix-race-caused-by-the-unprotected-ACPI-IPMI-user   net-packet-fix-race-condition-in-packet_set_ring   Но можно дальше жить считая что в мире линукса все хорошо.. все хорошо..
	Ответить | Правка | Наверх | Cообщить модератору

	45. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	+/–
	Сообщение от J.L. (?), 05-Апр-17, 12:47
	> палочкой.. палочкой. До мирокскопа не дожили. Слишком уж дырявый - если посмотреть > на комит логи от шапки.. Там в каждом обновлении десятки-сотни дыр > правят. > Но можно дальше жить считая что в мире линукса все хорошо.. все > хорошо.. всё не хорошо, но всё куда лучше чем во всех других альтернативах именно этим хорош опенсорс и линукс в частности а когда до мантейнеров дистрибов дойдёт что пора втягивать юзерэкспиренс из винды по защите юзера от программ и программ юзера от других программ, юзерфрендли фаерволы, юзерфрендли настройки ограничений для программ и тд и тп - вообще счастье наступит
	Ответить | Правка | Наверх | Cообщить модератору

	52. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	–3 +/–
	Сообщение от пох (?), 05-Апр-17, 13:47
	> всё не хорошо, но всё куда лучше чем во всех других альтернативах "чем лучше - чем в других". Ничем не лучше, с тех пор как в головах разработчиков и advocacy засела идиотская мысль "как windows, только нахаляву". > а когда до мантейнеров дистрибов дойдёт что пора втягивать юзерэкспиренс из винды по > защите юзера от программ и программ юзера от других программ, то только тyпой юзер и захочет с этим работать. Умный поймет, что еще одна винда "только нахаляву" (что выливается в поддержку на от..сь) ему совершенно и не нужна.
	Ответить | Правка | Наверх | Cообщить модератору

	47. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	+/–
	Сообщение от пох (?), 05-Апр-17, 12:55
	> палочкой.. палочкой. До мирокскопа не дожили. Слишком уж дырявый - если посмотреть > на комит логи от шапки.. Там в каждом обновлении десятки-сотни дыр следует понимать, что эти "cотни" на самом деле еще обычно очень непросто использовать. > Вот к примеру 514.2 -> 514.10 - поправлено 10 секурных багов, тихо.. > без анонсов.. во-первых, скорее всего это банальные бэкпорты из апстрима. Во-вторых, из всего списка разьве что > x86-kvm-x86-Check-memopp-before-dereference > vfio-pci-Fix-integer-overflows-bitmask-check вот эта парочка интересна для большинства обывателей - и то при условии, что они то или другое в принципе используют. > Но можно дальше жить считая что в мире линукса все хорошо.. все > хорошо.. то что в топике - не очень хорошо, в отличие от процитированной банальщины. И, если я правильно понимаю, до сих пор в 6 не исправлено, и даже не понятно, уязвимость-то есть ли?
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	50. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	+/–
	Сообщение от пох (?), 05-Апр-17, 13:04
	> И, если я правильно понимаю, до сих пор в 6 > не исправлено, и даже не понятно, уязвимость-то есть ли? потыкав палочкой - если она вообще есть, то и в 6 есть :-( как это работает и почему invalid checksum может проявляться в случае когда чексамминг НЕ выполняется - за недостатком времени и вдохновения разбираться не стал.
	Ответить | Правка | Наверх | Cообщить модератору

	51. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	+/–
	Сообщение от пох (?), 05-Апр-17, 13:12
	> :-( как это работает и почему invalid checksum может проявляться в а, вот оно что - оно просто второй раз ее считало, когда как раз валидна, при этом что-то ломая (видимо, уже не проверяя в этом случае, что есть куда писать).
	Ответить | Правка | Наверх | Cообщить модератору

	64. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	+/–
	Сообщение от Аноним (-), 05-Апр-17, 17:49
	> следует понимать, что эти "cотни" на самом деле еще обычно очень непросто использовать. или просто не знаешь как это использовать. > во-первых, скорее всего это банальные бэкпорты из апстрима. Во-вторых, из всего списка разьве что То есть бэкпорт security fix апсптрима - перестает таковым быть? ну да, большая часть это не удаленные уязвимости - но.. 7.2->7.3 $ ls -1 patches | grep -c -i overflow 46 $ ls -1 patches | grep -c -i deref 48 $ ls -1 patches | grep -c -i panic 36 $ ls -1 patches | grep -c -i corrupt 53 вот и к двум сотенкам подобрались.. фигня вопрос :-)
	Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

	69. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	+/–
	Сообщение от пох (?), 05-Апр-17, 21:23
	> или просто не знаешь как это использовать. знаю, надо иметь уникальные компоненты в сервере, в системе и в инфраструктуре, и еще желателен рут...ой, а зачем мне тогда эксплойты? > То есть бэкпорт security fix апсптрима - перестает таковым быть? то есть не надо стонать по поводу "молча и без анонсов". Хотите анонсов - следите за патчами в наираспоследней версии vanilla kernel Если случается линухокапец, как вот с udp.c - анонс случается тоже. (вот то что в rhel 6.чтоунастам-9? до сих пор не поправлено - это, кстати, занятно. Зато они вчерась прислали мне письмо электрическое, что героически победили CVE-2016-8399 - это вот как раз из серии "и еще, конечно же, желательно быть рутом на экслойтируемой системе")
	Ответить | Правка | Наверх | Cообщить модератору

	70. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	+/–
	Сообщение от Аноним (-), 05-Апр-17, 23:20
	> знаю, надо иметь уникальные компоненты в сервере, в системе и в инфраструктуре, и еще желателен рут...ой, а зачем мне тогда эксплойты? Гонишь. крепко. commit 4eb919825e6c3c7fb3630d5621f6d11e98a18b3a Author: Rik van Riel <riel@redhat.com> Date:   Thu Jan 2 12:58:46 2014 -0800     mm: fix use-after-free in sys_remap_file_pages ой.. специальное оборудование надо.. > то есть не надо стонать по поводу "молча и без анонсов". Хотите анонсов - следите за патчами в наираспоследней версии vanilla kernel Слив засчитан. Разговор идет о том что количество дыр в "стабильном" и "безопасном" линуксе исчисляется сотнями. А почему при этом обижаться на слово дырявость.. > Если случается линухокапец, как вот с udp.c - анонс случается тоже. точно? вот поправили еще в октябре - тихо. При этом не поправили в el6 - что смешно.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	+/–
	Сообщение от пох (?), 06-Апр-17, 00:36
	>> знаю, надо иметь уникальные компоненты в сервере, в системе и в инфраструктуре, и еще желателен рут...ой, а зачем мне тогда эксплойты? > Гонишь. крепко. > Date:   Thu Jan 2 12:58:46 2014 -0800 ну и какое милые, у вас, тыщелетье на дворе-то? Речь шла о том, что из "прямо вчера поправленно аж 10 секурных багов, ужас-ужас" реально вылезти, и то не в самом распространенном сценарии, могут аж два. И то не факт что exploitable >> Если случается линухокапец, как вот с udp.c - анонс случается тоже. > точно? вот поправили еще в октябре - тихо. При этом не поправили а чего опять же орать, когда опять "прищемил в году минувшем"? Коммит-то аж 2015го года, 2016-м баг помечен когда какой-то коммерческий клиент не поленился прислать редхатоидам код. Причем уже на момент коммита - давно неактуальный для текущих версий, там вообще все переписали по другому. > в el6 - что смешно. ну прочавкал индус, что есть еще и второе дерево, бывает - тикет небось счастливый юзверь семерки открывал. Ща другой (этот уже давно эффективным менеджером в другой компании бабки пилит) получит палкой, вcосет в 6. А может этот патч вообще на 2.6.32 не ложится, не качать же его только чтоб посмотреть.
	Ответить | Правка | Наверх | Cообщить модератору

	85. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	+/–
	Сообщение от Аноним (-), 06-Апр-17, 07:33
	> ну и какое милые, у вас, тыщелетье на дворе-то? Речь шла о том, что из "прямо вчера поправленно аж 10 секурных багов, ужас-ужас" реально вылезти, и то не в самом распространенном сценарии, могут аж два. И то не факт что exploitable прямо вчера. Это из все тех же патчей RHEL7.2->RHEL7.3. Открой глаза :-) > а чего опять же орать, когда опять "прищемил в году минувшем"? Коммит-то аж 2015го года, 2016-м баг помечен когда какой-то коммерческий клиент не поленился прислать редхатоидам код. то есть как минимум год, а тут получается и все 2, коммерческий супер пупер защищенный линукс, за который платят деньги не малые - был дырявым. > ну прочавкал индус, что есть еще и второе дерево, бывает - тикет небось счастливый юзверь семерки открывал. Хорошо отмазываешся. Для этого есть специальные люди которые за этим сделать должны. Но вы не стесняйтесь - жрите что дают. Патч кстати ложился на ура.
	Ответить | Правка | Наверх | Cообщить модератору

	72. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	+/–
	Сообщение от vi (ok), 05-Апр-17, 23:31
	> вот и к двум сотенкам подобрались.. фигня вопрос :-) А теперь и в относительных величинах покажите пожалуйста! Анонутик Вы наш ;)
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

	88. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	+/–
	Сообщение от Аноним (-), 06-Апр-17, 13:18
	когда вас будут иметь через дыры - вас будет интересовать сколько всего патчей или только те через которые вас поимели ?
	Ответить | Правка | Наверх | Cообщить модератору

	65. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	+2 +/–
	Сообщение от добрый (?), 05-Апр-17, 18:57
	> следует понимать, что эти "cотни" на самом деле еще обычно очень непросто использовать К сожалению, это заблуждение, которое развеивается простым разбором кода публикуемых эксплойтов и анализом количества и сложности техник обхода защит, которые там используются. Хороший пример, из последних (обратите внимание на простоту отключения SMEP): https://a13xp0p0v.github.io/2017/03/24/CVE-2017-2636.html С самозащитой ядра в линуксе дела обстоят очень плохо (в сравнении с современной виндой и iOS, например). Большинство тех механизмов защиты, которые реализованы, либо всё ещё нуждаются в необходимом дополнении другими, либо имеют серьёзные изъяны, либо не имеют практического смысла. При этом множество фич, таких как непривилегированные user и network namespaces, eBPF, только увеличивают поверхность атаки и открывают пути к эксплуатации кода, который изначально не писался с оглядкой на защиту от эксплуатации (со стороны root или capable-процессов, которые на момент написания являлись единственными его пользователями). И то, чем преимущественно сейчас занимается Kernel Self-Protection Project - это неумелое и, что важнее, бессистемное портирование (читай: копипаста с ошибками) "низко висящих фруктов" из патча Grsecurity (который, к тому же, в ближайшие недели пропадёт из публичного доступа). Этим не достигается практически ничего, кроме создания ложного чувства безопасности у пользователей и ложного имиджа линукс как ОС с современным подходом к безопасности. Из последних перлов: http://www.openwall.com/lists/kernel-hardening/2017/03/23/3 - "защита" от нападающего с примитивами arbitrary read+write, доступность которых делает такую и все подобные "защиты" бесполезными. http://www.openwall.com/lists/kernel-hardening/2017/04/04/10 - патч, который добавляет ещё одну ситуацию гонки за запись в память к уже существующей, от которой по задумке должен защищать. Почему так происходит? Не выработана и не принята модель угроз, в её рамках не ведётся системная работа. Сообщество продемонстрировало нежелание или неспособность критически оценивать ситуацию и формировать спрос на её исправление. А в свою очередь бизнесу, построенному на базе линукса и СПО, выгодно поддерживать статус кво, поскольку маркетинг, вводящий в заблуждение на фоне практической неспособности потребителя оценить искомые качества (безопасность), даёт прибыльность и обходится гораздо дешевле реальной технической работы.
	Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

	67. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	–1 +/–
	Сообщение от Гость (??), 05-Апр-17, 20:36
	Наделла решил посетить форум и дать советы окружающим. Давно ли шпионаж в "винде" априори стал законным?
	Ответить | Правка | Наверх | Cообщить модератору

	73. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	+/–
	Сообщение от Аноним (-), 05-Апр-17, 23:31
	>> следует понимать, что эти "cотни" на самом деле еще обычно очень непросто использовать > И то, чем преимущественно сейчас занимается Kernel Self-Protection Project - это неумелое > и, что важнее, бессистемное портирование (читай: копипаста с ошибками) "низко висящих > фруктов" из патча Grsecurity (который, к тому же, в ближайшие недели > пропадёт из публичного доступа). что бы быть откровенными - в grsecurity тоже хватает ляпов и вполне не однозначных решений. Но в целом забавный патч который пилят с оглядкой на то от чего же мы защищаемся.
	Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

	74. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	+/–
	Сообщение от добрый (?), 05-Апр-17, 23:40
	> что бы быть откровенными - в grsecurity тоже хватает ляпов и вполне > не однозначных решений. Примеры ляпов и неоднозначных решений можете привести? :)
	Ответить | Правка | Наверх | Cообщить модератору

	76. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	+/–
	Сообщение от Аноним (-), 05-Апр-17, 23:57
	>> что бы быть откровенными - в grsecurity тоже хватает ляпов и вполне >> не однозначных решений. > Примеры ляпов и неоднозначных решений можете привести? :) К примеру попытка создать свой аналог LSM, вместо того что бы брать / адаптировать готовую инфраструктуру. Сомнительное удовольствие как по мне, увеличивающее размер изменений. +       if (!gr_acl_handle_mkdir(dentry, path.dentry, path.mnt)) { +               error = -EACCES; +               goto out; +       }         error = security_path_mkdir(&path, dentry, mode); даже теже аргументы. Сомнительное переименование atomic / atomic_unchecked, увеличение патча без толку. Теже атрибуты могли встроиться в обычный atomic, а для нужных и так заводится тип. замены типа         struct fd f = fdget(fd); -       struct dentry *dentry;         int error = -EBADF;         if (!f.file)                 return error; -       dentry = f.file->f_path.dentry; -       audit_inode(NULL, dentry, 0); +       audit_inode(NULL, f.file->f_path.dentry, 0); которые просто лишние, зато влияют на время инспекций. это так.. @@ -258,19 +259,19 @@ static ssize_t process_vm_rw_core(pid_t pid, const struct iovec *lvec,         size_t iov_l_curr_offset = 0;         ssize_t iov_len; +       return -ENOSYS; // PaX: until properly audited +         /*          * Work out how many pages of struct pages we're going to need          * when eventually calling get_user_pages          */         for (i = 0; i < riovcnt; i++) {                 iov_len = rvec[i].iov_len; -               if (iov_len > 0) { -                       nr_pages_iov = ((unsigned long)rvec[i].iov_base -                                       + iov_len) -                               / PAGE_SIZE - (unsigned long)rvec[i].iov_base -                               / PAGE_SIZE + 1; -                       nr_pages = max(nr_pages, nr_pages_iov); -               } +               if (iov_len <= 0) +                       continue; +               nr_pages_iov = ((unsigned long)rvec[i].iov_base + iov_len) / PAGE_SIZE - +                               (unsigned long)rvec[i].iov_base / PAGE_SIZE + 1; +               nr_pages = max(nr_pages, nr_pages_iov);         }         if (nr_pages == 0) -- --- a/mm/shmem.c +++ b/mm/shmem.c @@ -33,7 +33,7 @@ #include <linux/swap.h> #include <linux/aio.h> -static struct vfsmount *shm_mnt; +struct vfsmount *shm_mnt; Опа.. теперь любой полазив в system.map может добраться сюда..
	Ответить | Правка | Наверх | Cообщить модератору

	83. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	+/–
	Сообщение от добрый (?), 06-Апр-17, 04:20
	> К примеру попытка создать свой аналог LSM, вместо того что бы брать > / адаптировать готовую инфраструктуру. > Сомнительное удовольствие как по мне, увеличивающее размер изменений. Почему и зачем это сделано, можно прочитать здесь: https://www.grsecurity.net/lsm.php > Сомнительное переименование atomic / atomic_unchecked, увеличение патча без толку. Теже В каком смысле, переименование? У atomic_t и atomic_unchecked_t разная семантика и соответствующие наборы функций операций, с проверками на переполнение и без них. Чуть подробнее об этом можно прочитать здесь: https://forums.grsecurity.net/viewtopic.php?f=3&t=2750#p11162 > атрибуты могли встроиться в обычный atomic, а для нужных и так > заводится тип. О каких атрибутах речь? У обоих типов он только один, counter. "заводится тип" - это вы про refcount_t? Он-то как раз и есть велосипед с квадратными колёсами, снижающий производительность: https://lwn.net/Articles/718275/ Помимо самой заметки, стоит обратить внимание на два последних комментария от zyzzyva и PaX Team. > которые просто лишние, зато влияют на время инспекций. Дело вкуса. Ляпом это назвать никак нельзя. > @@ -258,19 +259,19 @@ static ssize_t process_vm_rw_core(pid_t pid, const struct iovec *lvec, > +       return -ENOSYS; // PaX: until properly audited Это соответствует моим ожиданиям как пользователя патча, с тем уточнением, что мои ядра вообще собраны без поддержки process_vm_*. :) То есть, тоже субъективно. Bikeshedding в любом случае. Сравнивать подобные якобы "ляпы" с серьёзными изъянами в результатах работы KSPP - совершенно некорректно. > -static struct vfsmount *shm_mnt; > +struct vfsmount *shm_mnt; > Опа.. теперь любой полазив в system.map может добраться сюда.. А пара десятков тысяч других подобных определений в коде ядра вас не смущают? :) > в догонку ляп. > > -       if (current->fs->users != 1) > +       if (atomic_read(*t->fs->users) != 1) >                return -EINVAL; > > если открыть стандарт - reading always atomic if integer type size less or same than long. > так что эта замена вызовет только лишние LOCK по шине и тормоза. > Так и еще замены подобные есть. Вы это серьёзно или подкалываете? Атомарность чтения как операции не имеет совершенно никакого отношения к валидности значения при его конкурентном чтении и записи из нескольких параллельных потоков. Согласно стандарту, поведение в таких случаях не определено. Зачем бы тогда вообще atomic_read нужен был? > вообщем оно хорошо, но надо быть честным - есть ляпы и там. Наверное, всё-таки действительно надо быть честным и признать, что если смысл чего-либо неясен на первый взгляд, это ещё не значит, что его нет? :)
	Ответить | Правка | Наверх | Cообщить модератору

	86. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	+/–
	Сообщение от Аноним (-), 06-Апр-17, 07:45
	>> К примеру попытка создать свой аналог LSM, вместо того что бы брать >> / адаптировать готовую инфраструктуру. >> Сомнительное удовольствие как по мне, увеличивающее размер изменений. > Почему и зачем это сделано, можно прочитать здесь: https://www.grsecurity.net/lsm.php Так все пишут - "нас старое не устраивает" "долой диктат - будем жить по новому". Можно много чего писать, но факт остается фактом - дублирование инфраструктуры - никого до добра не доводило. Ну и странно было бы потом обсуждать "а чего не включают в ядро" когда сами разработчики положили болт и самоустранились. >> Сомнительное переименование atomic / atomic_unchecked, увеличение патча без толку. Теже > В каком смысле, переименование? У atomic_t и atomic_unchecked_t разная семантика и соответствующие > наборы функций операций, с проверками на переполнение и без них. Чуть > подробнее об этом можно прочитать здесь: https://forums.grsecurity.net/viewtopic.php?f=3&t=2750#p11162 Фактически весь atomic_t был переименован в atomic_uncheked и дальше применяются все проверки. Теперь задумайтесь что мешало использовать инверсию. Ввести тип atomic_checked  .. а в atomic_t добавить все проверки которые сделаны внутри atomic_unchecked. Да ничего - кроме вкуса, а это серьезно уменьшит патч и автоматом занесет весь код в разряд не проверенных. > "заводится тип" - это вы про refcount_t? Он-то как раз и есть > велосипед с квадратными колёсами, снижающий производительность: https://lwn.net/Articles/718275/ о типах atomic_t / atomic_unchecked. > Помимо самой заметки, стоит обратить внимание на два последних комментария от zyzzyva > и PaX Team. >> которые просто лишние, зато влияют на время инспекций. > Дело вкуса. Ляпом это назвать никак нельзя. Любое увеличение размера изменений без добавления функциональности - увеличивает вероятность ошибки. И с этим надо считаться. Если для вас это дело в куса... >> @@ -258,19 +259,19 @@ static ssize_t process_vm_rw_core(pid_t pid, const struct iovec *lvec, >> +       return -ENOSYS; // PaX: until properly audited > Это соответствует моим ожиданиям как пользователя патча, с тем уточнением, что мои > ядра вообще собраны без поддержки process_vm_*. :) То есть, тоже субъективно. > Bikeshedding в любом случае. Сравнивать подобные якобы "ляпы" с серьёзными изъянами > в результатах работы KSPP - совершенно некорректно. Вообще там сначала мы пытаемся что-то почтить, потом просто поставили return в начале функции. Спрашивается зачем те изменения что есть? Начали и бросили? >> -static struct vfsmount *shm_mnt; >> +struct vfsmount *shm_mnt; >> Опа.. теперь любой полазив в system.map может добраться сюда.. > А пара десятков тысяч других подобных определений в коде ядра вас не > смущают? :) Смущают. Но эти изменения писали люди без оглядки на безопасность. >[оверквотинг удален] >> +       if (atomic_read(*t->fs->users) != 1) >>                return -EINVAL; >> >> если открыть стандарт - reading always atomic if integer type size less or same than long. >> так что эта замена вызовет только лишние LOCK по шине и тормоза. >> Так и еще замены подобные есть. > Вы это серьёзно или подкалываете? Атомарность чтения как операции не имеет совершенно > никакого отношения к валидности значения при его конкурентном чтении и записи > из нескольких параллельных потоков. Согласно стандарту, поведение в таких случаях не > определено. Зачем бы тогда вообще atomic_read нужен был? Это надо спросить у тех кто делал такую замену. Общий локинг вокруг fs->users не менялся, но вот зачем-то туда запихали atomic_. Возможно было проще контролировать переполнения так, возможно какие-то еще идеи. Но ... >> вообщем оно хорошо, но надо быть честным - есть ляпы и там. > Наверное, всё-таки действительно надо быть честным и признать, что если смысл чего-либо > неясен на первый взгляд, это ещё не значит, что его нет? > :) Есть вещи которых можно добиться слегка иначе, проще и не увеличивая размер изменений. Это таки ляпы.
	Ответить | Правка | Наверх | Cообщить модератору

	87. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	+/–
	Сообщение от добрый (?), 06-Апр-17, 09:13
	>> Почему и зачем это сделано, можно прочитать здесь: https://www.grsecurity.net/lsm.php > Так все пишут - "нас старое не устраивает" "долой диктат - будем > жить по новому". Это неконструктивный разговор. Всю аргументацию по ссылке вы свели к "нас не устраивает". > Можно много чего писать, но факт остается фактом - дублирование инфраструктуры - Факт в том, что существующая инфраструктура не предоставляет всю необходимую функциональность, не позволяет использовать RBAC совместно с другими LSM и своим присутствием в ядре создаёт дополнительные риски безопасности. > никого до добра не доводило. Ну и странно было бы потом > обсуждать "а чего не включают в ядро" когда сами разработчики положили > болт и самоустранились. Разработчики Grsecurity никогда не пытались и не изъявляли желания включить свой патч в апстрим. > Фактически весь atomic_t был переименован в atomic_uncheked и дальше применяются все проверки. Фактически - в дополнение к существующему типу добавили ещё один. А не переименовали, как вы упорно утверждаете. atomic_t в большинстве случаев используется для подсчёта ссылок и переполняться не должен, а atomic_unchecked_t и аналогами помечены немногочисленные остальные случаи. > Теперь задумайтесь что мешало использовать инверсию. Ввести тип atomic_checked  .. а > в atomic_t добавить все проверки которые сделаны внутри atomic_unchecked. Да ничего > - кроме вкуса, а это серьезно уменьшит патч и автоматом занесет > весь код в разряд не проверенных. Проверки добавлены не "внутри atomic_unchecked", а для atomic_t. Сделано ровно то, о чём вы говорите. > Любое увеличение размера изменений без добавления функциональности - увеличивает вероятность > ошибки. И с этим надо считаться. Если для вас это дело вкуса... Всё это не более, чем максимализм и казуистика. Во-первых, пример ничтожный во всех смыслах. Во-вторых, изначальный код имел больший объём на то же количество логики - против такой дополнительной сложности у вас почему-то возражений не возникло. > Вообще там сначала мы пытаемся что-то почтить, потом просто поставили return в > начале функции. Спрашивается зачем те изменения что есть? Начали и бросили? Затем, чтобы продолжить в следующий раз, когда более приоритетные задачи будут решены. > Смущают. Но эти изменения писали люди без оглядки на безопасность. Какие именно, эти? Приведённые вами, из патча Grsecurity? Если да, то они на безопасность никак негативно не влияют. И ляпами не являются, поскольку были внесены по осознанной надобности. > Это надо спросить у тех кто делал такую замену. Общий локинг вокруг > fs->users не менялся, но вот зачем-то туда запихали atomic_. Возможно было > проще контролировать переполнения так, возможно какие-то еще идеи. Но ... Очевидно, что users используется в качестве счётчиков ссылок и должен быть защищён от переполнений. На производительность это не виляет практически никак. > Есть вещи которых можно добиться слегка иначе, проще и не увеличивая размер > изменений. Это таки ляпы. Вам, конечно же, виднее, как проще и лучше добиваться того, что на высочайшем профессиональном уровне в течение многих лет делают другие. ;)
	Ответить | Правка | Наверх | Cообщить модератору

	89. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	+/–
	Сообщение от Аноним (-), 06-Апр-17, 13:27
	>>> Почему и зачем это сделано, можно прочитать здесь: https://www.grsecurity.net/lsm.php >> Так все пишут - "нас старое не устраивает" "долой диктат - будем >> жить по новому". > Это неконструктивный разговор. Всю аргументацию по ссылке вы свели к "нас не > устраивает". >> Можно много чего писать, но факт остается фактом - дублирование инфраструктуры - > Факт в том, что существующая инфраструктура не предоставляет всю необходимую функциональность, > не позволяет использовать RBAC совместно с другими LSM и своим присутствием > в ядре создаёт дополнительные риски безопасности. Вот вы еще раз и подчеркнули мой ответ. Вместо того что бы развивать инфраструктуру - вы выбрали вариант "нас не устраивает, ну и плевать". Правильным ответом было бы - "а давайте обсудим и изменим инфраструктуру", но на это потребуется местами больше ресурсов и умения договариваться со всеми сторонами. А не только свое мнение иметь. >> никого до добра не доводило. Ну и странно было бы потом >> обсуждать "а чего не включают в ядро" когда сами разработчики положили >> болт и самоустранились. > Разработчики Grsecurity никогда не пытались и не изъявляли желания включить свой патч > в апстрим. >> Фактически весь atomic_t был переименован в atomic_uncheked и дальше применяются все проверки. > Фактически - в дополнение к существующему типу добавили ещё один. А не > переименовали, как вы упорно утверждаете. atomic_t в большинстве случаев используется > для подсчёта ссылок и переполняться не должен, а atomic_unchecked_t и аналогами > помечены немногочисленные остальные случаи. я вас умоляю.. количество ссылок на объекты местами тоже зашкаливает. Ровно по этому сейчас введен новый тип recount_t (см. последний месяц в LKML). >[оверквотинг удален] >> - кроме вкуса, а это серьезно уменьшит патч и автоматом занесет >> весь код в разряд не проверенных. > Проверки добавлены не "внутри atomic_unchecked", а для atomic_t. Сделано ровно то, о > чём вы говорите. >> Любое увеличение размера изменений без добавления функциональности - увеличивает вероятность >> ошибки. И с этим надо считаться. Если для вас это дело вкуса... > Всё это не более, чем максимализм и казуистика. Во-первых, пример ничтожный во > всех смыслах. Во-вторых, изначальный код имел больший объём на то же > количество логики - против такой дополнительной сложности у вас почему-то возражений > не возникло. у меня возникает возражение против любого усложнения. Бритву Окама еще никто не отменил. >> Вообще там сначала мы пытаемся что-то почтить, потом просто поставили return в >> начале функции. Спрашивается зачем те изменения что есть? Начали и бросили? > Затем, чтобы продолжить в следующий раз, когда более приоритетные задачи будут решены. запретите функцию и все. патчить.. потом кто-то сконструирует переход в недоделанный код.. >> Смущают. Но эти изменения писали люди без оглядки на безопасность. > Какие именно, эти? Приведённые вами, из патча Grsecurity? Если да, то они > на безопасность никак негативно не влияют. И ляпами не являются, поскольку > были внесены по осознанной надобности. Хуже что вы считаете их осознанной необходимостью, и не пытаетесь видеть другого. >> Это надо спросить у тех кто делал такую замену. Общий локинг вокруг >> fs->users не менялся, но вот зачем-то туда запихали atomic_. Возможно было >> проще контролировать переполнения так, возможно какие-то еще идеи. Но ... > Очевидно, что users используется в качестве счётчиков ссылок и должен быть защищён > от переполнений. На производительность это не виляет практически никак. тут я с вами очень сильно поспорю, достаточно посмотреть историю разработки ядра в VFS в частности. Как убирали atomic и заменяли spinlock + обычную переменную. Кроме того "цена" atomic растет с числом CPU. при 30 и выше это просто ужас.. а при 512 вообще смешно. >> Есть вещи которых можно добиться слегка иначе, проще и не увеличивая размер >> изменений. Это таки ляпы. > Вам, конечно же, виднее, как проще и лучше добиваться того, что на > высочайшем профессиональном уровне в течение многих лет делают другие. ;) Некоторые работают в проектах которые имеют размер не меньше gr sec, и местами требуют не меньшей надежности (если не большой). Но оставайтесь при своем мнении - не смею вам его навязывать. PS. а ляпы которые показывали в твитере - вообще смешные были. Я их сознательно сюда не копировал.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	+/–
	Сообщение от добрый (?), 06-Апр-17, 17:15
	Всё с вами ясно. Если кому-нибудь ещё интересна данная тема, пишите свои вопросы, на них постараюсь ответить.
	Ответить | Правка | Наверх | Cообщить модератору

	92. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	–1 +/–
	Сообщение от Аноним (-), 06-Апр-17, 22:21
	увы. Не оценили. Как и сама позиция закрывать патчи на GPL продукт. Оно вроде бы и не нарушение GPL, но вот душком отдает.
	Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

	93. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	+/–
	Сообщение от добрый (?), 07-Апр-17, 01:57
	> Как и сама позиция закрывать патчи на GPL продукт. Оно вроде бы > и не нарушение GPL, но вот душком отдает. Ах, вот оно что! :)
	Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

	95. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	+/–
	Сообщение от Аноним (-), 07-Апр-17, 17:28
	а вы как хотели? идете по стопам SWSoft/Parallels и тп ? которые сначала сделали virtuozzo а потом удалили патчи и никому их не показывали.
	Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

	78. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	+/–
	Сообщение от Аноним (-), 06-Апр-17, 00:03
	>> что бы быть откровенными - в grsecurity тоже хватает ляпов и вполне >> не однозначных решений. > Примеры ляпов и неоднозначных решений можете привести? :) в догонку ляп. @@ -862,7 +877,7 @@ static int userns_install(struct nsproxy *nsproxy, void *ns)         if (atomic_read(¤t->mm->mm_users) > 1)                 return -EINVAL; -       if (current->fs->users != 1) +       if (atomic_read(¤t->fs->users) != 1)                 return -EINVAL; если открыть стандарт - reading always atomic if integer type size less or same than long. так что эта замена вызовет только лишние LOCK по шине и тормоза. Так и еще замены подобные есть. вообщем оно хорошо, но надо быть честным - есть ляпы и там.
	Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

	77. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	+/–
	Сообщение от пох (?), 06-Апр-17, 00:03
	>> следует понимать, что эти "cотни" на самом деле еще обычно очень непросто использовать > Хороший пример, из последних (обратите внимание на простоту отключения SMEP): > так это как раз - хороший, правильный баг, какие раз в пять лет бывают (жаль только, их находят через еще десять) - я n_hdlc вынес со всех своих систем сразу же как увидел, не дожидаясь эксплойта. А как поэксплойтить be2iscsi, если его у тебя просто нет? ну и насчет простоты автор же явно жалуется что не так просто, просто ему повезло - баг "надежно" эксплойтится, можно не два а двадцать раз подряд успешно дергать, и рандомайзер он обошел неконвенционным путем. А цена этой дополнительной прокладки для современных процессоров околонулевая. > Почему так происходит? Не выработана и не принята модель угроз, в её > рамках не ведётся системная работа. системная ведется - это как раз и называется grsec (хотя они там и странные черезмерно). В мэйнстриме никакая системная невозможна, тебя завернут "патч слишком большой, разбейте его на двестиписят фрагментов и обоснуйте каждый", при попытке это все же сделать, одновременно вприпрыжку догоняя ляпателей новых глюков - 50 завернут или отложат в долгий ящик, сделав остальные двести бесполезными.
	Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

	79. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	+/–
	Сообщение от Аноним (-), 06-Апр-17, 00:27
	>>> следует понимать, что эти "cотни" на самом деле еще обычно очень непросто использовать >> Хороший пример, из последних (обратите внимание на простоту отключения SMEP): >> > так это как раз - хороший, правильный баг, какие раз в пять > лет бывают (жаль только, их находят через еще десять) - я > n_hdlc вынес со всех своих систем сразу же как увидел, не > дожидаясь эксплойта. А как поэксплойтить be2iscsi, если его у тебя просто > нет? а если он есть?.. вот бывает же и так что админишь не localhost..
	Ответить | Правка | Наверх | Cообщить модератору

	90. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	+/–
	Сообщение от пох (?), 06-Апр-17, 13:36
	> а если он есть?.. вот бывает же и так что админишь не localhost.. ну я вот админил нелокалхост, а "Emulex 10Gbps iSCSI - BladeEngine 2" почему-то у меня не было никогда (и постараюсь чтоб не было дальше, не люблю я nas'ы вообще и iscsi отдельно, по многим причинам). Спонтанно такие драйвера не загружаются. И если бы даже я относился к тем полутора инвалидам, у которых он есть - еще не факт что в моей конфигурации в моей сети это было бы опасно. P.S. а еще есть такая отличная штука echo /bin/false > /proc/sys/kernel/modprobe - на ядрах, любимых редхатом, отлично предотвращает загрузку ненужно. Я уже всерьез задумался гвоздем прибить туда именно это умолчание и вернуться в состояние 95го года, когда модули грузили там и тогда, когда админ считал нужным, а не выпрыгивали как чортик из табакерки по непонятным внутриядерным соображениям. Все нужное, и много лишнего, один хрен нынче модно всасывать из initrd.
	Ответить | Правка | Наверх | Cообщить модератору

	94. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	+/–
	Сообщение от Аноним (-), 07-Апр-17, 02:10
	а если у некоторых NAS - это так сказать жизнь ?:) причем это не самая плохая железка с неплохим offload iscsi протокола прям внутри сетевки. можем подискутировать о таких вот багах. O-Subject: [RHEL7.3 net] net, scm: fix PaX detected msg_controllen overflow in scm_detach_fds Upstream Commit: commit 6900317f5eff0a7070c5936e5383f589e0de7a09 Author: Daniel Borkmann <daniel@iogearbox.net> Date:   Fri Nov 20 00:11:56 2015 +0100     net, scm: fix PaX detected msg_controllen overflow in scm_detach_fds     David and HacKurx reported a following/similar size overflow triggered     in a grsecurity kernel, thanks to PaX's gcc size overflow plugin:     (Already fixed in later grsecurity versions by Brad and PaX Team.)     [ 1002.296137] PAX: size overflow detected in function scm_detach_fds net/core/scm.c:314                    cicus.202_127 min, count: 4, decl: msg_controllen; num: 0; context: msghdr;     [ 1002.296145] CPU: 0 PID: 3685 Comm: scm_rights_recv Not tainted 4.2.3-grsec+ #7     [ 1002.296149] Hardware name: Apple Inc. MacBookAir5,1/Mac-66F35F19FE2A0D05, [...]     [ 1002.296153]  ffffffff81c27366 0000000000000000 ffffffff81c27375 ffffc90007843aa8     [ 1002.296162]  ffffffff818129ba 0000000000000000 ffffffff81c27366 ffffc90007843ad8     [ 1002.296169]  ffffffff8121f838 fffffffffffffffc fffffffffffffffc ffffc90007843e60     [ 1002.296176] Call Trace:     [ 1002.296190]  [<ffffffff818129ba>] dump_stack+0x45/0x57     [ 1002.296200]  [<ffffffff8121f838>] report_size_overflow+0x38/0x60     [ 1002.296209]  [<ffffffff816a979e>] scm_detach_fds+0x2ce/0x300     [ 1002.296220]  [<ffffffff81791899>] unix_stream_read_generic+0x609/0x930 Легко заметить фикс был известен в 2015 году, Шапка же пофиксила это только в 2017. И не факт что это было не эксплуатированное. Хотя может у вас и unix sockets тоже нету?
	Ответить | Правка | Наверх | Cообщить модератору

	84. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."	+/–
	Сообщение от добрый (?), 06-Апр-17, 04:52
	> так это как раз - хороший, правильный баг, какие раз в пять > лет бывают (жаль только, их находят через еще десять) - я Вы это серьёзно? Даже опубликованных подобных уязвимостей нередко случается больше пяти в год, в числе которых в последнее время всё чаще оказываются и более "правильные" логические (см. уязвимости, порождённые непривилегированными namespaces). Другая часть уязвимостей остаётся неопубликованной, включая те, подробности о которых команда разработчиков намеренно не раскрывает. Со всеми вытекающими последствиями, вроде "скручивания" статистики по уязвимостям и невключения некоторых исправлений в дистрибутивные и даже официальные LTS-ядра с kernel.org. > ну и насчет простоты автор же явно жалуется что не так просто, > просто ему повезло - баг "надежно" эксплойтится, можно не два а Что-то я не заметил, где именно автор об этом говорит. В любом случае, относительная сложность написания эксплойта здесь не обусловлена необходимостью обхода механизмов защиты (это как раз самая тривиальная часть, о чём и речь), а семантикой самого уязвимого кода и используемых подсистем. Не существенно сложнее, чем это было во множестве случаев heap data corruption и 10, и 20 лет назад. > двадцать раз подряд успешно дергать, и рандомайзер он обошел неконвенционным путем. > А цена этой дополнительной прокладки для современных процессоров околонулевая. Количество раз, которое можно было "дёргать" баг, в данном случае никак не ограничена ни KASLR, ни SMEP, ни другими механизмами защиты. К слову, существует множество известных способов обхода KASLR, включая атаки на микроархитектуру: https://cyber.wtf/2016/10/25/micro-architecture-attacks-on-k.../ Таким образом, цена обхода KASLR для атакующего с уже имеющимся инструментарием - практически нулевая и расти не будет. > системная ведется - это как раз и называется grsec (хотя они там You don't say! :) Я говорил о работе команды разработчиков официального ядра, включая членов KSPP. В рамках Grsecurity такая, в своём роде уникальная работа действительно ведётся, но годами остаётся непонятой и непринятой сообществом.
	Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

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

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