В апрельском обновлении платформы Android в сетевой подсистеме ядра Linux устранена (https://source.android.com/security/bulletin/2017-04-01.html) критическая уязвимость (CVE-2016-10229 (https://security-tracker.debian.org/tracker/CVE-2016-10229)), позволяющая выполнить код на уровне ядра, отправив специально оформленный набор UDP-пакетов, который приводит к некорректному вычислению контрольной суммы в процессе выполнения системного вызова recv с флагом MSG_PEEK.Ошибка, вызвавшая уязвимость, была устранена (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...) боле года назад в выпусках основного ядра Linux 4.5 и 4.4.21, поэтому проблеме подвержены только версии ядра, младше 4.4.21. Уязвимость не проявляется в Debian (https://security-tracker.debian.org/tracker/CVE-2016-10229) и SUSE (https://bugzilla.novell.com/show_bug.cgi?id=CVE-2016-10229), но вероятно присутствует в openSUSE 42.1. Информации о подверженности проблеме Ubuntu (https://people.canonical.com/~ubuntu-security/cve/CVE-2016-1...) и RHEL (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-10229) пока нет.
Кроме уязвимости в UDP-стеке и уже ранее упомянутых (https://www.opennet.ru/opennews/art.shtml?num=46316) проблем в беспроводном стеке Broadcom и crypto-движке Qualcomm, в апрельском обновлении Android также устранено шесть критических уязвимостей в медиасервере, позволяющих организовать выполнение кода с правами процесса mediaserver при обработке специально оформленного контента, а также критические уязвимости в драйвере MediaTek, драйвере сенсорных экранов HTC, в подсистеме ядра ION и в различных компонентах Qualcomm. Опасные уязвимости, позволяющие поднять свои привилегии в системе, устранены в CameraBase, Audioserver, SurfaceFlinger, libskia, v8, Freetype, звуковой подсистеме ядра, различных драйверах MediaTek, Broadcom, Qualcomm и NVIDIA.
Дополнительно можно отметить заявление (https://motherboard.vice.com/en_us/article/samsung-tizen-ope...) о наличии в платформе Tizen около 40 неисправленных 0-day уязвимостей. Информация пока не подтверждена и представлена в виде голословных заявлений, данных исследователем безопасности Amihai Neiderman (https://def.camp/speakers/amihai-neiderman/) в интервью изданию Motherboard. Не ясно в каких компонентах выявлены уязвимости (судя по всему речь ведётся о проблемах в прикладных приложениях и специфичных дополнениях Samsung) и насколько эти уязвимости эксплуатируемы. В материале упоминается повсеместное использование в коде функции strcpy(), передача данных с сервисов Samsung без шифрования, удалённо эксплуатируемые уязвимости в приложении TizenStore.
URL: https://source.android.com/security/bulletin/2017-04-01.html
Новость: http://www.opennet.ru/opennews/art.shtml?num=46317
По мере проникновения IoT и прочих устройств на Linux его активней начинают ковырять палочкой расковыривая уязвимости.
Так ведь это же превосходно! Только тут уже не палочкой ковыряют, а под микроскопом. Linux давно-давно вырос из студенческого проекта в проект всемирной значимости.
> Так ведь это же превосходно! Только тут уже не палочкой ковыряют, а
> под микроскопом. 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Но можно дальше жить считая что в мире линукса все хорошо.. все хорошо..
> палочкой.. палочкой. До мирокскопа не дожили. Слишком уж дырявый - если посмотреть
> на комит логи от шапки.. Там в каждом обновлении десятки-сотни дыр
> правят.
> Но можно дальше жить считая что в мире линукса все хорошо.. все
> хорошо..всё не хорошо, но всё куда лучше чем во всех других альтернативах
именно этим хорош опенсорс и линукс в частности
а когда до мантейнеров дистрибов дойдёт что пора втягивать юзерэкспиренс из винды по защите юзера от программ и программ юзера от других программ, юзерфрендли фаерволы, юзерфрендли настройки ограничений для программ и тд и тп - вообще счастье наступит
> всё не хорошо, но всё куда лучше чем во всех других альтернативах"чем лучше - чем в других".
Ничем не лучше, с тех пор как в головах разработчиков и advocacy засела идиотская мысль "как windows, только нахаляву".> а когда до мантейнеров дистрибов дойдёт что пора втягивать юзерэкспиренс из винды по
> защите юзера от программ и программ юзера от других программ,то только тyпой юзер и захочет с этим работать.
Умный поймет, что еще одна винда "только нахаляву" (что выливается в поддержку на от..сь) ему совершенно и не нужна.
> палочкой.. палочкой. До мирокскопа не дожили. Слишком уж дырявый - если посмотреть
> на комит логи от шапки.. Там в каждом обновлении десятки-сотни дырследует понимать, что эти "cотни" на самом деле еще обычно очень непросто использовать.
> Вот к примеру 514.2 -> 514.10 - поправлено 10 секурных багов, тихо..
> без анонсов..во-первых, скорее всего это банальные бэкпорты из апстрима. Во-вторых, из всего списка разьве что
> x86-kvm-x86-Check-memopp-before-dereference
> vfio-pci-Fix-integer-overflows-bitmask-checkвот эта парочка интересна для большинства обывателей - и то при условии, что они то или другое в принципе используют.
> Но можно дальше жить считая что в мире линукса все хорошо.. все
> хорошо..то что в топике - не очень хорошо, в отличие от процитированной банальщины. И, если я правильно понимаю, до сих пор в 6 не исправлено, и даже не понятно, уязвимость-то есть ли?
> И, если я правильно понимаю, до сих пор в 6
> не исправлено, и даже не понятно, уязвимость-то есть ли?потыкав палочкой - если она вообще есть, то и в 6 есть :-( как это работает и почему invalid checksum может проявляться в случае когда чексамминг НЕ выполняется - за недостатком времени и вдохновения разбираться не стал.
> :-( как это работает и почему invalid checksum может проявляться ва, вот оно что - оно просто второй раз ее считало, когда как раз валидна, при этом что-то ломая (видимо, уже не проверяя в этом случае, что есть куда писать).
> следует понимать, что эти "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вот и к двум сотенкам подобрались.. фигня вопрос :-)
> или просто не знаешь как это использовать.знаю, надо иметь уникальные компоненты в сервере, в системе и в инфраструктуре, и еще желателен рут...ой, а зачем мне тогда эксплойты?
> То есть бэкпорт security fix апсптрима - перестает таковым быть?
то есть не надо стонать по поводу "молча и без анонсов". Хотите анонсов - следите за патчами в наираспоследней версии vanilla kernel
Если случается линухокапец, как вот с udp.c - анонс случается тоже. (вот то что в rhel 6.чтоунастам-9? до сих пор не поправлено - это, кстати, занятно. Зато они вчерась прислали мне письмо электрическое, что героически победили CVE-2016-8399 - это вот как раз из серии "и еще, конечно же, желательно быть рутом на экслойтируемой системе")
> знаю, надо иметь уникальные компоненты в сервере, в системе и в инфраструктуре, и еще желателен рут...ой, а зачем мне тогда эксплойты?Гонишь. крепко.
commit 4eb919825e6c3c7fb3630d5621f6d11e98a18b3a
Author: Rik van Riel <riel@redhat.com>
Date: Thu Jan 2 12:58:46 2014 -0800mm: fix use-after-free in sys_remap_file_pages
ой.. специальное оборудование надо..
> то есть не надо стонать по поводу "молча и без анонсов". Хотите анонсов - следите за патчами в наираспоследней версии vanilla kernel
Слив засчитан. Разговор идет о том что количество дыр в "стабильном" и "безопасном" линуксе исчисляется сотнями. А почему при этом обижаться на слово дырявость..
> Если случается линухокапец, как вот с udp.c - анонс случается тоже.
точно? вот поправили еще в октябре - тихо. При этом не поправили в el6 - что смешно.
>> знаю, надо иметь уникальные компоненты в сервере, в системе и в инфраструктуре, и еще желателен рут...ой, а зачем мне тогда эксплойты?
> Гонишь. крепко.
> Date: Thu Jan 2 12:58:46 2014 -0800ну и какое милые, у вас, тыщелетье на дворе-то? Речь шла о том, что из "прямо вчера поправленно аж 10 секурных багов, ужас-ужас" реально вылезти, и то не в самом распространенном сценарии, могут аж два. И то не факт что exploitable
>> Если случается линухокапец, как вот с udp.c - анонс случается тоже.
> точно? вот поправили еще в октябре - тихо. При этом не поправилиа чего опять же орать, когда опять "прищемил в году минувшем"? Коммит-то аж 2015го года, 2016-м баг помечен когда какой-то коммерческий клиент не поленился прислать редхатоидам код.
Причем уже на момент коммита - давно неактуальный для текущих версий, там вообще все переписали по другому.
> в el6 - что смешно.ну прочавкал индус, что есть еще и второе дерево, бывает - тикет небось счастливый юзверь семерки открывал. Ща другой (этот уже давно эффективным менеджером в другой компании бабки пилит) получит палкой, вcосет в 6.
А может этот патч вообще на 2.6.32 не ложится, не качать же его только чтоб посмотреть.
> ну и какое милые, у вас, тыщелетье на дворе-то? Речь шла о том, что из "прямо вчера поправленно аж 10 секурных багов, ужас-ужас" реально вылезти, и то не в самом распространенном сценарии, могут аж два. И то не факт что exploitableпрямо вчера. Это из все тех же патчей RHEL7.2->RHEL7.3. Открой глаза :-)
> а чего опять же орать, когда опять "прищемил в году минувшем"? Коммит-то аж 2015го года, 2016-м баг помечен когда какой-то коммерческий клиент не поленился прислать редхатоидам код.
то есть как минимум год, а тут получается и все 2, коммерческий супер пупер защищенный линукс, за который платят деньги не малые - был дырявым.
> ну прочавкал индус, что есть еще и второе дерево, бывает - тикет небось счастливый юзверь семерки открывал.Хорошо отмазываешся. Для этого есть специальные люди которые за этим сделать должны. Но вы не стесняйтесь - жрите что дают. Патч кстати ложился на ура.
> вот и к двум сотенкам подобрались.. фигня вопрос :-)
А теперь и в относительных величинах покажите пожалуйста! Анонутик Вы наш ;)
когда вас будут иметь через дыры - вас будет интересовать сколько всего патчей или только те через которые вас поимели ?
> следует понимать, что эти "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 - патч, который добавляет ещё одну ситуацию гонки за запись в память к уже существующей, от которой по задумке должен защищать.
Почему так происходит? Не выработана и не принята модель угроз, в её рамках не ведётся системная работа. Сообщество продемонстрировало нежелание или неспособность критически оценивать ситуацию и формировать спрос на её исправление. А в свою очередь бизнесу, построенному на базе линукса и СПО, выгодно поддерживать статус кво, поскольку маркетинг, вводящий в заблуждение на фоне практической неспособности потребителя оценить искомые качества (безопасность), даёт прибыльность и обходится гораздо дешевле реальной технической работы.
Наделла решил посетить форум и дать советы окружающим. Давно ли шпионаж в "винде" априори стал законным?
>> следует понимать, что эти "cотни" на самом деле еще обычно очень непросто использовать
> И то, чем преимущественно сейчас занимается Kernel Self-Protection Project - это неумелое
> и, что важнее, бессистемное портирование (читай: копипаста с ошибками) "низко висящих
> фруктов" из патча Grsecurity (который, к тому же, в ближайшие недели
> пропадёт из публичного доступа).что бы быть откровенными - в grsecurity тоже хватает ляпов и вполне не однозначных решений. Но в целом забавный патч который пилят с оглядкой на то от чего же мы защищаемся.
> что бы быть откровенными - в grsecurity тоже хватает ляпов и вполне
> не однозначных решений.Примеры ляпов и неоднозначных решений можете привести? :)
>> что бы быть откровенными - в 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 может добраться сюда..
> К примеру попытка создать свой аналог 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 нужен был?
> вообщем оно хорошо, но надо быть честным - есть ляпы и там.
Наверное, всё-таки действительно надо быть честным и признать, что если смысл чего-либо неясен на первый взгляд, это ещё не значит, что его нет? :)
>> К примеру попытка создать свой аналог 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_. Возможно было проще контролировать переполнения так, возможно какие-то еще идеи. Но ...
>> вообщем оно хорошо, но надо быть честным - есть ляпы и там.
> Наверное, всё-таки действительно надо быть честным и признать, что если смысл чего-либо
> неясен на первый взгляд, это ещё не значит, что его нет?
> :)Есть вещи которых можно добиться слегка иначе, проще и не увеличивая размер изменений. Это таки ляпы.
>> Почему и зачем это сделано, можно прочитать здесь: 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 используется в качестве счётчиков ссылок и должен быть защищён от переполнений. На производительность это не виляет практически никак.
> Есть вещи которых можно добиться слегка иначе, проще и не увеличивая размер
> изменений. Это таки ляпы.Вам, конечно же, виднее, как проще и лучше добиваться того, что на высочайшем профессиональном уровне в течение многих лет делают другие. ;)
>>> Почему и зачем это сделано, можно прочитать здесь: 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. а ляпы которые показывали в твитере - вообще смешные были. Я их сознательно сюда не копировал.
Всё с вами ясно.Если кому-нибудь ещё интересна данная тема, пишите свои вопросы, на них постараюсь ответить.
увы. Не оценили.Как и сама позиция закрывать патчи на GPL продукт. Оно вроде бы и не нарушение GPL, но вот душком отдает.
> Как и сама позиция закрывать патчи на GPL продукт. Оно вроде бы
> и не нарушение GPL, но вот душком отдает.Ах, вот оно что! :)
а вы как хотели? идете по стопам SWSoft/Parallels и тп ? которые сначала сделали virtuozzo а потом удалили патчи и никому их не показывали.
>> что бы быть откровенными - в 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 по шине и тормоза.
Так и еще замены подобные есть.вообщем оно хорошо, но надо быть честным - есть ляпы и там.
>> следует понимать, что эти "cотни" на самом деле еще обычно очень непросто использовать
> Хороший пример, из последних (обратите внимание на простоту отключения SMEP):
>так это как раз - хороший, правильный баг, какие раз в пять лет бывают (жаль только, их находят через еще десять) - я n_hdlc вынес со всех своих систем сразу же как увидел, не дожидаясь эксплойта. А как поэксплойтить be2iscsi, если его у тебя просто нет?
ну и насчет простоты автор же явно жалуется что не так просто, просто ему повезло - баг "надежно" эксплойтится, можно не два а двадцать раз подряд успешно дергать, и рандомайзер он обошел неконвенционным путем. А цена этой дополнительной прокладки для современных процессоров околонулевая.
> Почему так происходит? Не выработана и не принята модель угроз, в её
> рамках не ведётся системная работа.системная ведется - это как раз и называется grsec (хотя они там и странные черезмерно). В мэйнстриме никакая системная невозможна, тебя завернут "патч слишком большой, разбейте его на двестиписят фрагментов и обоснуйте каждый", при попытке это все же сделать, одновременно вприпрыжку догоняя ляпателей новых глюков - 50 завернут или отложат в долгий ящик, сделав остальные двести бесполезными.
>>> следует понимать, что эти "cотни" на самом деле еще обычно очень непросто использовать
>> Хороший пример, из последних (обратите внимание на простоту отключения SMEP):
>>
> так это как раз - хороший, правильный баг, какие раз в пять
> лет бывают (жаль только, их находят через еще десять) - я
> n_hdlc вынес со всех своих систем сразу же как увидел, не
> дожидаясь эксплойта. А как поэксплойтить be2iscsi, если его у тебя просто
> нет?а если он есть?.. вот бывает же и так что админишь не localhost..
> а если он есть?.. вот бывает же и так что админишь не localhost..ну я вот админил нелокалхост, а "Emulex 10Gbps iSCSI - BladeEngine 2" почему-то у меня не было никогда (и постараюсь чтоб не было дальше, не люблю я nas'ы вообще и iscsi отдельно, по многим причинам). Спонтанно такие драйвера не загружаются.
И если бы даже я относился к тем полутора инвалидам, у которых он есть - еще не факт что в моей конфигурации в моей сети это было бы опасно.P.S. а еще есть такая отличная штука echo /bin/false > /proc/sys/kernel/modprobe - на ядрах, любимых редхатом, отлично предотвращает загрузку ненужно.
Я уже всерьез задумался гвоздем прибить туда именно это умолчание и вернуться в состояние 95го года, когда модули грузили там и тогда, когда админ считал нужным, а не выпрыгивали как чортик из табакерки по непонятным внутриядерным соображениям.
Все нужное, и много лишнего, один хрен нынче модно всасывать из initrd.
а если у некоторых 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 +0100net, 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 тоже нету?
> так это как раз - хороший, правильный баг, какие раз в пять
> лет бывают (жаль только, их находят через еще десять) - яВы это серьёзно? Даже опубликованных подобных уязвимостей нередко случается больше пяти в год, в числе которых в последнее время всё чаще оказываются и более "правильные" логические (см. уязвимости, порождённые непривилегированными 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 такая, в своём роде уникальная работа действительно ведётся, но годами остаётся непонятой и непринятой сообществом.
Linux на IoT не нужен. Пусть лучше KasperskyOS используют.
BolgenOS для кого писали?
А сколько устройств не получают обновления ???
Это проблемы пользователей ??? Ну-ну
когда получают кучу доссеров это оказывается что проблема все-же не только пользователей.
Пользователю отключают интернет за вредоносную активность, и проблема становится его личной.
Если бы андроидные устройства (большинство из них) еще и получали обновления...
А ты бери те устройства, на которые можно установить правильное обновление сразу после покупки: http://plasma-phone.org/
Ты бы сам этим попользовался как основным смартфоном этак хотя бы месяц, а потом уж говорил...
> Если бы андроидные устройства (большинство из них) еще и получали обновления...Так продаж небудет :(
Жаль, что нет готового эксплоита, в публичном доступе, уже скомпиленного. Это вызвало бы волну взломом линукс-серверов (не все Арч пользуют и не все считают нужным обновляться), что привело бы к массовому обновлению линуксов и оттоку пользователей с него (не спецы сказали бы "да нафиг нужно" и вернулись бы обратно на винды, и денег нашлось бы на лицензии).
Кроме того, эту уязвимость нашли далеко не самые умные люди на планете, материально в этом не заинтересованные, по этому можно сделать вывод, что самые умные люди на планете, материально в этом (хакеры, в плане "лучшие специалисты") заинтересованные материально давно нашли эту уязвимость, но пользовались ей тайно, а получив рут-доступ, причем даже доступ на уровне ядра - они могли скрывать свое присутствие в системе, имея к ней полный доступ. Возможно что именно ваш сервер давно хакнут, если версия ядра в нем ниже, чем указано в этой статье, и у вас нет никаких способов доказать себе, что это было не так.
Ну что за чушь? Итак больше половины линуксовых серверов торчат с софтом, содержащим известные уязвимости.
И да, имеют их. На венду естественно никто не побежит, ибо инфраструктуры нет.
ЗЫ: ситуация же во многом похожа с вендой на десктопах.
Что за ерунду вы все тут порете?
ВСЕ НОРМАЛЬНЫЕ КОНТОРЫ всегда выстраивают инфраструктуру которая обеспечивает работу конторы. Если в конторе есть администратор, то сделает это он. Это единственный и самый лучший способ получить инфраструктуру с заданной надежностью и требуемыми характеристиками. Все ваши виндовзы, касперскийОС и прочее - это просто проприетарные игрушечки домохозяек. Пропритеарные рюшечки не годятся для строительства инфраструктур.
Ну да, в твоем идеальном мире существуют одни нормальные конторы с хорошим ит отделом или качественным аутсорсом на худой конец. И все физики-владельцы вдсок с прочей мелочью под личные хотелки тоже профешинал хакерз.
> Ну да, в твоем идеальном мире существуют одни нормальные конторы с хорошим
> ит отделом или качественным аутсорсом на худой конец.где, где портал в этот мир? В моем если они где-то и существуют, то очень хорошо спрятаны.
А в реальности существуют только гoвнo-конторы с неадекватными it'шниками или совсем уж бангалорским аутсорсом, у которых единственным смыслом существования является всех построить и заодно прикрыть свою жопу (именно в этом порядке, прикрытие жопы только обосновывает синдром вахтера), желательно вообще ничего не делая полезного для окружающих. А на практике имеем по джамп-хосту в каждом мелком подразделении "нормальной конторы", в каждом крупном - по четыре, из них о трех не знает ни одна еще работающая в компании живая душа.> И все физики-владельцы вдсок с прочей мелочью под личные хотелки тоже профешинал хакерз.
этим как раз проще - за них провайдер вдски думает, ну или хотя бы вовремя их отключает - ему же не нужны неприятности.
> Ну что за чушь? Итак больше половины линуксовых серверов торчат с софтом, содержащим
> известные уязвимости.так речь-то о том, что другие "меньше половины" все равно имеют не[широко]известные уязвимости с тем же самым результатом.
> На венду естественно никто не побежит, ибо инфраструктуры нет.
дело даже не в инфраструктуре, а в том что и с виндой ситуация ровно та же самая.
Причем в виду ее большей сложности и меньшей прозрачности, как ни старайся, общий набор векторов атаки всегда будет большим, чем у отдельно взятой линуксной системы (но тут линукс резко сокращает дистанцию, в виду последних улучшизмов).
> Причем в виду ее большей сложности и меньшей прозрачности, как ни старайся,
> общий набор векторов атаки всегда будет большим, чем у отдельно взятой
> линуксной системы (но тут линукс резко сокращает дистанцию, в виду последних улучшизмов).подробнее про улучшизмы можно ? о чём вообще речь ?
Еще, еще, бро! Еще немного - и пригласят в редмонд.
> не все Арч пользуют и не все считают нужным обновлятьсяArch Linux на втором месте по скорости исправления уязвимостей, по мнению шефа службы информационной безопасности Qiwi Кирилла Ермакова: https://www.slideshare.net/KirillErmakov/vulnerability-funal...
А redhat в среднем исправляет за 80 дней??
Опять не смог прочитать новость дальше первого абзаца?
> Жаль, что нет готового эксплоита, в публичном доступе, уже скомпиленного. Это вызвало бы волну взломом линукс-серверовсудя по данным шапки - есть. Бага в тихую поправлена в -327.16.
O-Subject: [PATCH RHEL7.3 net] udp: properly support MSG_PEEK with truncated buffers
Bugzilla: 1294384
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1294384
Upstream Status: net-next 197c949e7798fbf28cfadc69d9ca0c2abbf93191
Tested: local VM, with the test case provided by the customerобрати внимание на комментарии "test case provided by the customer"
> "test case provided by the customer"Тесткейс — это ещё не эксплойт.
хорошо. повторяй как мантру - "тест кейс это не эксплойт" - ведь поможет и защитит.
>> Жаль, что нет готового эксплоита, в публичном доступе
> судя по данным шапки - есть. Бага в тихую поправлена в -327.16.блин, это у шапки есть, а просили - в публичном доступе.
Я тоже хочу! Можно даже нескомпилированный.> Tested: local VM, with the test case provided by the customer
> обрати внимание на комментарии "test case provided by the customer"это не я.
К сожалению.(ну и да, тескейс это еще не эксплойт и даже не PoC - ну вывалит ведро трейс, и чего?)
>>> Жаль, что нет готового эксплоита, в публичном доступе
>> судя по данным шапки - есть. Бага в тихую поправлена в -327.16.
> блин, это у шапки есть, а просили - в публичном доступе.
> Я тоже хочу! Можно даже нескомпилированный.Тем кому нужен он есть :) и давно.
>> Tested: local VM, with the test case provided by the customer
>> обрати внимание на комментарии "test case provided by the customer"
> это не я.
> К сожалению.
> (ну и да, тескейс это еще не эксплойт и даже не PoC
> - ну вывалит ведро трейс, и чего?)Ты так уверен? :) то есть падение ядра это не local DoS ?.. и так каждый раз как поднимется..
Видимо доступность сервиса нынче не чести..
> Тем кому нужен он есть :) и давно.мне, мне нужен, у меня нет! (у меня ж масса друзей...)
>> (ну и да, тескейс это еще не эксплойт и даже не PoC - ну вывалит ведро трейс, и чего?)
> Ты так уверен? :) то есть падение ядра это не local DoSвываливание трейса и даже повисшая единичная юзерская поделка - это еще даже не падение ядра, увы.
>> Тем кому нужен он есть :) и давно.
> мне, мне нужен, у меня нет! (у меня ж масса друзей...)
>>> (ну и да, тескейс это еще не эксплойт и даже не PoC - ну вывалит ведро трейс, и чего?)
>> Ты так уверен? :) то есть падение ядра это не local DoS
> вываливание трейса и даже повисшая единичная юзерская поделка - это еще
> даже не падение ядра, увы.там таки падение - но ты повторяй мантру "все хорошо" "дыр в линуксе нету" "я в безопасности".
Примеры можешь почитать выше.
Кстати как всегда жутко утрируешь. Глянька лучше на IoT и ведрофоны. Там как правило обновления не приходят никогда. Вот оно раздолье для истерики. И иось под носом проприетарненькая по самые нехочу, где с этим своевременно, почти образцово.Ан нет, все потешные попытки выбелить ms шindoшs в споре кто из них дырявей с gnu/лuнупс на уме. Ведь не раз подборки CVE кидали, у ms шindoшs их все еще больше, и не на 1-2. При всем засилии клятого ядра сами знаете чего в IoT и телефонах.
И как об отработках не подумать, м?
> Ан нет, все потешные попытки выбелить ms шindoшs в споре кто из
> них дырявей с gnu/лuнупс на уме.про винду я ничего не сказал, я просто пальцем ткнул, а у фанатов опять бомбануло.
Фанаты, они даже в случае полного глобального и полного фиаско не признают, что линукс плохой - он как больной раком и синдоромом дауна сын-наркоман - самый любимый, самый умный, самый красивый и самый хороший.Выяснилось, внезапно, что долгие годы в linux была по суди удаленная-рут уязвимость, причем в этот раз не на приложение ориентированная, а именно на ядро, каковы масштабы последствий - никто не скажет. Но убеждения пользователей линукс в отношении превосходства своей ОС над ms Windos строятся именно на ВЕРЕ, а не на знаниях, это нефига не шутка и не метафора - это констатация факта, они прочитали в интернетах где-то инфу, что линукс безопаснее, ПОВЕРИЛИ в это и приняли эту точку зрения как свою.
Или они все строки исходного кода прочитали и изучуи, коим пользуются ?
> про винду я ничего не сказал, я просто пальцем ткнул, а у
> фанатов опять бомбануло.ентож опеннет, ты чо хотел-то?
> Выяснилось, внезапно, что долгие годы в linux была по суди удаленная-рут уязвимость,
> причем в этот раз не на приложение ориентированная, а именно нану, не совсем. Надо еще найти что-то, что слушает доступный извне сокет и потом непереваренное обратно в него же отрыгивает, и там внутри наступить еще и на проблему с переполнением.
Я, честно говоря, совершенно не в курсе, что у нас и зачем открывает сокеты с этим странным флагом. (спроси себя, для начала, что у тебя вообще udp слушает. У меня это dns, и он такого флага ставить не будет)
То есть эксплойт возможнен только локальный - сам написал такой код, сам его повесил на сокет, сам же к нему и пришел. Не то чтоб это было хорошо, особенно с учетом возраста бага (что-то района 2010го года) но не ужасно, тем более что не факт что получится выполнить код, а не просто задосить или уронить систему.
То что там в новости дальше про андроед - это вот ужасно. Но оно там так ВСЕГДА, ничего нового или удивительного в этом нет.
Ну взломают сервер. А тебе-то что с этого? В кармане прибавится? Или завышенное ЧСВ покоя не дает?
> Ну взломают сервер. А тебе-то что с этого? В кармане прибавится?эмм... если это банальный вебсервер конкурентов (э... lor,к примеру, vs opennet), ломаем через zero-rhel-day - то есть каждый день он лежит в течении заметного периода, админ ничего найти не может, потому что не знает где искать - очень даже прибавится, за счет ухода траффика.
А еще бывают сервера, где есть что взять - данные кредиток, или личную инфу пользователей, весьма часто ведущую к данным кредиток далеко от места где ее стырили, например.
А твой локалхост, действительно, нафиг никому не сдался, спи спокойно.
Основные новости про open source в последнее время это "обнаружена уязвимость"
Чистое вранье.
> Чистое вранье."Here we are in 2013 onwards [,,,]"
==>http://www.opennet.ru/openforum/vsluhforumID3/105391.html#15Не мешайте тело работает.
Глупости какие-то. Эмблемы и логотипы получили реально стоящие уязвимости, а их не так много.
К тому же если бы это было так, то от компании <CENSORED> были бы рекламки - пользуйтесь нашим Azure, он построен на всем "дырявом" линуксе?
Просто когда работает паранойя вместо логики, то обычно выходит не очень...
Азура? Господи, не смешите, это на уровне сервелата, скоро сдoхнет, если еще не. Технология "что бы было". То есть совсем не показатель. А во сути я соглашусь с Адреем, ибо лицемерие МС таково, что противно иметь с ними дело. Но люди жрут, и добавки просят. Один раз они довели гую до хорошего состояния, что же теперь, на них молиться, сколько лет? Тем более, гую ту они благополучно закoпали, здравствуй плитка.
3 из 5 новости в "Последние новости" opennet сейчас в топе - это "обнаружена уязвимость".
А я смог посмотреть на новости так что из 3 новостей нашел 3 про уязвимости. Видишь какая у тебя выборка не объективная.
> Основные новости про open source в последнее время это "обнаружена уязвимость"Всё больше глаз смотрят в код.
"Если долго всматриваться в бездну, то бездна начинает всматриваться в тебя" /Фридрих Ницше/.
> Основные новости про open source в последнее время это "обнаружена уязвимость"Так замечательно же. Не замалчивают, как некоторые.
Интересно, есть ли и будут ли обновления безопасности для Nexus 5? Или Гугл таки не заботится о своих пользователях в отличии от Яблока? Ведь уязвимости по сути критические.
Не будет - три года прошло.
Модель не потеряла своей актуальности. Я понимаю, если бы её аппаратные возможности устарели и не отвечали современным требованиям. Но ведь нет, ибо модель смартфона получилась очень удачной. Гугл ведь зарабатывает на сервисах, поэтому не очень понятно, почему такой короткий жизненный цикл у их устройств, причем даже не по мажорным обновлениям операционной системы, а по исправлению в ней уязвимостей.
А Что именно Nexus 5На руках у людей зачастую трубки, купленные два-три года (и более) назад.
в 90% случаев производители на эти модели давно забили.
> Интересно, есть ли и будут ли обновления безопасности для Nexus 5?http://plasma-phone.org/nexus-5/ только брать не старую, а свежею с новым ядром Linux
С таким же успехом можно выкинуть смартфон и купить звонилку. Под "это" есть приложения?
>Под "это" есть приложения?Вы не полняль. Оно шутит[, аж форсит,] что под это есть _обновления безопасности_.
> Интересно, есть ли и будут ли обновления безопасности для Nexus 5? Или Гугл таки не
> заботится о своих пользователях в отличии от Яблока?чихать гугл хотел на пользователей. В отличие от яблока, они с его сервиса уже не спрыгнут, пойдут и купят новую, улучшенную модель без бага, подумаешь.
> Ведь уязвимости по сути критические.
в ведре (которая обеспечила заголовок данной новости) - нет, помимо помощи снаружи надо еще иметь весьма странную программу внутри системы, причем не в обертке дальвика, оттуда вряд ли подобные вещи доступны. Я вообще хз что это.
В медиасервере и остальном- ну да, как обычно. Любой андроид без обновлений последние пару месяцев - [слово запрещенное тут к употреблению ;-) ]
Справедливости ради - гугль заботиться о _своих_ пользователях (это вовсе не покупатели гуглолопат) и если за пределы экосистемы не выходить, нарваться на проблемы маловероятно.
Подробности: http://samtizen.blogspot.com/2017/04/tizen-os.html
Amihai Neiderman не первый раз выступает на профильных конференциях и известен как минимум взломами DVB-T.А вот о серьёзности вашей публикации говорит намеренное искажение информации, выдёргивание из контекста и передёргивания в стиле РЕН-ТВ. Особенно мерзко обращение к исследователю через унизительные клички, типа "юное дарование", "софтверного гения", "король безопасности", "новоявленный гений", "гений цифрового сыска", "мальчишка с грязной попкой".
Чтобы лишний раз этот бред не читать, приведу лишь одну цитату, наглядно показывающую уровень той статьи:"Как повествует анкетка Амихая в LinkedIn, юное дарование училось в The Open University of Israel (Открытый университет Израиля). Что из себя представляют так называемые "открытые университеты", нам хорошо известно по "лихим 90-м", когда подобные заведения открывались в России как грибы после дождя. Если коротко, это то самое место, где можно было легко "получить корочку" любому троечнику, причём совершенно официально, но за приличные деньги. В таком "американском открытом университете", что расположился на Старом Арбате в Москве, "учились" (а если точнее, то лишь изредка посещали) отпрыски многих "заслуженных людей страны", на которых природа решила хорошенько отдохнуть. И вряд ли стоит сомневаться, что Открытый университет Израиля чем-то кардинально отличается от вышеописанного."
>[оверквотинг удален]
> "Как повествует анкетка Амихая в LinkedIn, юное дарование училось в The Open
> University of Israel (Открытый университет Израиля). Что из себя представляют так
> называемые "открытые университеты", нам хорошо известно по "лихим 90-м", когда подобные
> заведения открывались в России как грибы после дождя. Если коротко, это
> то самое место, где можно было легко "получить корочку" любому троечнику,
> причём совершенно официально, но за приличные деньги. В таком "американском открытом
> университете", что расположился на Старом Арбате в Москве, "учились" (а если
> точнее, то лишь изредка посещали) отпрыски многих "заслуженных людей страны", на
> которых природа решила хорошенько отдохнуть. И вряд ли стоит сомневаться, что
> Открытый университет Израиля чем-то кардинально отличается от вышеописанного."Спросите у знакомых евреев из IT-сферы что это за университет, и вам откроется.
p.s. Называть с канадачка ОС "худшей из всех" (это он в свои 27 лет коды всех ОС проштудировал "от корки до корки") - вот где верх наглости и цинизма.