Исходное сообщение
"Уязвимость в сетевом стеке ядра Linux" Отправлено zanswer CCNA RS and S, 14-Май-19 05:03
Я не буду самостоятельно делать глубоких выводов о данной спорной ситуации, поскольку мне не известна мотивация сотрудника Cisco Talos research group, но конкретно показанный вами твит, был лишь саркастической иллюстрацией со стороны разработчика grsecurity: А вот твит который описывает реальный факт конфликта интересов: «So is Cisco Talos like Google's Project Zero, but instead of having talented researchers and writeups about real vulns, they have fake vulns found by people who don't know how to run fuzzers or what security boundaries are, with the sole purpose being bug metrics and page clicks?» «Was notified of a "security vulnerability impacting GRsecurity customers" with a CVSS score of 5.3 no less (cc @daveaitel) that turned out to be a memory leak only in our 4.9 test patch on reading /dev/kmem,something that requires CAP_SYS_RAWIO (as privileged as it gets in Linux)» «as well as having CONFIG_DEVKMEM enabled (which no distro I'm aware of has done for about a decade), and having GRKERNSEC_KMEM disabled (with it being enabled by default).  I asked if they were going to issue an advisory for the fact that someone with read access to /dev/kmem...» «generally has write access as well, and obviously can crash the kernel (or do whatever else) by simply writing to it» https://twitter.com/grsecurity/status/1100516458776485894?s=21 Как видно из твитов разработчика grsecurity memory leak имел место быть, хоть и в тестовом патче. Тем не менее требовал особой настройки со стороны ядра. Я постараюсь найти комментарии с обратной стороны, может быть тогда будет понятно, кто прав, а кто виноват.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> Я не буду самостоятельно делать глубоких выводов о данной спорной ситуации, поскольку > мне не известна мотивация сотрудника Cisco Talos research group, но конкретно > показанный вами твит, был лишь саркастической иллюстрацией со стороны разработчика grsecurity: > А вот твит который описывает реальный факт конфликта интересов: > «So is Cisco Talos like Google's Project Zero, but instead of having > talented researchers and writeups about real vulns, they have fake vulns > found by people who don't know how to run fuzzers or > what security boundaries are, with the sole purpose being bug metrics > and page clicks?» > «Was notified of a "security vulnerability impacting GRsecurity customers" with a > CVSS score of 5.3 no less (cc @daveaitel) that turned out > to be a memory leak only in our 4.9 test patch > on reading /dev/kmem,something that requires CAP_SYS_RAWIO (as privileged as it gets > in Linux)» > «as well as having CONFIG_DEVKMEM enabled (which no distro I'm aware of > has done for about a decade), and having GRKERNSEC_KMEM disabled (with > it being enabled by default). I asked if they were > going to issue an advisory for the fact that someone with > read access to /dev/kmem...» > «generally has write access as well, and obviously can crash the kernel > (or do whatever else) by simply writing to it» > https://twitter.com/grsecurity/status/1100516458776485894?s=21 > Как видно из твитов разработчика grsecurity memory leak имел место быть, хоть > и в тестовом патче. Тем не менее требовал особой настройки со > стороны ядра. Я постараюсь найти комментарии с обратной стороны, может быть > тогда будет понятно, кто прав, а кто виноват.
	Введите код, изображенный на картинке: