https://www.opennet.ru/opennews/art.shtml?num=57032 #cve

"Как и в случае с первой уязвимостью исправление проблемы вызывает недоумение - устранение проблемы сводится к тому, что для чтения файла конфигурации теперь запускается внешняя утилита "cat" ('Command::new("/bin/cat").arg(path).output()')."

"I am an 18 year old open-source developer and Linux enthusiast from the Philippines." #школота

(я тут немного манипулирую читателем, потому что это возраст автора фикса, а не автора исходного варианта, который я просто не знаю)

Хочу поспекулировать вот на какую тему.

Развитие программиста - долгий, многогранный, процесс. Человек одновременно учится инструментам, API, взаимодействию с товарищами.

Поэтому, раньше, когда человек наУчивался писать на С/С++ без проездов и багов, он уже начинал что-то понимать в Unix, в каких-то своих предметных областях, и так далее.

Rust же позволяет писать человеку memory safe код, и, на первый взгляд, кажется, что все ОК, а на самом деле школьник там 10 CVE допустил. А если бы писал на С/C++, то у вас программа бы просто упала на старте, и до дела бы дело не дошло.

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

Я искал себе login manager, чтобы не всратый, и lightweight, пока не нашел.

Зато могу привести пример "гармоничного" развития программиста - вот человек ищет себе свободный X display - https://github.com/fairyglade/ly/blob/master/src/login.c#L25. Ну так у него и код(этого демона в общем) течет и падает, никто в здравом уме пользоваться не будет.

Короче, возрастной ценз в президенты - не зря, ох, не зря.

———
Парочка "прикольных" предупреждения от сборки с clang, волосы на жопе шевелятся:

common.c:125:29: warning: 
    format specifies type 'char *' 
    but the argument has type 'int' 
    [-Wformat]

    fprintf(stream, _("%s."), 
        strerror_r(error, buf, DESCR_BUFSZ));

