- Уязвимость в TCP-подсистеме ядра Linux, Vitaliy Blats, 20:52 , 13-Май-19 (1) +2
- Уязвимость в сетевом стеке ядра Linux, Аноним, 20:54 , 13-Май-19 (2) –4 [V]
- Уязвимость в сетевом стеке ядра Linux, Аноним, 20:56 , 13-Май-19 (3) +2
- Уязвимость в сетевом стеке ядра Linux, Аноним, 21:14 , 13-Май-19 (6) –5 [V]
- Уязвимость в сетевом стеке ядра Linux, Sluggard, 22:51 , 13-Май-19 (14)
- Уязвимость в сетевом стеке ядра Linux, Добрыйсурамаритянин, 23:54 , 13-Май-19 (15) +1
- Уязвимость в сетевом стеке ядра Linux, Аноним, 10:15 , 14-Май-19 (28) –3
- Уязвимость в сетевом стеке ядра Linux, Нанобот, 11:57 , 14-Май-19 (37)
- Уязвимость в сетевом стеке ядра Linux, Ilya Indigo, 21:19 , 14-Май-19 (58) –1
- Уязвимость в сетевом стеке ядра Linux, Аноним, 21:06 , 13-Май-19 (4)
- Уязвимость в сетевом стеке ядра Linux, zanswer CCNA RS and S, 05:03 , 14-Май-19 (19)
Я не буду самостоятельно делать глубоких выводов о данной спорной ситуации, поскольку мне не известна мотивация сотрудника 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 имел место быть, хоть и в тестовом патче. Тем не менее требовал особой настройки со стороны ядра. Я постараюсь найти комментарии с обратной стороны, может быть тогда будет понятно, кто прав, а кто виноват.
- Уязвимость в сетевом стеке ядра Linux, Аноним, 07:23 , 14-Май-19 (20) +3
- Уязвимость в сетевом стеке ядра Linux, Онаним, 07:58 , 14-Май-19 (21)
- Уязвимость в сетевом стеке ядра Linux, Аноним, 08:54 , 14-Май-19 (23)
- Уязвимость в сетевом стеке ядра Linux, Аноним, 10:22 , 14-Май-19 (30)
- Уязвимость в сетевом стеке ядра Linux, PnDx, 10:51 , 14-Май-19 (31) +1
- Уязвимость в сетевом стеке ядра Linux, Аноним, 19:05 , 14-Май-19 (55)
- Уязвимость в сетевом стеке ядра Linux, Аноним, 21:16 , 14-Май-19 (57) –1
- Уязвимость в сетевом стеке ядра Linux, Аноним, 05:39 , 15-Май-19 (61)
|