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

"В 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.me/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.me/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 (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.me/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 (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 (??) 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 (??) on 09-Апр-17, 01:47
	>[оверквотинг удален] > "Как повествует анкетка Амихая в LinkedIn, юное дарование училось в The Open > University of Israel (Открытый университет Израиля). Что из себя представляют так > называемые "открытые университеты", нам хорошо известно по "лихим 90-м", когда подобные > заведения открывались в России как грибы после дождя. Если коротко, это > то самое место, где можно было легко "получить корочку" любому троечнику, > причём совершенно официально, но за приличные деньги. В таком "американском открытом > университете", что расположился на Старом Арбате в Москве, "учились" (а если > точнее, то лишь изредка посещали) отпрыски многих "заслуженных людей страны", на > которых природа решила хорошенько отдохнуть. И вряд ли стоит сомневаться, что > Открытый университет Израиля чем-то кардинально отличается от вышеописанного." Спросите у знакомых евреев из IT-сферы что это за университет, и вам откроется. p.s. Называть с канадачка ОС "худшей из всех" (это он в свои 27 лет коды всех ОС проштудировал "от корки до корки") - вот где верх наглости и цинизма.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

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

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