xfs_copy.c:264:21: warning: 
    comparison between pointer and integer 
    ('pthread_t' (aka 'struct __pthread *')
    and 'pid_t' (aka 'int')) 
    [-Wpointer-integer-compare]

    if (target[i].pid == pid)  {

https://www.opennet.ru/opennews/art.shtml?num=57131 #cve

Уязвимость и уязвимость, но подход коллег к уязвимостям доставляет:

"В марте была попытка отдельно связаться с сопровождающим проект uClibc-ng, но он ответил, что не в состоянии исправить уязвимость самостоятельно и рекомендовал публично раскрыть информацию о проблеме, рассчитывая получить помощь в разработке исправления от сообщества."

Я, как ни странно, считаю, что это очень разумный подход. Денег не платите - DIY.

———
Две новости про Rust:

https://www.opennet.ru/opennews/art.shtml?num=57133 - кусок clamav переписали на subj.

https://www.phoronix.com/scan.php?page=news_item&px=System76-Scheduler-1.1 - насколько я понимаю, это деятельность одного из авторов redox, какие-то патчи для шедулера Linux, тоже на Rust. Патчи для меня интересные, потому что про desktop responsivenress.

https://github.com/pop-os/system76-scheduler

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

Короче, школота беснуется, фанбои довольны.

———
Продолжая вчерашнюю тему про wayland clipboard.

Есть такой проект, https://github.com/bugaevc/wl-clipboard, с двумя cli тулзами:

wl-paste, она позволяет или напечатать содержимое clipboard на stdin, или запустить обработчик на поступления новых сообщений в буфер обмена. Скажем, wl-paste -w cat просто печатает новые сообщения на экран.

wl-copy копирует stdin в clipboard. (На самом деле, технически, запускает фоновый процесс, который держит это сообщение, пока оно нужно)

Удобно?

Казалось бы, запусти себе wl-paste -w wl-copy, и ты получишь персистентный clipboard в wayland?

Какое там, команда приводит к 100% потреблению CPU, потому что wl-copy не проверяет, что в clipboard лежит то же самое, что мы хотим положить, и мы получаем бесконечный цикл.

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

Наверняка какое-нить очередное ЧСВ у автора, я пока не разбирался.

Так же доставляет тот факт, что тулза пытается делать временные файлы прямо в /tmp.

TMPDIR? XDG_RUNTIME_DIR? Не, не слышали.

https://www.opennet.ru/opennews/art.shtml?num=57358 #cve #CVE

"It is all about probability"

Извините, что опять не про сборку, но у меня бугуртит, и я хочу поделиться.

Full disclosure - я не верю в безопасность. По крайней мере, в том виде, в котором ее нам "продают".

Я не верю в CVE.

Реальные взломы не происходят через публично доступные CVE. Ладно, на самом деле, раз в год бывают ситуации, когда в CVE пишут "ну вот тут у нас сломан chrome, и мы реально встречали взломы через этот баг in the wild". Раз в год, из всех CVE.

Во всем остальном база данных CVE:

* PR для тех или иных работников безопасности. Найти какую-нить дичь, которой присвоят CVE - это всегда полезно для CV.

* Удобная пугалка для RedHat, с помощью которой можно обосновать необходимость платной подписки на обновления софта.

* Удобный аргумент для сторонников динамической линковки. На самом деле, так себе аргумент, потому что пересобрать все зависимости не так уж и дорого(помните, я писал про скорость роста CPU мощностей, и про скорость роста сложности софта?), и скачать их через CDN - тоже.

Я, например, не согласен, что, когда случается баг в zlib, нужно бежать сломя голову, и обновлять всякое старое говно мамонта.

Когда нашли багу в zlib, нужно обновить nginx/envoy/etc, и не более того. Все остальное - в порядке очереди.

Есть один класс проблем, которые нужно чинить быстро - это проблемы в браузере.

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

Так же я не верю в CVE, потому что bug bounty программы от вендоров - это смешные копейки.

Будьте уверены, что реальные zero days люди продают за десятки миллионов долларов, в даркнете.

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

Поэтому CVE, и дыры, через которые реально хачат - это две большие разницы.

Так, введение закончилось, теперь про данный конкретный случай.

Что я про него могу сказать?

Статья на https://lwn.net/Articles/897914/ про него начинается так:

"Today's branded, logo-equipped vulnerability is known as Hertzbleed"

Что тут написано? Что авторы уже придумали красивое название, и завели сайт, посвященный уязвимости.

На самом деле, на этом можно было бы и закончить, и ежу понятно, на кого вся эта показуха рассчитана(не на нас с вами), добавлю только, что я очень хочу, чтобы облачные вендоры уже начали разделять локации с mitigations=off, и с mitigations=on.

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

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

PS: текст довольно controversal, поэтому я тут явно напишу, что это исключительно мое, и только мое, мнение.

https://lwn.net/Articles/900917/ #cve
https://comsec.ethz.ch/research/microarch/retbleed/

Еще пачка spectre-like уязвимостей, ничего интересного, кроме того, сколько стоит их исправление:

"Our performance evaluation shows that mitigating Retbleed has unfortunately turned out to be expensive: we have measured between 14% and 39% overhead with the AMD and Intel patches respectively."

Очень жду от облачных провайдеров разделение на независимые кластера, с mitigations=off, и mitigations=on, потому что зачем мне платить "за того парня с паранойей"?

https://mort.coffee/home/tar/
https://www.opennet.ru/opennews/art.shtml?num=57587 #CVE

Я тут подумал, что было бы очень круто, если бы всякого рода распаковщики можно было запускать в своем mount namespace + chroot, ну, то есть, чтобы / был той папкой, куда мы распаковываем.

Например, вот так:

pg-> unshare -r -m sh
pg-> mkdir -p new_root/bin
pg-> cp /bin/* new_root/bin/
cp: omitting directory '/bin/bin_dhcpcd_sys'
cp: omitting directory '/bin/bin_ix'
cp: omitting directory '/bin/bin_openresolv'
pg-> chroot new_root /bin/sh
pg-> ls -la /
total 16
drwxr-xr-x    3 0  0 17 Aug  3 02:32 .
drwxr-xr-x    3 0  0 17 Aug  3 02:32 ..
drwxr-xr-x    2 0  0 12288 Aug  3 02:32 bin

(папочку bin я скопировал, чтобы внутри chroot можно было бы показать, где я)

Тогда они бы все перестали лазить по fs куда ни попадя, и не надо было бы реализовывать квадратичные алгоритмы в tar.

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

https://lwn.net/Articles/907572/
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10735 #CVE

"A flaw was found in python. In algorithms with quadratic time complexity using non-binary bases, when using int("text"), a system could take 50ms to parse an int string with 100,000 digits and 5s for 1,000,000 digits (float, decimal, int.from_bytes(), and int() for binary bases 2, 4, 8, 16, and 32 are not affected). The highest threat from this vulnerability is to system availability"

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

(тут нельзя не вспомнить цитату Линуса про "security glory hole" - https://lkml.org/lkml/2008/7/15/296)

А какой-то упырь в python взял и закоммитил ограничение на максимальную длину обрабатываемого числа, тем самым, сделав из generic алгоритма непонятное УГ. Ну, и, конечно, сломал каких-то клиентов.

А почему мы не ограничим сортировку? А почему не ограничим любой > O(n), или даже просто > O(1) алгоритм?

Короче.

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

А разработчики, видимо, тоже мотивированы эти "CVE" потом "фиксить", самым диким образом.

Про тормознутую реализацию bigint из python я вообще молчу, зачем они ее тащат с собой, когда есть более продвинутые и доступные реализации?

#security #CVE

Меня тут спрашивают, почему я не пишу про всякие интересные уязвимости в CPU, типа

https://www.opennet.ru/opennews/art.shtml?num=59571
https://comsec.ethz.ch/research/microarch/inception/

Я не знаю.

Это было интересно в первый раз (а все помнят название первой уязвимости такого класса? Я вот уже забыл).

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

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

Когда их сложно найти, и легко починить, то почет и уважение тем, кто их ищет, почет и уважение тем, кто их фиксит, все довольны, все получили свою 5+, и всем пофиг, что ущерб не нанесен, потому что in the wild оно не эксплуатировалось.

А вот когда починить реально дорого, прямо очень дорого, то люди ВНЕЗАПНО вспоминают, что умеют считать деньги, и просто игнорируют всю эту шелуху и весь этот абсурдный театр безопасности.

https://www.opennet.ru/opennews/art.shtml?num=59683 #CVE

"Спорные отчёты направлены анонимно через сервис информирования об уязвимостях NVD. Мотив публикации не ясен, вероятно кто-то решил продемонстрировать отсутствие должного аудита при приёме отчётов об уязвимостях, возможность использования CVE как механизма для дискредитации проектов или привлечь внимание к исправлению в коде потенциально опасных проблем без анализа их влияния на безопасность"

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

Например:

https://t.iss.one/itpgchannel/401
https://t.iss.one/itpgchannel/600

https://www.opennet.ru/opennews/art.shtml?num=61466 #CVE

Опять та же самая организация (MITRE) отправила CVE, без возможности как-то аргументировать отсутствие ошибки.

И, как выяснилось, эта организация делает так довольно часто, пострадали не только curl и io.js, но и, например, aiohttp - https://github.com/github/advisory-database/pull/3504#issuecomment-2198884952

Ну, чем больше будет таких историй, тем быстрее эта лавочка дискредитирует себя, и безопасники будут заниматься поиском ошибок, а не присвоением id-шника CVE всякой чепухе.

Процитирую себя же:

"Индустрия страдает из-за того, что безопасники мотивированы(известность, статус, премии) приписать шильдик CVE к любой хероте.

А разработчики, видимо, тоже мотивированы эти "CVE" потом "фиксить", самым диким образом."

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

https://github.com/github/advisory-database/pull/3504#issuecomment-2201065321
https://huntr.com/bounties/bfc3b23f-ddc0-4ee7-afab-223b07115ed3
https://github.com/indutny/node-ip/issues/126