В библиотеке libcue, используемой для разбора метаданных cо сведениями о порядке и длительности звуковых треков, выявлена уязвимость (CVE-2023-43641), позволяющая организовать выполнение кода при обработке специально оформленных cue-файлов. Библиотека используется в некоторых мультимедийных проигрывателях и звуковых редакторах, включая Audacious, и может быть использована для компрометации системы при открытии в них непроверенных данных...Подробнее: https://www.opennet.me/opennews/art.shtml?num=59896
Ох, эта libcue такая кривая дрянь, вы таки не поверите. По-моему даже если файл не заканчивается пустой строкой сегфолтится. Использовать её для автоматического разбора файлов несколько опрометчиво (хотя вполне ожидаемо для гномеров).
О, да. Я помню как долго с этим бился. Бывало, отредактируешь cue sheet в винде из foobar как тебе нужно и всё зашибись. Но потом в линуксе опа! и этот куй не читается? Я дооолго не мог понять в чём дело. Кодировка? Нет. Тогда почему? Голову сломал. И только как-то невзначай до меня вдруг дошло, что я при редактировании всегда убираю пустую строку в конце. Ну а нахер она нужна? Некрасиво же. А вот невменяемому линуксу оказывается она жизненно необходима! И смех и грех.
Ты будешь смеяться, но это пофиксили. Буквально пару недель назадhttps://github.com/lipnitsk/libcue/commit/11e006a9a086e312a0...
Мне не смешно Code taken from https://stackoverflow.com/questions/1756275/bison-end-of-file
Причем тут Linux?
Потому что в Linux написал скрипт баше, и уже программист.
Прикол в том, что вантузники никогда не смогут осилить GNU bash.
И правильно делают. Я бы на их месте тоже не стал менять язык программирования на скриптоту, рассчитанную на написание максимум 10-ти строк.
> при редактировании всегда убираю пустую строку в конце. Ну а нахер она нужна?Текстовый файл -- это последовательность строк. Строка -- это последовательность символов, завершающихся символом "\n". Держи формальное определение:
TEXT := LINE*
LINE := [^\n]* "\n"Когда убираешь пустую строку в конце непустого файла, файл перестает быть текстовым и становится... бинарным. По определению.
Фубару и Аимпу в винде и андроиде пофиг. Мне тоже.
> я при редактировании всегда убираю пустую строку в конце
> пофиг. Мне тоже.Я специально удаляю конец последней строки в файле, потому что мне пофик.
Можно ещё сказать, что когда убираешь символ конца строки после последней строки, последняя строка становится бесКОНЕЧной, и падение библиотеки при её парсинге неудивительно (кроме случаев, когда у пользователя бесконечное количество оперативной памяти).
Но для этого вы должны использовать специальную библиотеку. Libcue называется.
> Можно ещё сказать, что когда убираешь символ конца строки после последней строки,
> последняя строка становится бесКОНЕЧнойБесконечных вещей всего две: Вселенная и человеческая глупость.
>>Бесконечных вещей всего две: ВселеннаяЕсть теория, согласно которой Вселенная конечна, но постоянно расширяется, так что до края не доберёшься.
С глупостью то же самое)
Ну почему же
Конца глупости таки можно достичь - в конце тоннеля или в отдельном котле, смотря на чём кодил
И да, держи формальное определение:> Ты будешь смеяться, но это пофиксили.
> файл перестает быть текстовым и становится... бинарнымСтранно, я всегда думал что файл - это просто набор байт, который можно интерпретировать как угодно. Это какой-то очередной бессмысленный атавизм из 70-х, вроде символа возврата каретки или символа звона телетайпа (bell character). Многие повторяют, и лупят других чтобы тоже повторяли, хотя уже не помнят почему и зачем, как в эксперименте с обезьянами и поливальным шлангом.
А ещё в конце файла обязательно должен быть байт 0x1A!!! (в Windows кстати copy file1+file2 filenew вроде до сих пор его добавляет)
\n — это не часть строки. Это разделитель строк. Зачем он нужен в конце файла — решительно непонтяно.
Причём он разный бывает — у кого \n, у кого \r\n, а у кого и вовсе \r.
Потому что при склейке файлов утилитой cat уютный мирок кекспертов по строкам начинает сыпаться.
Бред какой-то..
> Держи формальное определение:
> TEXT := LINE*
> LINE := [^\n]* "\n"А теперь предоставь ссылку на компетентный источник.
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...:> Text File
>
> A file that contains characters organized into zero or more lines.
> Line
>
> A sequence of zero or more non- <newline> characters plus a terminating <newline> character.
> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...:
>> Text File
>>
>> A file that contains characters organized into zero or more lines.Although POSIX.1-2017 does not distinguish between text files and binary files (see the ISO C standard), many utilities only produce predictable or meaningful output when operating on text files. The standard utilities that have such restrictions always specify "text files" in their STDIN or INPUT FILES sections.
>> Line
>>
>> A sequence of zero or more non- <newline> characters plus a terminating <newline> character.The lines do not contain NUL characters and none can exceed {LINE_MAX} bytes in length, including the <newline> character.
Упс. Какой же пункт прав?
И в чем противоречие? При чтении строки выделяется буфер, длинна строки включая '\n' не должна превышать размер буфера. LINE_MAX обычно 2048 байт. Дальше программист сам решает что делать с огрызком меньше 2048, но не закончившимся '\n'.
Можно выбросить, можно на ской страх и риск добавить '\n'. А можно выбросить и весь файл, как не соответствующий стандарту или поврежденный. Ведь такой файл вполне может получиться при аварийном обрыве записи, например при записи вырубили питание или прибили процесс, или при передаче сеть отвалилась.
> И в чем противоречие? При чтении строки выделяется буфер, длинна строки включая
> '\n' не должна превышать размер буфера. LINE_MAX обычно 2048 байт.С этим
>>> Держи формальное определение:
>>> TEXT := LINE*
>>> LINE := [^\n]* "\n"
> Дальше
> программист сам решает что делать с огрызком меньше 2048, но не
> закончившимся '\n'.
> Можно выбросить, можно на ской страх и риск добавить '\n'. А можно
> выбросить и весь файл, как не соответствующий стандарту или поврежденный. Ведь
> такой файл вполне может получиться при аварийном обрыве записи, например при
> записи вырубили питание или прибили процесс, или при передаче сеть отвалилась.Какому такому стандарту и при чём тут вообще POSIX?
File format
Cuesheet files are standard text (ASCII) files. You can use any text
editor, such as Notepad or Wordpad, to edit your cuesheet. Do not
save your cuesheet in any non-text format. The recommended file
extensions for your cuesheet are.cue or.txt.
При том, что когда-то давно, когда безупречная работа компьютеров и сетей не гарантировалась, а ресурсы были не бесконечные, некие ребята решили. А давайте хоть как-то сделаем текстовый файл читаемым в случае аварии при записи. И придумали такие правила: Длинна строк в текстовом файле конечна и файл обязательно заканчивается символом перевода строки. Так в случае если файл битый мы прочитаем все целые строки, а если целый и мы прочитаем его до конца, то мы можем убедиться в его целостности тем что в его конце будет строка нулевой длинны. Большинство конфигов в linux и прочих unix-like текстовые. Те кто писал разбор cue-файлов для просто решили следовать стандартам. Так он мог использовать стандартные библиотеки для чтения текстовых файлов. Не нравится - вы конечно всегда можете пропатчить разбор cue в нужном вам плеере.
Конечно вариант с пустой строкой в конце не идеальный, но альтернативой было бы рассчитывать контрольную сумму от содержимого и как-то помещать ее в текстовый файл, что делало бы уже этот файл не таким уж и текстовым.
> POSIXНу то есть для юниксов, то есть для линуксов. Алё! За их пределами жизнь есть!
Про {LINE_MAX} особенно понравилось. Это-то вообще из какого стандарта?
POSIX. И те кто его соблюдает не будут испытывать проблем с парсингом текстовых файлов совместимых с POSIX. Вне зависимости от того какую систему они используют. Linux, unix, bsd и т.п. даже windows и macos кмк. Остальные... ну можно теоретически ездить и по левой стороне дороги, и кто-то из встречных даже будет уворачиваться, но рано или поздно возможно столкновение с камазом.
Кстати, современные приложения пытаются как могут и даже подстраиваются к строкам гораздо длиннее LINE_MAX, но последнюю строку без терминатора в большинстве случаев игнорируют.
Может за пределами linux жизнь и есть, но весьма печальная. У каждого в доме есть роутер и он на 99% под linux. Более 70 % сайтов в интернете либо отдаются целиком nginx под linux(под windows он полноценно и работать не сможет), либо проксируются им же. Более 60% почтовых серверов exim, более 30% postfix.Т. е. вся сетевая инфраструктура работает под linux. ПО принтеров тоже в большинстве своем linux. Windows только у админов локалхоста, либо в корпоративных сетях за периметром из linux.
В 90% офисов уборщица есть, но не она правила устанавливает.
>> POSIX
> Ну то есть для юниксов, то есть для линуксов. Алё! За их
> пределами жизнь есть!За их пределами и возник этот Cuesheet:
The cue sheet format was invented by Jeff Arnold of GoldenHawk Technology for use with his DAO (Disc At Once) and CDRWIN applications. The format has since been adopted as the de facto standard, and is used by various other applications, including the audio player foobar2000. The official cue sheet specification is widely accepted to be Appendix A of the CDRWIN User's Guide.
> Про {LINE_MAX} особенно понравилось. Это-то вообще из какого стандарта?
Ну что не ясно, всякая программа должна вызвать баш и выполнить getconf LINE_MAX, а потом работать по стандарту.)))
Что ни день, то новая уязвимость.Терпим.
Господи, это же просто тестовый файл! Как можно написать кривой код, его читающий?!Надо проверить как они строки читают, нет ли там кастомной либы для преобразования строк. Это в стиле сишников – изобретать своё уникальное решение на каждую задачу...
Там сгенерированный си-парсер. Т.е. дело не в си, а в том, как этот парсер описан в большей мере. На деле это намного хуже, чем звучит. Но довольно эфективно, этого не отнять.
Там грамматика для бизона, насколько я понимаю
Дело и в криворуких кодерах, которые в парсере использовали signed int, а в track_set_index не добавили проверку "i >= 0". И в сишке, которая не проверяет выход за границы массива.
> Это в стиле противосишников – изобретать своё уникальное решение на каждую задачу, уже реализованную на Си...
> Для преобразования строки в число используется функция atoiтут как раз свой велосипед был бы к месту, я даже сейчас её не использую (в Go)
C 76.5%
Не удивительно. Типичное integer overflow.С ядерным Ганди, это было веселее, а тут как-то грустно((
Ядерный Ганди это придуманная байка вроде
Да, возможно веселая придуманная байка.
А это реальная невеселая уязвимость.Причем ошибка детская (обе ошибки, архитектурная с выбором типа и пропущенная проверка).
Можно было бы попробовать включать -ftrapv или -fwrapv хотя бы в дебаге и тестах.
Но вторая опция кажется не очень надежная, а тесты надо делать fuzzy...
В общем задача совсем не тривиальная ((
Написать свою реализацию Increase/Decrease? Да не, мы пару тактов процессора сэкономим.
Нафига они вообще использовали int для INDEX?
Разве cue sheet допускает там отрицательные индексы?
Чем им unsigned не подошел?
Ошиблись. Идеальных разработчиков не бывает. Кто-то чаще лажает, кто-то реже.
Проблема в языке, который позволяет такие примитивные ошибки
Так водителей всех идеальных тоже не бывает.
Зато как получат штраф в 5-10% от средней зарплаты, сразу улучшаются навыки и распознавания знаков, и внимательность для всех цветов светофоров.Но да, заборчики отделяющие проезжую часть от тротуара тоже важны.
Чтобы устанавливать штрафы, нужно начать платить зарплату тем, чей код бесплатно используешь. А кому это надо?
Так многим и платят, посмотри сколько разрабов ядра и других крупных проектов на зряплате корпов.Но ты прав, штраф тут не помогут.
А вот введение каких-то правил... Что-то типа мисры, но не настолько сложное.
Или внедрить проверки на этап компиляции.Например
- Каждая с либа которая используется в нашем проекте должна проходить Valgrind или другой стат. анализатор
- Если собираем Clangʼом используем -fcatch-undefined-behavior для тестов
- Для CI крутим разные стат и fuzzy тестыНо это реально сложно(
Тем не менее, использование signed int налево и направо — ужасно плохая практика. Это только вопрос времени, когда она вылезет где-нибудь боком.
я наоборот использую signed даже где будет только unsigned, чтобы потом наоборот в ожидаемое unsigned не залетело signed. благо 64 бит хватает, в отличие от 32.
Но ты же добавляешь проверки, что значение не отрицательное перед использованием? Правда же?
Разумеется. Особенно после того как стал работать на Go - там эти бесячьи проверки порой 80% строк функции
> благо 64 бит хватает, в отличие от 32Воот, лень про это было писать: в 16-битную эпоху ещё экономили, в 32-битную расслабились, а теперь и вовсе…
Иногда signed int используется для того чтобы положительным результатом вернуть значение, а отрицательным код ошибки. Иначе придется возвращать значение через указатель. Компиляторы кстати могут предупреждать о преобразованиях:
test.c:9:14: warning: conversion to ‘uint32_t’ {aka ‘unsigned int’} from ‘int32_t’ {aka ‘int’} may change the sign of the result [-Wsign-conversion]Кто бы еще за этим следил бы. Обычно наоборот включают блокировку таких сообщений.
> Иногда signed int используется для того чтобы положительным результатом вернуть значение, а отрицательным код ошибки.Вот за это сишников надо не то что убивать, а пытать бесконечно.
Значение должно использоваться для того, чтобы вернуть значение, И ВСЁ.
Но нет, они же до сих пор полтора регистра и десять байтов памяти экономят.
Не все сишники пишут под x64_86 и не то чтобы было большой проблемой проверить на >0 и привести к нужному типу. Ну и не все представляют, что завтра его либа станет использоваться в миллионе проектов ее использование расширится за пределы заложенные разработчиком.
Ну и есть люди, которые портируют не разбираясь в вопросе. К примеру кто-то написал драйвер датчика i2c под arduino, а следом кто-то пишет модуль ядра linux.
> Не все сишники пишут под x64_86 и не то чтобы было большой проблемой проверить на >0 и привести к нужному типу.Это совершенно не важно, подо что они пишут. Передача кода ошибки (и самого факта ошибки) в результатах вызова функции — это даже в ассемблере 8086 было экономией на спичках (и в нормальных языках не использовалось).
У нас есть куча регистров. У нас есть миллион мегабайт памяти (которую мы бездарно транжирим). Но в бутылочное горлышко eax (ax, rax) мы постараемся протащить всё!
> Но нет, они же до сих пор полтора регистра и десять байтов памяти экономят.Ага, а потом вот такие "программисты" пишут жирный код и "десять байтов" накапливаются по всему кода в разных частях, затем в разных программах и тд. А потом удивляемся чего это новые программы столько жрут при том же функционале.
проблема в электричестве, которое питает железо, позволяющее выполнять машинные инструкции без проверки границы буфера
Ты не поверишь, но да, бывают - в особенности встречаетсая на дисках с непрерывным переходом из одного трека в другой.
Вы обратили внимание сколько сервисов надо остановить чтобы это отключить? Systemd развращает и поощряет, если ты сделал софтину и не создал для нее 15 сервисов, то потратил время зря. С баш-портянками никто такого бы не наворотил. Ну если и наворотил, то оно само по себе сломалось бы.
Так это же unix way для каждой мелочи делать свою программуWrite programs that do one thing and do it well.
Так и тут, каждый сервис делает что-то одно.
> Write programs that do one thing and do it well.Вот именно, что well.
Ну а сейчас есть одно системпшшш, которое портянками юнитов делает не well.
Этот unix way для каждой мелочи делать свою программу как то не довел до добра сам Unix.
> Эксплоит стабилен в работену хоть что-то стабильно и работает!
Почему они tracker-miner в bwrap не завернули, как thumbnailer?
Я думал, это в винде такая порочная мода, пихать паразитные фоновые задачи живущие своей жизнью и жрущие, а оказывается в линуксе то же самое. По умолчанию индексатор, ха, даже еще CUE-файлов, господи, зачем? Ха-ха-ха.
Предварительный индекс ускоряет поиск файлов. Так делают и в Gnome (tracker), и в KDE (baloo), и в Винде (как минимум с Vista).
И, традиционно, это первые кандидаты на отключение.
Чел, спасибо что ты есть. Столько телеметрии поставлено, и для чего? Им будто плевать на пользователя.
да, отключение baloo и аналогов в винде не только освободили мне до трети ЦПУ после загрузки, но и продлило жизнь ПЗУ.
Помню как этот гном трекер наглухо подвешивал систему при закачке фильмов на hdd.
Он пытался сканировать недокачанные файлы, получал где-то ошибку (файл-то еще не готов) и потом повторял зановоБесконечный доступ к медленному диску блокировал все остальные операции, и при этом он в цпу себе не отказывал и жрал под 90%.
Чтобы ты ввёл только слово, и сразу нашлось.
А не как в Windows XP — смотри на собачку 🐕Тоже самое и касается и превьюшек файлов, с которыми несколько раз находили уязвимости в линуксах. Выполняются сами.
Такое больше десяти лет.
Всегда отключаю эти «супер-пупер-интеллектуальные» фоновые индексации.
Лучше я посмотрю на собачку пару минут, чем компьютер будет тормозить остальные 24 часа.
Нормальный индексатор просканирует диск один раз и успокоится. Но это если нормальный.
А где вы нормальные-то видели? В винде то же самое.
А что не так в винде? Там он действительно один раз просканировал и норм.
Ага, скачал новую собачку - и заверте- Простите, счас у всех ССД, они не вертятся (
"Заткнись с*ка, я сам знаю что мне делать с моими файлами."(c) Вряд ли большинству линуксоидов нужна функция мгновенного поиска везде и во всем. Если нужен поиск чего-то конкретного, то они либо заранее продумают как разместить файлы чтобы их было просто искать. либо напишут или подберут свою систему индексации, что будет в 100 раз эффективнее "универсальной системы". Вот я несколько лет назад писал систему индексирования почтовых архивов, где среди нескольких миллионов писем нужно было найти письма отправленные и полученные неким пользователем. И не то чтобы прям так сложно .eml распарсить.
Мне просто абзац как нужна. Правда, не по содержимому, а по именам, но в линуксе и того нет, убогий fsearch ни разу не замена everything.
fzf вполне быстро ищет
Удивительно!!!
На днях на компе к которому подключаюсь ssh (раньше был десктопом) посмотрел какие процессы запускаются у пользователя. О ужас!
Пришлось сносить всякий shit!
А сегодня такая новость. АААААА, они за мной следят!!!!!!!1111111ААААААА
Я этот tracker-miner забыл с какой версии убунты в обязательном пришибаю при установках и dist-upgrade. Просто потому, что польза от этой индексации околонулевая, а ресурсов оно отжирает при каждом запуске, как свинолошадь.
Смысла во всех этих индексёрах, построителей превьюшек и кучи всего остального "удобного", строго нулевая. А тут ещё и дырявая. Я, конечно, понимаю что ошибаются все, но это блин текстовый файл - как можно одырявится, при работе с текстом. Это что ж тогда с бинарными происходит?!Может действительно только хруст спасёт от расстрелов? +)
Не спасет. Были уже там и косяки с разбором аргументов, и выедание всей памяти, когда память под разбор HTTP-запроса выделяли по "Content-Length". Уйдут только проблемы с памятью, и то не факт, учитывая что на 100% все не перепишут, а так и будут тягать сишные библиотеки через unsafe. А даже если и перепишут, то всегда останутся узкие места, где для ускорения потребуется код на С или ASM. То же самое и к go относится.
> А даже если и перепишут, то всегда останутся узкие места, где для ускорения потребуется код на С или ASM.Процессоры по пять гигагерц, но у погромистов по-прежнему узкие места для обработки строк. Ну и не только.