The OpenNET Project / Index page

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



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

"В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от opennews (??) on 04-Апр-17, 23:16 
В апрельском обновлении платформы 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

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

Оглавление

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


1. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +7 +/
Сообщение от Аноним (??) on 04-Апр-17, 23:16 
По мере проникновения IoT и прочих устройств на Linux его активней начинают ковырять палочкой расковыривая уязвимости.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

33. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  –2 +/
Сообщение от Аноним (??) on 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  

Но можно дальше жить считая что в мире линукса все хорошо.. все хорошо..

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

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

всё не хорошо, но всё куда лучше чем во всех других альтернативах
именно этим хорош опенсорс и линукс в частности
а когда до мантейнеров дистрибов дойдёт что пора втягивать юзерэкспиренс из винды по защите юзера от программ и программ юзера от других программ, юзерфрендли фаерволы, юзерфрендли настройки ограничений для программ и тд и тп - вообще счастье наступит

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

52. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  –3 +/
Сообщение от пох on 05-Апр-17, 13:47 
> всё не хорошо, но всё куда лучше чем во всех других альтернативах

"чем лучше - чем в других".
Ничем не лучше, с тех пор как в головах разработчиков и advocacy засела идиотская мысль "как windows, только нахаляву".

> а когда до мантейнеров дистрибов дойдёт что пора втягивать юзерэкспиренс из винды по
> защите юзера от программ и программ юзера от других программ,

то только тyпой юзер и захочет с этим работать.
Умный поймет, что еще одна винда "только нахаляву" (что выливается в поддержку на от..сь) ему совершенно и не нужна.

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

47. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от пох on 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 устранена уязвимость, эксплуа..."  +/
Сообщение от пох on 05-Апр-17, 13:04 
> И, если я правильно понимаю, до сих пор в 6
> не исправлено, и даже не понятно, уязвимость-то есть ли?

потыкав палочкой - если она вообще есть, то и в 6 есть :-( как это работает и почему invalid checksum может проявляться в случае когда чексамминг НЕ выполняется - за недостатком времени и вдохновения разбираться не стал.

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

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

а, вот оно что - оно просто второй раз ее считало, когда как раз валидна, при этом что-то ломая (видимо, уже не проверяя в этом случае, что есть куда писать).


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

64. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от Аноним (??) on 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 устранена уязвимость, эксплуа..."  +/
Сообщение от пох on 05-Апр-17, 21:23 
> или просто не знаешь как это использовать.

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

> То есть бэкпорт security fix апсптрима - перестает таковым быть?

то есть не надо стонать по поводу "молча и без анонсов". Хотите анонсов - следите за патчами в наираспоследней версии vanilla kernel

Если случается линухокапец, как вот с udp.c - анонс случается тоже. (вот то что в rhel 6.чтоунастам-9? до сих пор не поправлено - это, кстати, занятно. Зато они вчерась прислали мне письмо электрическое, что героически победили CVE-2016-8399 - это вот как раз из серии "и еще, конечно же, желательно быть рутом на экслойтируемой системе")

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

70. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от Аноним (??) on 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 - что смешно.

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

80. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от пох on 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 не ложится, не качать же его только чтоб посмотреть.

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

85. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от Аноним (??) on 06-Апр-17, 07:33 
> ну и какое милые, у вас, тыщелетье на дворе-то? Речь шла о том, что из "прямо вчера поправленно аж 10 секурных багов, ужас-ужас" реально вылезти, и то не в самом распространенном сценарии, могут аж два. И то не факт что exploitable

прямо вчера. Это из все тех же патчей RHEL7.2->RHEL7.3. Открой глаза :-)

> а чего опять же орать, когда опять "прищемил в году минувшем"? Коммит-то аж 2015го года, 2016-м баг помечен когда какой-то коммерческий клиент не поленился прислать редхатоидам код.

то есть как минимум год, а тут получается и все 2, коммерческий супер пупер защищенный линукс, за который платят деньги не малые - был дырявым.


> ну прочавкал индус, что есть еще и второе дерево, бывает - тикет небось счастливый юзверь семерки открывал.

Хорошо отмазываешся. Для этого есть специальные люди которые за этим сделать должны. Но вы не стесняйтесь - жрите что дают. Патч кстати ложился на ура.

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

72. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от vi (ok) on 05-Апр-17, 23:31 

> вот и к двум сотенкам подобрались.. фигня вопрос :-)

А теперь и в относительных величинах покажите пожалуйста! Анонутик Вы наш ;)

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

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

65. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +2 +/
Сообщение от добрый on 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 +/
Сообщение от Гость (??) on 05-Апр-17, 20:36 
Наделла решил посетить форум и дать советы окружающим. Давно ли шпионаж в "винде" априори стал законным?
Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

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

что бы быть откровенными - в grsecurity тоже хватает ляпов и вполне не однозначных решений. Но в целом забавный патч который пилят с оглядкой на то от чего же мы защищаемся.

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

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

Примеры ляпов и неоднозначных решений можете привести? :)

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

76. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от Аноним (??) on 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 может добраться сюда..

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

83. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от добрый on 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 нужен был?

> вообщем оно хорошо, но надо быть честным - есть ляпы и там.

Наверное, всё-таки действительно надо быть честным и признать, что если смысл чего-либо неясен на первый взгляд, это ещё не значит, что его нет? :)

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

86. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от Аноним (??) on 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_. Возможно было проще контролировать переполнения так, возможно какие-то еще идеи. Но ...


>> вообщем оно хорошо, но надо быть честным - есть ляпы и там.
> Наверное, всё-таки действительно надо быть честным и признать, что если смысл чего-либо
> неясен на первый взгляд, это ещё не значит, что его нет?
> :)

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

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

87. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от добрый on 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 используется в качестве счётчиков ссылок и должен быть защищён от переполнений. На производительность это не виляет практически никак.

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

Вам, конечно же, виднее, как проще и лучше добиваться того, что на высочайшем профессиональном уровне в течение многих лет делают другие. ;)

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

89. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от Аноним (??) on 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. а ляпы которые показывали в твитере - вообще смешные были. Я их сознательно сюда не копировал.

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

91. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от добрый on 06-Апр-17, 17:15 
Всё с вами ясно.

Если кому-нибудь ещё интересна данная тема, пишите свои вопросы, на них постараюсь ответить.

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

92. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  –1 +/
Сообщение от Аноним (??) on 06-Апр-17, 22:21 
увы. Не оценили.

Как и сама позиция закрывать патчи на GPL продукт. Оно вроде бы и не нарушение GPL, но вот душком отдает.

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

93. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от добрый on 07-Апр-17, 01:57 
> Как и сама позиция закрывать патчи на GPL продукт. Оно вроде бы
> и не нарушение GPL, но вот душком отдает.

Ах, вот оно что! :)

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

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

78. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от Аноним (??) on 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 устранена уязвимость, эксплуа..."  +/
Сообщение от пох on 06-Апр-17, 00:03 
>> следует понимать, что эти "cотни" на самом деле еще обычно очень непросто использовать
> Хороший пример, из последних (обратите внимание на простоту отключения SMEP):
>

так это как раз - хороший, правильный баг, какие раз в пять лет бывают (жаль только, их находят через еще десять) - я n_hdlc вынес со всех своих систем сразу же как увидел, не дожидаясь эксплойта. А как поэксплойтить be2iscsi, если его у тебя просто нет?

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

> Почему так происходит? Не выработана и не принята модель угроз, в её
> рамках не ведётся системная работа.

системная ведется - это как раз и называется grsec (хотя они там и странные черезмерно). В мэйнстриме никакая системная невозможна, тебя завернут "патч слишком большой, разбейте его на двестиписят фрагментов и обоснуйте каждый", при попытке это все же сделать, одновременно вприпрыжку догоняя ляпателей новых глюков - 50 завернут или отложат в долгий ящик, сделав остальные двести бесполезными.

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

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

а если он есть?.. вот бывает же и так что админишь не localhost..

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

90. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от пох on 06-Апр-17, 13:36 
> а если он есть?.. вот бывает же и так что админишь не localhost..

ну я вот админил нелокалхост, а "Emulex 10Gbps iSCSI - BladeEngine 2" почему-то у меня не было никогда (и постараюсь чтоб не было дальше, не люблю я nas'ы вообще и iscsi отдельно, по многим причинам). Спонтанно такие драйвера не загружаются.
И если бы даже я относился к тем полутора инвалидам, у которых он есть - еще не факт что в моей конфигурации в моей сети это было бы опасно.

P.S. а еще есть такая отличная штука echo /bin/false > /proc/sys/kernel/modprobe - на ядрах, любимых редхатом, отлично предотвращает загрузку ненужно.
Я уже всерьез задумался гвоздем прибить туда именно это умолчание и вернуться в состояние 95го года, когда модули грузили там и тогда, когда админ считал нужным, а не выпрыгивали как чортик из табакерки по непонятным внутриядерным соображениям.
Все нужное, и много лишнего, один хрен нынче модно всасывать из initrd.

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

94. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от Аноним (??) on 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 тоже нету?

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

84. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от добрый on 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ообщить модератору

13. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  –1 +/
Сообщение от Tita_M (ok) on 05-Апр-17, 07:28 
Linux на IoT не нужен. Пусть лучше KasperskyOS используют.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

19. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +2 +/
Сообщение от A.Stahl (ok) on 05-Апр-17, 08:27 
BolgenOS для кого писали?
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

57. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от vitektm on 05-Апр-17, 14:54 
А сколько устройств не получают обновления ???
Это проблемы пользователей ??? Ну-ну
когда получают кучу доссеров это оказывается что проблема все-же не только пользователей.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

81. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от L29Ah (ok) on 06-Апр-17, 04:18 
Пользователю отключают интернет за вредоносную активность, и проблема становится его личной.
Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

4. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +13 +/
Сообщение от Аноним (??) on 05-Апр-17, 00:29 
Если бы андроидные устройства (большинство из них) еще и получали обновления...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

22. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  –2 +/
Сообщение от Аноним (??) on 05-Апр-17, 09:04 
А ты бери те устройства, на которые можно установить правильное обновление сразу после покупки: http://plasma-phone.org/
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

28. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +1 +/
Сообщение от iPony on 05-Апр-17, 09:38 
Ты бы сам этим попользовался как основным смартфоном этак хотя бы месяц, а потом уж говорил...
Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

75. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от vi (ok) on 05-Апр-17, 23:47 
> Если бы андроидные устройства (большинство из них) еще и получали обновления...

Так продаж небудет :(

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

11. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  –3 +/
Сообщение от Адекват (ok) on 05-Апр-17, 06:52 
Жаль, что нет готового эксплоита, в публичном доступе, уже скомпиленного. Это вызвало бы волну взломом линукс-серверов (не все Арч пользуют и не все считают нужным обновляться), что привело бы к массовому обновлению линуксов и оттоку пользователей с него (не спецы сказали бы "да нафиг нужно" и вернулись бы обратно на винды, и денег нашлось бы на лицензии).
Кроме того, эту уязвимость нашли далеко не самые умные люди на планете, материально в этом не заинтересованные, по этому можно сделать вывод, что самые умные люди на планете, материально  в этом (хакеры, в плане "лучшие специалисты") заинтересованные материально давно нашли эту уязвимость, но пользовались ей тайно, а получив рут-доступ, причем даже доступ на уровне ядра - они могли скрывать свое присутствие в системе, имея к ней полный доступ. Возможно что именно ваш сервер давно хакнут, если версия ядра в нем ниже, чем указано в этой статье, и у вас нет никаких способов доказать себе, что это было не так.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

12. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +2 +/
Сообщение от iPony on 05-Апр-17, 06:58 
Ну что за чушь? Итак больше половины линуксовых серверов торчат с софтом, содержащим известные уязвимости.
И да, имеют их. На венду естественно никто не побежит, ибо инфраструктуры нет.
ЗЫ: ситуация же во многом похожа с вендой на десктопах.
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

16. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +1 +/
Сообщение от Аноним (??) on 05-Апр-17, 08:11 
Что за ерунду вы все тут порете?
ВСЕ НОРМАЛЬНЫЕ КОНТОРЫ всегда выстраивают инфраструктуру которая обеспечивает работу конторы. Если в конторе есть администратор, то сделает это он. Это единственный и самый лучший способ получить инфраструктуру с заданной надежностью и требуемыми характеристиками. Все ваши виндовзы, касперскийОС и прочее - это просто проприетарные игрушечки домохозяек. Пропритеарные рюшечки не годятся для строительства инфраструктур.
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

38. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от Аноним (??) on 05-Апр-17, 11:16 
Ну да, в твоем идеальном мире существуют одни нормальные конторы с хорошим ит отделом или качественным аутсорсом на худой конец. И все физики-владельцы вдсок с прочей мелочью под личные хотелки тоже профешинал хакерз.
Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

44. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от пох on 05-Апр-17, 12:46 
> Ну да, в твоем идеальном мире существуют одни нормальные конторы с хорошим
> ит отделом или качественным аутсорсом на худой конец.

где, где портал в этот мир? В моем если они где-то и существуют, то очень хорошо спрятаны.
А в реальности существуют только гoвнo-конторы с неадекватными it'шниками или совсем уж бангалорским аутсорсом, у которых единственным смыслом существования является всех построить и заодно прикрыть свою жопу (именно в этом порядке, прикрытие жопы только обосновывает синдром вахтера), желательно вообще ничего не делая полезного для окружающих. А на практике имеем по джамп-хосту в каждом мелком подразделении "нормальной конторы", в каждом крупном - по четыре, из них о трех не знает ни одна еще работающая в компании живая душа.

> И все физики-владельцы вдсок с прочей мелочью под личные хотелки тоже профешинал хакерз.

этим как раз проще - за них провайдер вдски думает, ну или хотя бы вовремя их отключает - ему же не нужны неприятности.


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

43. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +1 +/
Сообщение от пох on 05-Апр-17, 12:41 
> Ну что за чушь? Итак больше половины линуксовых серверов торчат с софтом, содержащим
> известные уязвимости.

так речь-то о том, что другие "меньше половины" все равно имеют не[широко]известные уязвимости с тем же самым результатом.

> На венду естественно никто не побежит, ибо инфраструктуры нет.

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

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

46. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от J.L. on 05-Апр-17, 12:52 
> Причем в виду ее большей сложности и меньшей прозрачности, как ни старайся,
> общий набор векторов атаки всегда будет большим, чем у отдельно взятой
> линуксной системы (но тут линукс резко сокращает дистанцию, в виду последних улучшизмов).

подробнее про улучшизмы можно ? о чём вообще речь ?

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

25. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +1 +/
Сообщение от Аноним (??) on 05-Апр-17, 09:30 
Еще, еще, бро! Еще немного - и пригласят в редмонд.
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

26. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  –1 +/
Сообщение от iZEN email(ok) on 05-Апр-17, 09:32 
> не все Арч пользуют и не все считают нужным обновляться

Arch Linux на втором месте по скорости исправления уязвимостей, по мнению шефа службы информационной безопасности Qiwi Кирилла Ермакова: https://www.slideshare.net/KirillErmakov/vulnerability-funal...

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

34. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от kerneliq (ok) on 05-Апр-17, 10:23 
А redhat в среднем исправляет за 80 дней??
Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

30. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от angra (ok) on 05-Апр-17, 09:49 
Опять не смог прочитать новость дальше первого абзаца?
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

31. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от Аноним (??) on 05-Апр-17, 10:07 
> Жаль, что нет готового эксплоита, в публичном доступе, уже скомпиленного. Это вызвало бы волну взломом линукс-серверов

судя по данным шапки - есть. Бага в тихую поправлена в -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"

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

48. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от анонимус вульгарис on 05-Апр-17, 12:59 
> "test case provided by the customer"

Тесткейс — это ещё не эксплойт.

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

61. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от Аноним (??) on 05-Апр-17, 17:17 
хорошо. повторяй как мантру - "тест кейс это не эксплойт" - ведь поможет и защитит.
Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

60. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от пох on 05-Апр-17, 15:22 
>> Жаль, что нет готового эксплоита, в публичном доступе
> судя по данным шапки - есть. Бага в тихую поправлена в -327.16.

блин, это у шапки есть, а просили - в публичном доступе.
Я тоже хочу! Можно даже нескомпилированный.

> Tested: local VM, with the test case provided by the customer
> обрати внимание на комментарии "test case provided by the customer"

это не я.
К сожалению.

(ну и да, тескейс это еще не эксплойт и даже не PoC - ну вывалит ведро трейс, и чего?)

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

62. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от Аноним (??) on 05-Апр-17, 17:18 
>>> Жаль, что нет готового эксплоита, в публичном доступе
>> судя по данным шапки - есть. Бага в тихую поправлена в -327.16.
> блин, это у шапки есть, а просили - в публичном доступе.
> Я тоже хочу! Можно даже нескомпилированный.

Тем кому нужен он есть :) и давно.

>> Tested: local VM, with the test case provided by the customer
>> обрати внимание на комментарии "test case provided by the customer"
> это не я.
> К сожалению.
> (ну и да, тескейс это еще не эксплойт и даже не PoC
> - ну вывалит ведро трейс, и чего?)

Ты так уверен? :) то есть падение ядра это не local DoS ?.. и так каждый раз как поднимется..
Видимо доступность сервиса нынче не чести..

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

63. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от пох on 05-Апр-17, 17:25 
> Тем кому нужен он есть :) и давно.

мне, мне нужен, у меня нет! (у меня ж масса друзей...)

>> (ну и да, тескейс это еще не эксплойт и даже не PoC - ну вывалит ведро трейс, и чего?)
> Ты так уверен? :) то есть падение ядра это не local DoS

вываливание трейса и даже повисшая единичная юзерская поделка  - это еще даже не падение ядра, увы.

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

71. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  –1 +/
Сообщение от Аноним (??) on 05-Апр-17, 23:22 
>> Тем кому нужен он есть :) и давно.
> мне, мне нужен, у меня нет! (у меня ж масса друзей...)
>>> (ну и да, тескейс это еще не эксплойт и даже не PoC - ну вывалит ведро трейс, и чего?)
>> Ты так уверен? :) то есть падение ядра это не local DoS
> вываливание трейса и даже повисшая единичная юзерская поделка  - это еще
> даже не падение ядра, увы.

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

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

39. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от Аноним (??) on 05-Апр-17, 11:31 
Кстати как всегда жутко утрируешь. Глянька лучше на IoT и ведрофоны. Там как правило обновления не приходят никогда. Вот оно раздолье для истерики. И иось под носом проприетарненькая по самые нехочу, где с этим своевременно, почти образцово.

