Компания Netflix выявила (https://www.openwall.com/lists/oss-security/2019/06/17/5) несколько критических уязвимостей (https://github.com/Netflix/security-bulletins/blob/master/ad...) в TCP-стеках Linux и FreeBSD, которые позволяют удалённо инициировать крах ядра или вызвать чрезмерное потребление ресурсов при обработке специально оформленных TCP-пакетов (packet-of-death). Проблемы вызваны (https://access.redhat.com/security/vulnerabilities/tcpsack) ошибками в обработчиках максимального размера блока данных в TCP-пакете (MSS, Maximum segment size) и механизма выборочного подтверждения соединений (SACK, TCP Selective Acknowledgement).
- CVE-2019-11477 (https://security-tracker.debian.org/tracker/CVE-2019-11477) (SACK Panic) - проблема проявляется в ядрах Linux начиная с 2.6.29 и позволяет вызвать крах (panic) ядра через отправку серии SACK-пакетов из-за возникновения целочисленного переполнения в обработчике. В качестве обходных путей защиты можно отключить обработку SACK (записать 0 в /proc/sys/net/ipv4/tcp_sack) или заблокировать (https://github.com/Netflix/security-bulletins/blob/master/ad...) соединения с низким MSS (работает только при выставлении sysctl net.ipv4.tcp_mtu_probing в 0 и может нарушить работу некоторых нормальных соединений с низким MSS);- CVE-2019-11478 (https://security-tracker.debian.org/tracker/CVE-2019-11478) (SACK Slowness) - приводит к нарушению работы механизма SACK (при использовании ядра Linux младше 4.15) или избыточному потреблению ресурсов. Проблема проявляется при обработке специально оформленных SACK-пакетов, которые можно использовать для фрагментирования очереди повторной передачи (TCP retransmission). Обходные пути защиты аналогичны предыдущей уязвимости;
- CVE-2019-5599 (https://security-tracker.debian.org/tracker/CVE-2019-5599) (SACK Slowness) - позволяет вызвать фрагментацию карты отправленных пакетов при обработке специальной последовательности SACK в рамках одного TCP-соединения и вызвать выполнение ресурсоёмкой операции перебора списка. Проблема проявляется во FreeBSD 12 с механизмом определения потери пакетов RACK. В качестве обходной меры можно отключить модуль RACK;
- CVE-2019-11479 (https://security-tracker.debian.org/tracker/CVE-2019-11478) - атакующий может вызвать в ядре Linux разделение ответов на несколько TCP-сегментов, каждый из которых включает только 8 байт данных, что может привести к существенному повышению трафика, увеличению нагрузки на CPU и забиванию канала связи. В качестве обходного метода защиты рекомендовано заблокировать (https://github.com/Netflix/security-bulletins/blob/master/ad...) соединения с низким MSS.
В ядре Linux проблемы устранены в выпусках 4.4.182, 4.9.182, 4.14.127, 4.19.52 и 5.1.11. Исправление для FreeBSD доступно в виде патча (https://github.com/Netflix/security-bulletins/blob/master/ad...). В дистрибутивах обновления пакетов с ядром уже выпущено для Debian (https://security-tracker.debian.org/tracker/CVE-2019-11477), RHEL (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-11477), SUSE/openSUSE (https://www.suse.com/security/cve/CVE-2019-11477/). Исправление в процессе подготовки в Ubuntu (https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2...), Fedora (https://bodhi.fedoraproject.org/updates/?releases=F30&type=s...) и Arch Linux (https://security.archlinux.org/).
URL: https://www.openwall.com/lists/oss-security/2019/06/17/5
Новость: https://www.opennet.me/opennews/art.shtml?num=50889
Это тестами выявили или при эксплуатации , от пользователей пакеты завешивали их сервера и они это смогли выявить?
> Это тестами выявили или при эксплуатации , от пользователей пакеты завешивали их
> сервера и они это смогли выявить?Написано же, им сообщили:
| Acknowledgments:
| Originally reported by Jonathan Looney.
Сижу на 2.6.16 и вообще не парюсь. Хипсторы, качающие софт в день релиза, должны страдать.
то, что вы любитель окаменелостей, не умаляет того, что проблема есть ;)
Ты должен спасибо говорить багтестерам, а не желать им страданий.
Наслаждайся своими уязвимостями большего количества и качества, чем указанные в статье.
> Наслаждайся своими уязвимостями большего количества и качества, чем указанные в статье.вы, конечно же, можете предъявить хотя бы пару?
(_remote_. локальных да, не то что "больше количества и качества", но _найденных_, разумеется, больше. Когда их столько же найдут в самом наираспоследне-свежайшем, с дымком - оно уже станет немодно-немолодежно)
>> Наслаждайся своими уязвимостями большего количества и качества, чем указанные в статье.
> вы, конечно же, можете предъявить хотя бы пару?Легко:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11815 — «An attacker can exploit this issue to … execute arbitrary code» TCP-пакетами аж с 2.0.40
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10229 — «An attacker can exploit this issue to execute arbitrary code in the context of the kernel» через UDP как минимум во всех 2.6
>>> Наслаждайся своими уязвимостями большего количества и качества, чем указанные в статье.
>> вы, конечно же, можете предъявить хотя бы пару?
> Легко:ну где ж тут качество?
rm /lib/modules/*/kernel/net/rds/rds.ko
rm /lib/modules/*/kernel/net/rds/rds_*.ko # хз что это, было в каких-то 2.6
следом за кучей других нужных и полезных чудо-фич - нет ножек, нет проблемы.> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10229 — «An
этот действительно серьезный, но это ж 2015го года проблема (в 16 всплыла из-за кривофикса) - уж за такое время можно бы было и бэкпорт как-нибудь осилить?
> уж за такое время можно бы было и
> бэкпорт как-нибудь осилить?Добровольно подписывающиеся на некрофилию люди бекпорты трогать обычно брезгуют. Их от последствий следования мантре «работает — не трогай» обычно спасает лишь тот факт, что престарелый оракл недостаточно модный, чтобы выставлять его по умолчанию голой жопой в интернет.
> FreeBSD: В качестве обходной меры можно отключить модуль RACK;Вобщето для начала его неплохо бы включить, чтобы было что выключать. Оно само не вклюбчается.
$ sysctl net.inet.tcp.functions_available
net.inet.tcp.functions_available:
Stack D Alias PCB count
freebsd * freebsd 131тут будет еще rack, если сначала ядро пересобрать с нужными опциями, а потом загрузить полученный модуль имени Нетфликса...
Есть ещё нормальный Unix. Пойду задоначу им ещё.
Тем более что завтра
https://nationaldaycalendar.com/national-freebsd-day-june-19/
FreeBSD не Unix.
Вот https://www.opengroup.org/openbrand/register/ список того что является Unix'ом. Все. Все остальное не UnixOracle Corporation: Oracle Solaris 11.4 Operating System and later, on SPARC-based and X86 based platforms
Apple Inc.: macOS version 10.14 Mojave on Intel-based Mac computers
IBM Corporation: AIX version 7, at either 7.1 TL5 (or later) or 7.2 TL2 (or later) on systems using CHRP system architecture with POWER™ processors
Apple Inc.: macOS version 10.13 High Sierra on Intel-based Mac computers
Cemprus LLC: DNCP Series running FTX Release 3
Hewlett Packard Enterprise: HP-UX 11i V3 Release B.11.31 or later on HP Integrity Servers
Hewlett Packard Enterprise: HP-UX 11i V3 Release B.11.31 or later on HP 9000 Servers with Precision Architecture
Huawei Technology Co., Ltd: Huawei EulerOS 2.0 on Huawei KunLun Mission Critical Server
IBM Corporation: AIX 6 Operating System V6.1.2 with SP1 or later on Systems using CHRP system architecture with POWER™ processors and 2, 8 or 128 port async cards
IBM Corporation: AIX 5L for POWER V5.3 dated 7-2006 or later on Systems using CHRP system architecture with POWER™processors
IBM Corporation: z/OS V2R1 or later with: z/OS V2R1 or later Security Server and z/OS V2R1 or later C/C++ Compiler on IBM zSeries Processors that support z/OS Version 2 Release 1 or later
Oracle Corporation: Oracle Solaris 11 FCS and later on SPARC-based platforms, 32-bit and 64-bit and on X86-based platforms, 32-bit and 64-bit
Oracle Corporation: Solaris 10 Operating System plus patch 118844-06 for X86 and on, on 64-bit X86 based systems
Oracle Corporation: Solaris 10 Operating System and on, on 32-bit and 64-bit SPARC based systems
Oracle Corporation: Solaris 10 Operating System and on, on 32-bit X86 based systems
Oracle Corporation: Solaris 9 12/02 X86 Platform Edition and later on 32-bit X86 based systems
Oracle Corporation: Solaris 9 and on, (SPARC 32 bit and 64 bit Platform Editions)
The SCO Group, Inc.: UnixWare ® 7.1.3 and later for single and multiprocessor systems based on IA-32 and compatible processors and conforming to PC architecture
The SCO Group, Inc.: SCO OpenServer Release 5 and OpenServer Release 6 on Single and Multi-processor Industry Standard Intel architecture platforms
Все вышеперечисленное сертифицировано на соответствие юних-совместимости.Реально же юнихами могут называться только два последних бедолаги, происходящие от AT&T UNIX, выкупленных в конце концов SCO Inc. Это - труЪ юнихи, все остальное - юних-лайки.
Но, конечно же, макось в списке тру-юнихов - это прекрасно, просто прекрасно!
Все перечисленное и есть Unix, так как получило сертификат. А остальное не Unix.
macOS — Unix, какие могут быть сомнения? Все тесты пройдены и сертификат получен. Именно так это и определяется. Если что-то соответствует стандарту, проходит положенные тесты и получило сертификат, это что-то Unix. А все остальное это твои фантазии про «происходящее» и так далее. Твои фантазии никому не интересны.
> Все перечисленное и есть Unix, так как получило сертификат. А остальное не
> Unix.потому что братве не занесли?
> macOS — Unix, какие могут быть сомнения?
действительно - мафии уплачено, сертификат выписан.
А все остальное - не юниксы, так, фигня какая-то.
> получен. Именно так это и определяется. Если что-то соответствует стандарту, проходит
> положенные тесты и получило сертификат, это что-то Unix. А все остальное
> это твои фантазии про «происходящее» и так далее. Твои фантазии никому
> не интересны.наоборот - никому неинтересна филькина грамота про какие-то тесты непойми чего непойми кем.
ну, конечно же, кроме парней в доле.
С какой целью ты врешь? Мне интересны его фантазии. И даже твои. Иначе я бы не читал опеннет. Или хочешь заявить, что ты весь такой нефантазийный в белом жабо?
> Huawei Technology Co., Ltd: Huawei EulerOS 2.0 on Huawei KunLun Mission Critical ServerWhat is the Euler OS?
Euler OS is a Linux Distribution, based on CentOS, released by Huawei.
> тут будет еще rack, если сначала ядро пересобрать с нужными опциями, а
> потом загрузить полученный модуль имени Нетфликса...Хех.
Для начала придеться еще найти, как и где включить -- я ради любопытства полез в доки и сходу ничего не нашел.
Только после гуглежа:
https://reviews.freebsd.org/rS334804
> To build this into your kernel you will need to enable in your kernel:
> makeoptions WITH_EXTRA_TCP_STACKS=1
> options TCPHPTSт.к.
kern.opts.mk
__DEFAULT_NO_OPTIONS = \
EXTRA_TCP_STACKS \
KERNEL_RETPOLINE \
NAND \
OFED \
RATELIMIT
т.е. требуется пересобрать ядро и прописать в /etc/sysctl.conf
net.inet.tcp.functions_default=rack
И как с этим в миллионах необновляемых андроидов и миллионах (обычно тоже не обновляемых) домашних рутеров ? (понятно, что далеко не каждого из рутеров можно заставить установить ТСП соединение с кем надо, но много таких, в которых чтото попосыллать можно.) Судя про номерам версий ядер в ЦВЕ, тут все тоже "хорошо", а обновления не будет.
> И как с этим в миллионах необновляемых андроидов и миллионах (обычно тоже
> не обновляемых) домашних рутеров ?отлично всё с этим, должно работать как написано.
Ушёл расчехлять dsl-300t, там 2.4.17 стоял
1. Там пищят дроссели
2. Это не имеет смысла, ибо он либо бриджём умеет и тогда твой TCP стёк доступен или ZIPB - прозрачный нат с ограничением в 100 соединений, и опять же твой TCP доступен.
А в CentOS когда?
пятый центос (2.6.18) неуязвим!
...хотя эти могли и бекпортировать
для центос 7 родили...
А ветка 3.16 и не думала обновляться. Maintainer Ben Hutchings на неё забил, хотя поддерживать обещал до апреля 2020 года.
Вот теперь, по традиции опеннета: "Это опенсорс! Вам никто ничего не обязан! Надо - поддерживайте сами!" И все такое.
вендeкапец
Миллионы красных глаз не спят - ревьюют код в режыме 24/7, и святой Ричард с апостолом Линусом их благословляют.
> "Это опенсорс! Вам никто ничего не обязан! Надо - поддерживайте сами!"Вообще-то разработчики ядра берут на себя обязанность закрывать баги в своём ядре. Вот только ресурсы у них не резиновые, чтобы поддерживать абсолютно все версии ядра, что они выпустили. Тем более разработкой новых возможностей тоже надо заниматься. Хотите поддержки - используйте актуальные версии ПО.
Кстати, ещё бы на Microsoft наехали, что она в Windows XP и Vista дыры в безопасности не фиксит.
Сравнил официально мертвую хрюшечку с официально живым ведром. Ты прямо Цицерон Платонович Пифагоров.
Это опенсорс! Вам никто ничего не обязан! Надо - поддерживайте сами!
не обязан, но баги исправляются..(и зачем вообще тогда говорить про обязанности)
Ладно, так и быть. Можете не сами. Можете за это платить мантейнеру. В остальном всё правда. Надоело человеку и перестал. Он действительно ничего вам не должен.
Сначала дал надежду в него поверить, а потом бросил на середине пути и даже об этом не сказал. В этом весь опенсорс.
> А ветка 3.16 и не думала обновляться. Maintainer Ben Hutchings на неё
> забил, хотя поддерживать обещал до апреля 2020 года.Скачал и почитал https://mirror.yandex.ru/debian-security/pool/updates/main/l... за тебя:
3.16.68-2-$ egrep '^([^ ]| --)' changelog -m 10
linux (3.16.68-2) jessie-security; urgency=high
-- Ben Hutchings <ben@decadent.org.uk> Mon, 17 Jun 2019 16:57:59 +0100
linux (3.16.68-1) jessie-security; urgency=high
-- Ben Hutchings <ben@decadent.org.uk> Wed, 22 May 2019 23:27:42 +0100
linux (3.16.64-2) jessie-security; urgency=high
-- Ben Hutchings <ben@decadent.org.uk> Mon, 01 Apr 2019 04:10:04 +0100
linux (3.16.64-1) jessie-security; urgency=high
-- Ben Hutchings <ben@decadent.org.uk> Mon, 25 Mar 2019 18:05:41 +0000
linux (3.16.59-1) jessie-security; urgency=high
-- Ben Hutchings <ben@decadent.org.uk> Wed, 03 Oct 2018 04:25:08 +01003.16.68-2-$ _
Не https://duckduckgo.com/?q=ben-hutchings+3.16.68&t=ffnt&ia=web
благодари https://lkml.org/lkml/2019/5/16/748 ,
не надо https://lore.kernel.org/lkml/?q=Hutchings+3.16 .PS: Совсем инфраструктуру забросили-запустили-развалили, на
https://metadata.ftp-master.debian.org/changelogs//main/l/li...
linux_3.16.56-1+deb8u1_changelog 2018-05-08 15:11 1.1M
последний.PPS: https://www.kernel.org/
longterm: 3.16.68 2019-05-22
Где же забил, если 3 недели назад выходило обновление? Думаешь, легко моментально бекпортировать патчи? Потерпи денёк-другой.
Если кому понадобится для 4.4 -- брать здесь:http://git.altlinux.org/people/kernelbot/packages/kernel-ima...
https://packages.altlinux.org/ru/c8/srpms/kernel-image-std-d...(и да, мы знали заранее)
> Если кому понадобится для 4.4 -- брать здесь:Бену https://www.decadent.org.uk/ben/blog/2019/06/02/debian-lts-w...
надо. Но это вам раньше надо было. Сейчас-то он, поди, уже....Впрочем, у них там торговая война с китаем, но от Русских Хакеров по-прежнему могут постесняться принять патчей.
> (и да, мы знали заранее)
> Бену www.decadent.org.uk/ben/blog/2019/06/02/debian-lts-work-may-2019https://www.decadent.org.uk/ben/blog/debian-lts-work-may-201...
> надо
проверять ссылки. Надо проверять ссылки. Надо проверять ссылки.
Почитал. Сурово пришлось Бену...
У альта нет вменяемой секьюрити странички? Даже у школьников из арча такая есть.
> Если кому понадобится для 4.4 -- брать здесьСпасибо, но мы лучше возьмём здесь:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...
> Если кому понадобится для 4.4 -- брать здесь:Если закладок от товарище Майора нет, тогда брать ну буду.
Вы, кстати, в каком звании?
Возможно скоро появиться удаленный рут через ремоте-tcp :)
>Для защиты от переполнения в коде имеется проверка, которая приводит к вызову функции BUG_ON() и переводу ядра в состояние panic.
Ну, перемудрили, что сказать.
Вполне могли бы игнорировать все предложения ставить MSS меньше 536.
Не зря ребята из МЦСТ тихонько матерились на код ядра Linux
> Не зря ребята из МЦСТ тихонько матерились на код ядра Linuxну да. проклятые буржуи со своим GPL! не то что *BSD. но *BSD отчего-то брать не захотели.
>> Не зря ребята из МЦСТ тихонько матерились на код ядра LinuxНевоспитанные какие. Ты их палкой, палкой -- пусть молча копают, куда дадено.
> ну да. проклятые буржуи со своим GPL! не то что *BSD. но
> *BSD отчего-то брать не захотели.Эффективные в погонах их ссильничали.... А виноват код, понятное дело!
GPL! GPL!
Вот только именно линукс и впихнули в уютненькую десяточку. Зато ГПЛ! Ни шагу назад! ни строчик проприетасам!
> GPL! GPL!
> Вот только именно линукс и впихнули в уютненькую десяточку. Зато ГПЛ! Ни
> шагу назад! ни строчик проприетасам!ты бы, барин, всё-таки разобрался, про что именно GPL. а то скажешь такое где-нибудь, где не такие вежливые собеседники — получится совсем конфуз.
>> GPL! GPL!
>> Вот только именно линукс и впихнули в уютненькую десяточку. Зато ГПЛ! Ни
>> шагу назад! ни строчик проприетасам!
> ты бы, барин, всё-таки разобрался, про что именно GPL. а то скажешь
> такое где-нибудь, где не такие вежливые собеседники — получится совсем конфуз.Он хозяйских цЫркуляров не читал. Балаболит свосем не в струю.
Изучайте конспекты, хватит халявить:
http://www.opennet.me/openforum/vsluhforumID3/111315.html#33
http://www.opennet.me/openforum/vsluhforumID3/112865.html#21
[дождались!] http://www.opennet.me/openforum/vsluhforumID3/111689.html#36
http://www.opennet.me/openforum/vsluhforumID3/107903.html#129
http://www.opennet.me/openforum/vsluhforumID3/109155.html#41
http://www.opennet.me/openforum/vsluhforumID3/117005.html#51
Не в том дело, на GPL они и так кладут местами (по крайней мере пока).
Именно в качестве кода.Насколько знаю, там как-то попытались портировать линукс на эльбрусовый защищённый режим ptr128 со строгой памятью -- просто не взлетел (как, собственно, и glibc -- сейчас эксперименты идут с портированной/допиленной musl в контейнерах).
это всё слухи и прочий недоказуемый smalltalk. я вот в своё время про Unreal Engine (который 1 и 2) слышал, что код там ужасен, все конечности и мозг можно сломать, пришлось полностью перерабатывать, чтобы нормально заработало и всё вот такое. а потом код в сеть утёк — и он оказался очень красивым и понятным. а вот к квалификации «дорабатывателей» появились огромные вопросы.
Это "почём купил, по том продал". О чём и сказано сразу же рядом.
> Не зря ребята из МЦСТ тихонько матерились на код ядра LinuxПусть покажут свои патчи, мы поржём. А то тут один ребятёнок из Росы недавно тихо матерился на код rpm5, хотя сам туда коммиты с синтаксическими ошибками делает.
Там непосредственно в патче нет ошибки, это ABF Росы часть кода не показывает. Да и патч из rpm4. Да и работник, если как следует об этом призадуматься, ни при чём -- кто там и чем думал, когда переходили с rpm4 на rpm5 (созданный после эпичного отказа Джеффа исправлять баг в rpm4) -- вот в чём вопрос.
они обнаружили там набор замечательных, блестящих, острозаточенных, гениальных... костылей
> они обнаружили там набор замечательных, блестящих, острозаточенных, гениальных... костылейСначала матероились, когда обнаружили там синтаксические ошибки.
Потом матерились, когда обнаружили, что сами их и накоммитили туда.
А потом матерились, когда не смогли их справить...
А после....Невоспитанные же. Палкой их.
> Не зря ребята из МЦСТ тихонько материлисьОни не матерились, это они так разговаривают.
Естл эксплоиты?
> Естл эксплоиты?тут -- нет. купи в дырконете и выложи сюда -- будут. понел-понел?
Купи не дорого
Где и по чём?
> Где и по чём?"--мама сказала, что деньги в бидоне."
Без регистрации и СМС?
вот это жесть...
а зачем они разрешают такой мелкий mss? он даже у диалапов был 512байт.
iptables -A INPUT -p tcp -m tcpmss --mss :300 -j DROP
как вариант рещения
Ради антиреса, насколько напряжет цпу и на сколько увеличит задержку разбор каждого тцп пакетика ради анализа?
Скажем на 1Гбит или 10Гбит потоке?
на время, соизмеримое с ошибкой измерения.Поскольку проверяется пара битов по маске, а основное время вообще тратится на проверку что эти биты там действительно есть,а не подсунули кривой пакет.
> на время, соизмеримое с ошибкой измерения.лол што?
Это был один из самых чудесных дней в моей жизни. Google Cloud вообще не чесались с исправлениями.
obvious iptables fix.