Ан нет, все потешные попытки выбелить ms шindoшs в споре кто из них дырявей с gnu/лuнупс на уме. Ведь не раз подборки CVE кидали, у ms шindoшs их все еще больше, и не на 1-2. При всем засилии клятого ядра сами знаете чего в IoT и телефонах.

И как об отработках не подумать, м?

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

53. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +1 +/
Сообщение от Адекват (ok) on 05-Апр-17, 13:55 
> Ан нет, все потешные попытки выбелить ms шindoшs в споре кто из
> них дырявей с gnu/лuнупс на уме.

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

Выяснилось, внезапно, что долгие годы в linux была по суди удаленная-рут уязвимость, причем в этот раз не на приложение ориентированная, а именно на ядро, каковы масштабы последствий - никто не скажет. Но убеждения пользователей линукс в отношении превосходства своей ОС над ms Windos строятся именно на ВЕРЕ, а не на знаниях, это нефига не шутка и не метафора - это констатация факта, они прочитали в интернетах где-то инфу, что линукс безопаснее, ПОВЕРИЛИ  в это и приняли эту точку зрения как свою.
Или они все строки исходного кода прочитали и изучуи, коим пользуются ?

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

59. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от пох on 05-Апр-17, 15:04 
> про винду я ничего не сказал, я просто пальцем ткнул, а у
> фанатов опять бомбануло.

ентож опеннет, ты чо хотел-то?

> Выяснилось, внезапно, что долгие годы в linux была по суди удаленная-рут уязвимость,
> причем в этот раз не на приложение ориентированная, а именно на

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

Я, честно говоря, совершенно не в курсе, что у нас и зачем открывает сокеты с этим странным флагом. (спроси себя, для начала, что у тебя вообще udp слушает. У меня это dns, и он такого флага ставить не будет)

То есть эксплойт возможнен только локальный - сам написал такой код, сам его повесил на сокет, сам же к нему и пришел. Не то чтоб это было хорошо, особенно с учетом возраста бага (что-то района 2010го года) но не ужасно, тем более что не факт что получится выполнить код, а не просто задосить или уронить систему.

То что там в новости дальше про андроед - это вот ужасно. Но оно там так ВСЕГДА, ничего нового или удивительного в этом нет.

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

68. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  –1 +/
Сообщение от Гость (??) on 05-Апр-17, 20:39 
Ну взломают сервер. А тебе-то что с этого? В кармане прибавится? Или завышенное ЧСВ покоя не дает?
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

96. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +1 +/
Сообщение от Аноним (??) on 08-Апр-17, 03:24 
> Ну взломают сервер. А тебе-то что с этого? В кармане прибавится?

эмм... если это банальный вебсервер конкурентов (э... lor,к примеру, vs opennet), ломаем через zero-rhel-day - то есть каждый день он лежит в течении заметного периода, админ ничего найти не может, потому что не знает где искать  - очень даже прибавится, за счет ухода траффика.

А еще бывают сервера, где есть что взять - данные кредиток, или личную инфу пользователей, весьма часто ведущую к данным кредиток далеко от места где ее стырили, например.

А твой локалхост, действительно, нафиг никому не сдался, спи спокойно.

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

14. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от Джо on 05-Апр-17, 07:50 
Основные новости про open source в последнее время это "обнаружена уязвимость"
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

17. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +3 +/
Сообщение от Аноним (??) on 05-Апр-17, 08:15 
Чистое вранье.
Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

29. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  –1 +/
Сообщение от Andrey Mitrofanov on 05-Апр-17, 09:46 
> Чистое вранье.

"Here we are in 2013 onwards [,,,]"
==>http://www.opennet.ru/openforum/vsluhforumID3/105391.html#15

Не мешайте тело работает.

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

42. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от iPony on 05-Апр-17, 12:04 
Глупости какие-то. Эмблемы и логотипы получили реально стоящие уязвимости, а их не так много.
К тому же если бы это было так, то от компании <CENSORED> были бы рекламки - пользуйтесь нашим Azure, он построен на всем "дырявом" линуксе?
Просто когда работает паранойя вместо логики, то обычно выходит не очень...
Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

66. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  –2 +/
Сообщение от Аноним (??) on 05-Апр-17, 20:11 
Азура? Господи, не смешите, это на уровне сервелата, скоро сдoхнет, если еще не. Технология "что бы было". То есть совсем не показатель. А во сути я соглашусь с Адреем, ибо лицемерие МС таково, что противно иметь с ними дело. Но люди жрут, и добавки просят. Один раз они довели гую до хорошего состояния, что же теперь, на них молиться, сколько лет? Тем более, гую ту они благополучно закoпали, здравствуй плитка.
Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

36. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  –1 +/
Сообщение от Джо on 05-Апр-17, 10:24 
3 из 5 новости в "Последние новости" opennet сейчас в топе - это "обнаружена уязвимость".
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

56. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от Аноним (??) on 05-Апр-17, 14:29 
А я смог посмотреть на новости так что из 3 новостей нашел 3 про уязвимости. Видишь какая у тебя выборка не объективная.
Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

27. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от iZEN email(ok) on 05-Апр-17, 09:33 
> Основные новости про open source в последнее время это "обнаружена уязвимость"

Всё больше глаз смотрят в код.

"Если долго всматриваться в бездну, то бездна начинает всматриваться в тебя" /Фридрих Ницше/.


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

49. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от анонимус вульгарис on 05-Апр-17, 13:01 
> Основные новости про open source в последнее время это "обнаружена уязвимость"

Так замечательно же. Не замалчивают, как некоторые.

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

15. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от Аноним (??) on 05-Апр-17, 08:01 
Интересно, есть ли и будут ли обновления безопасности для Nexus 5? Или Гугл таки не заботится о своих пользователях в отличии от Яблока? Ведь уязвимости по сути критические.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

18. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от iPony on 05-Апр-17, 08:15 
Не будет - три года прошло.
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

24. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от Аноним (??) on 05-Апр-17, 09:09 
Модель не потеряла своей актуальности. Я понимаю, если бы её аппаратные возможности устарели и не отвечали современным требованиям. Но ведь нет, ибо модель смартфона получилась очень удачной. Гугл ведь зарабатывает на сервисах, поэтому не очень понятно, почему такой короткий жизненный цикл у их устройств, причем даже не по мажорным обновлениям операционной системы, а по исправлению в ней уязвимостей.
Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

20. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от mmm (??) on 05-Апр-17, 08:45 
А Что именно Nexus 5

На руках у людей зачастую трубки, купленные два-три года (и более) назад.

в 90% случаев производители на эти модели давно забили.

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

23. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  –1 +/
Сообщение от Аноним (??) on 05-Апр-17, 09:08 
> Интересно, есть ли и будут ли обновления безопасности для Nexus 5?

http://plasma-phone.org/nexus-5/ только брать не старую, а свежею с новым ядром Linux

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

35. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от Аноним (??) on 05-Апр-17, 10:23 
С таким же успехом можно выкинуть смартфон и купить звонилку. Под "это" есть приложения?
Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

37. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от Andrey Mitrofanov on 05-Апр-17, 10:26 
>Под "это" есть приложения?

Вы не полняль. Оно шутит[, аж форсит,] что под это есть _обновления безопасности_.

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

58. "В Android и старых ядрах Linux устранена уязвимость, эксплуа..."  +/
Сообщение от пох on 05-Апр-17, 14:56 
> Интересно, есть ли и будут ли обновления безопасности для Nexus 5? Или Гугл таки не
> заботится о своих пользователях в отличии от Яблока?

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

> Ведь уязвимости по сути критические.

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

В медиасервере и остальном-  ну да, как обычно. Любой андроид без обновлений последние пару месяцев - [слово запрещенное тут к употреблению ;-) ]

Справедливости ради - гугль заботиться о _своих_ пользователях (это вовсе не покупатели гуглолопат) и если за пределы экосистемы не выходить, нарваться на проблемы маловероятно.

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

97. "критики Tizen - шайка проходимцев  "  +/
Сообщение от Yuri email(??) on 09-Апр-17, 00:11 
Подробности: http://samtizen.blogspot.com/2017/04/tizen-os.html
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

98. "критики Tizen - шайка проходимцев  "  +/
Сообщение от Аноним (??) on 09-Апр-17, 01:14 
Amihai Neiderman не первый раз выступает на профильных конференциях и известен как минимум взломами DVB-T.

А вот о серьёзности вашей публикации говорит намеренное искажение информации, выдёргивание из контекста и передёргивания в стиле РЕН-ТВ. Особенно мерзко обращение к исследователю через унизительные клички, типа  "юное дарование", "софтверного гения",  "король безопасности", "новоявленный гений",  "гений цифрового сыска", "мальчишка с грязной попкой".


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

"Как повествует анкетка Амихая в LinkedIn, юное дарование училось в The Open University of Israel (Открытый университет Израиля). Что из себя представляют так называемые "открытые университеты", нам хорошо известно по "лихим 90-м", когда подобные заведения открывались в России как грибы после дождя. Если коротко, это то самое место, где можно было легко "получить корочку" любому троечнику, причём совершенно официально, но за приличные деньги. В таком "американском открытом университете", что расположился на Старом Арбате в Москве, "учились" (а если точнее, то лишь изредка посещали) отпрыски многих "заслуженных людей страны", на которых природа решила хорошенько отдохнуть. И вряд ли стоит сомневаться, что Открытый университет Израиля чем-то кардинально отличается от вышеописанного."

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

99. "критики Tizen - шайка проходимцев  "  +/
Сообщение от Yuri email(??) on 09-Апр-17, 01:47 
>[оверквотинг удален]
> "Как повествует анкетка Амихая в LinkedIn, юное дарование училось в The Open
> University of Israel (Открытый университет Израиля). Что из себя представляют так
> называемые "открытые университеты", нам хорошо известно по "лихим 90-м", когда подобные
> заведения открывались в России как грибы после дождя. Если коротко, это
> то самое место, где можно было легко "получить корочку" любому троечнику,
> причём совершенно официально, но за приличные деньги. В таком "американском открытом
> университете", что расположился на Старом Арбате в Москве, "учились" (а если
> точнее, то лишь изредка посещали) отпрыски многих "заслуженных людей страны", на
> которых природа решила хорошенько отдохнуть. И вряд ли стоит сомневаться, что
> Открытый университет Израиля чем-то кардинально отличается от вышеописанного."

Спросите у знакомых евреев из IT-сферы что это за университет, и вам откроется.

p.s. Называть с канадачка ОС "худшей из всех" (это он в свои 27 лет коды всех ОС проштудировал "от корки до корки") - вот где верх наглости и цинизма.


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

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

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




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

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