В библиотеке отрисовки шрифтов...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62875
А когда добавили? В прошлый раз была уязвимость с шрифтами в формате png. Так теперь и не отключить png во freetype стало.
Хороший вопрос... Ибо вариативные шрифты придумала в 2016 году группа компаний Adobe, Apple, Google и Microsoft.
Хорошие компании
> вариативные шрифты придумала в 2016 году группа
> компаний Adobe, Apple, Google и Microsoft.Ужасные компании!
Мало того что платиновые спонсоры линукс фаундейшн, так еще умудяются наложить в штаны freedesktop'у, создавая стандарты который фридесктопчики ниасиливают!
Подбросили CVE вот так прямо в их репозиторий!
это пять!
Никогда такого не было и вот опять
Заходя в эту новость, я уже предвкушал, что тут будет переполнение буфера.
Пора это уже в спецификации языка Си указать, что буфер -- это то, за пределы чего должен выйти любой уважающий себя сишник. Закрепить, так сказать, официально этот стандарт де-факто.
> из-за присвоения переменной с типом "signed short",
> участвующей в вычислении размера буфера, значения с типом "unsigned long"Просто диды - мастера не только в индексах, но и в преобразованиях типов которые сами себе напридумывали в т.ч ради экономии на спичках, точнее, отдельных байтах
freetype-2.13.1-1.fc39
created a year ago for Fedora 39какой смысл писать про такие древности?
Любители дебиана уже дуреют с 2.12.1+dfsg-5+deb12u3 прикормки.
Точно подмечено
таки и не все на 12-ом (!)
2.10.4+dfsg-1+deb11u1 all
Всего год? В генту уязвимая 2.13.0 до сих пор стабильная. А теперь представь сколько софта тащит только эту версию (и сколько более старые), у нас же деды-специалисты говорят обновляться стыдно и в то же время юнцы-специалисты топят за статическую линковку или как минимум таскать всё бандлом.
не нада ля-ляв генту зеленое 2.13.3
> не нада ля-ля
> в генту зеленое 2.13.3все 3 зелёные (2.13.0 2.13.2 2.13.3), крайне странное решение.
ну может зависимости какие, каким-то пакетам нужны устаревшие версии.
Причём, 2.13.3 уже почти год без обновлений, хочешь свежей собирай из гита и софт к этому может весьма плохо отнестись. Ситуация довольно патовая, ключевая либа такая дохлая -- одни уязвимости добавляют по мере надобности.
Дарка от бублика наш линукс злосчастный.
К тому же, если учесть, что код всем открыт. Чем там все кичатся.
Кто бы что ни говорил, но зачастую это банальный кактус, который мы с ехидной улыбкой, как у 20-летних заносчивых супэраутишников, жуём все вместе.
Ну.. жуём дальше господа ))
Согласен, надо ставить проприетарную Solaris от Oracle.
лучше такой же астра линкус
там манда ты
>>код всем открыт. Чем там все кичатся.Странный повод, чтоб кичиться. Ведь благодаря открытому коду любой школьник может прочитать diff закрытия свежей уязвимости и по быстрому написать зловред для тех, кто ещё не успел обновиться.
Не любому это надо, у кого-то и детство есть.
Cчастливые люди, приятно слышать что такие ещё остались.
Ну да, в проприетарных ОС-подобных поделиях уязвимости просто никто не ищет, поэтому там их количество постоянно растёт.
> Amazon Linux 2, Debian stable / Devuan, RHEL 8 и 9Вся суть "стабильных" дистрибутивов.
А что не так? Стабильные дистры затаскивают и бекпортируют себе фикс уязвимостей. Стабильные дистры не тащат новые фичи, которые ломают поведение библиотек/программ.
> Стабильные дистры затаскивают и бекпортируют себе фикс уязвимостей.Ну-ну. Проблема была исправлена еще в 2023 году.
А сейчас на календаре 2025й, но окаменевший деб все еще уязвим
security-tracker.debian.org/tracker/CVE-2025-27363Вот где бекпорт??
Дак выявили проблему в этом году. Как они могли себе фикс бекпортировать, если проблема еще не была обнаружена?
> Дак выявили проблему в этом году.Проблемы выявили и исправили еще в 2023. Просто тогда не осознали насколько она проблемная.
> Как они могли себе фикс бекпортировать, если проблема еще не была обнаружена?
Но из-за того, что некродистры не забирают фиксы обычных багов, а только тех, которые оценили как критику, то естественно ее никто не забирал.
Причем для нормальных дистров это проблемой не стало - они просто обновились и забыли.В итоге в шта6ильных сурьезных дистрах типа RHEL9 дырень прожила на полтора года дольше чем во всяких рачах и бубунтах
Ты не бойся, в рачах уже четыре новые слопатили)
> Дак выявили проблему в этом году. Как они могли себе фикс бекпортировать, если проблема еще не была обнаружена?Обновившись до актуальной версии, прикинь.
> А что не так? Стабильные дистры затаскивают и бекпортируют себе фикс уязвимостей.Не так то что ничего они не затаскивают и не бэкпортируют, как иллюстрирует этот случай. А просто злонамеренно держат в репах тухлые дырявые версии.
Я забыл, дум уже запустили в шрифте или мне приснилось?
GTA запустили
https://fuglede.github.io/llama.ttf/
Разрабы freetype просто не умеют писать на сишке, вот местные комментаторы никогда бы не допустили такого бага.
> до версии 2.13.0 включительно и устранена в версии 2.13.1 (июнь 2023 года).А что за некронвости такие!?
freetype2-2.13.3 уже стоит из портов.
Опять у растовиков обострение и пообщатся захотелось?
> А что за некронвости такие!?Обычные некроновости для некродистров вроде Debian stable / Devuan, RHEL 8 и 9 и так далее.
Потому что исправлено оно было в июне 2023 года, но не помечено как CVE.
Поэтому бекпорта не было.> Опять у растовиков обострение и пообщатся захотелось?
О чем тут общаться? Типикал сишная дыра, никогда такого не было и вот опять.
А вот предупредить некролюбов что нужно обновиться - это доброе дело.
> А вот предупредить некролюбов что нужно обновиться - это доброе дело.Скорее всего систем со старой либой где шрифт с эксплоитом можно загрузить и "заюзать" единицы, они не представляют интереса, если только в таргетированных атаках.
все корпоративные дистры со старыми либами
Годно. Теперь код необязательно запускать, достаточно открыть его в редакторе, чтобы произошел взлом.
Достаточно открыть страничку в интернете без дефолтной блокировки шрифтов ublock. Будь готовые прототипы в паблике, можно было бы использовать их их для обхода цифровой тюрьмы¸а так ничего хорошего.
Раньше было лучше (с)
В 2020 у них была 0-day дырень [1], которая мало того что активно эксплуатировалась.
Так еще и работала через браузер (хром и лиса).
И работала на андроиде.Вот это уровень!
[1] opennet.ru/opennews/art.shtml?num=53922
Перед этим правдва надо установить нужный шрифт, и вот потом уже да.
Если это жадность до ОЗУ, то это необоснованно, т.к. в 32 битных системах переменная всё равно по факту займет 32 бита (если не извращаться, и к массивам не относится), а в 64-битной - 64. Более того, если говорить о микроконтроллерах с Cortex M, то там в некоторых случаях придется дополнительно выполнить команды SXTB, SXTH, UXTB и UXTH при операциях с меньшими по разрядности типами.
> т.к. в 32 битных системах переменная всё равно по факту займет 32 бита (если не извращаться, и к массивам не относится), а в 64-битной - 64Да ты что.
Прикинь, в ОЗУ Cortex M0 оно так по умолчанию.
> в 32 битных системах переменная всё равно по факту займет 32 битаДа ладно? Так уж и займёт 32 бита?
Попробуй такое:
struct test {
char a;
char b;
char c;
char d;
};struct test var;
assert!(sizeof(var) == 16);
Отметь, это не массив нисколько.
> в некоторых случаях придется дополнительно выполнить команды SXTB, SXTH, UXTB и UXTH при операциях с меньшими по разрядности типами.
Ага. Это ты ещё не видел как битовые поля распаковывают в представление, над которым затем можно выполнять осмысленные операции.
Выравнивание подобной структуры, если об упаковке явно не указано, зависит и от платформы, и от уровня оптимизации, и конкретного компилятора.>>Ага
Полагаться на то что выдал sizeof - некорректно.
Ваше утверждение тоже неверное.
Правильный ответ: неопределенный размер. Хотя и с большой вероятностью 32 или 128 бит, но не конкретное значение.
> Ваше утверждение тоже неверное.Какое утверждение? Где и что я утверждал? Вы assert сочли "утверждением"? Это не утверждение, это часть кода, которую я предлагал скомпилировать и посмотреть, что выйдет.
> Выравнивание подобной структуры, если об упаковке явно не указано, зависит и от платформы, и от уровня оптимизации, и конкретного компилятора.
Да-да.
> Полагаться на то что выдал sizeof - некорректно.
Из предыдущей цитаты вас, я могу утверждать, что неверно полагаться на то, что любое значение будет занимать 32 бита, потому что реально это будет зависеть от "выравнивания подобной структуры, ... бла-бла-бла".
> Правильный ответ: неопределенный размер.
Это не совсем правильный ответ. Одно из свойств C, которое делает его незаменимым везде, это фиксированный ABI. Да, этот ABI зависит от платформы, но как только мы определились с платформой, так сразу мы можем точно сказать, сколько байт будет занимать вышеприведённая структура. Нам не нужно для этого знать, каким компилятором для данной платформы мы будем пользоваться.
Флагами компилятора можно это всё "испортить", но, кстати, не "флагами уровня оптимизации", потому что ABI должен быть фиксированным вне зависимости от уровня оптимизации: как ты будешь вызывать функции libc, если твой уровень оптимизации меняет layout структур libc? То есть ты такой сказал -O0, для отладки, и у тебя всё сломалось, потому что libc скомпилирована с -O2 или с -Os?
Более того, я вам скажу, что ваш ответ категорически неправильный. Он истинный с формальной точки зрения (хотя бы потому, что мы всегда можем найти компилятор C, который делает не так как все), но он _абсолютно_ _бесполезен_ на практике. С философской точки зрения это банальный нигилизм, отрицание всего по каким-то метафизическим формальным причинам, с положением толстого болта на прагматику.
Таким образом _правильный краткий ответ_: размер структуры вполне определён на каждой платформе, хотя могут быть нюансы.
Более развёрнутый правильный ответ таков. Есть простое правило: alignment члена структуры равно его размеру, округлённому вверх на ближайшую степень двойки (но не больше 4 или 8 байт, в зависимости от битности системы). Таким образом, смещения членов относительно начала структуры будут 0, 1, 2 и 3, потому что alignment char'а 1 байт.
Если вы укажете мне десктопную/серверную* систему в которой это правило не работает, вместо дальнейших пустопорожних рассуждений об абстрактных опциях компилятора, то я буду премного вам благодарен. Мне всегда интересно расширить свой кругозор. А до тех пор, пока вам такую систему найти не удалось, я продолжу следовать этому правилу, располагая поля в своих структурах так, чтобы структура бы занимала минимальный размер, не упираясь в проблемы с unaligned access. Собственно то правило выше, можно переформулировать в ещё более прагматичной форме, которая прям инструкция к действию: самый простой способ минимизировать размер структуры, не сталкиваясь с ограничениями packed структур, это располагать поля в структуре в порядке уменьшения их размера.
*) эмбедщина не интересна, там свои правила, там даже соответствие в граните отлитым стандартам C весьма условно. Там уже у каждой зверюшки свои погремушки, каждая железка требует отдельного изучения особенностей архитектуры и компилятора.
> Хотя и с большой вероятностью 32 или 128 бит, но не конкретное значение.
Что значит "не конкретное значение"? Мне не понятно это ваше заявление, равно как и ваш отказ полагаться на то, что говорит sizeof: sizeof специфически говорит о том, сколько структура занимает места в памяти (не считая padding'а после неё, который может добавляться с тем, чтобы выдержать alignment других объектов в памяти). Что вы вообще хотели сказать этим? Я вот гадаю, и единственное объяснение, которое мне приходит на ум, это то, что компилятор может хранить эту структуру распакованной в четырёх регистрах. Он запросто может проделать такое в процессе оптимизации. Распаковать из RAM в регистры, поработать с ними, потом упаковать обратно в RAM, если компилятору покажется, что это будет быстрее, чем каждый раз обращаться к индивидуальным полям структуры по адресу. Я полагаю, что и на стеке он может хранить поля этой структуры в любом порядке с любым padding'ом который ему удобно, в конце концов там делали даже ассемблерные программисты во времена DOS, потому что push на стек клал 2 байта, и запушить туда один байт было невозможно. Таким образом, если хотелось освободить регистр, сохранив байт хранящийся там, то на стек летел этот байт расширенный нулями до двух байт.
Но если вы _это_ имели в виду, то это мимо кассы. Речь идёт о layout'е структур в RAM. Аноним выше специфически хотел поговорить об этом. Это не memory layout структуры, это то что делает оптимизатор (человек или алгоритм), когда ему не надо заботиться об ABI: это временное, нефиксированное представление данных, с которым будет работать только локальный код, и оно оптимизировано под этот код.
Если же вы имели в виду что-то иное, то вам следует изложить свою мысль внятно и последовательно.
Да, утверждение не Ваше, лишне я сказал.
Но, в остальном, мы друг друга поняли все равно верно.>>Если вы укажете мне десктопную/серверную* систему в которой это правило не работает
Вы подметили про оптимизацию, а она может быть и под конкретную серию процессоров, и учитывать внутренниие нюансы скорости, особенности кэша..
В общем полагаться на то как уложит структуру компилятор "по умолчанию" в любом случае не стоит.>>эмбедщина не интересна
Сейчас там отличий от десктопного кода все меньше
>>Мне не понятно это ваше заявление, равно как и ваш отказ полагаться на то, что говорит sizeof
Не верно полагаться но именно на то, что sizeof выдаст предполагаемый размер.
А если он проверяется в рантайме, то конечно, ему тогда уже нужно доверять. ;)
> Одно из свойств C, которое делает его незаменимым везде, это фиксированный ABI. Да, этот ABI зависит от платформы🤣🤣🤣🤣🤣
Это капец.
Речь о переменных, а не о полях структуры, помимо массивов. И речь идет о жадности, а на операции с битовыми полями сколько инструкций нужно выполнить?
в очередной раз доказывает несостоятельность разного рода изкоробочных селинуксов и подчеркивает нужность МАСов.
>из-за присвоения переменной с типом "signed short", участвующей в вычислении размера буфера, значения с типом "unsigned long",госпади, на это же все современные компиляторы жалуются.
как это произошло вообще ?
Варнинги отключили. Иначе память при компиляции ими переполнялась.
Гспди, рукалицо, если это правда.
>устранена в версии 2.13.1 (июнь 2023 года)Тю.
ИМХО,
не обращайте внимание, мысли в слух xD
Вам не смешно читать, комменты, "вумных" людей, которые говорят как всё плохо и как надо, и о защите от ошибок программистов... И тем более о Сях как о плохом языке. И из них никто даже близко не берётся подумать что быстрее сей ТОЛЬКО ассемблер с ОЧЕНЬ читаемым кодом и Очень независимыми от платформы командами xD... Си же читабелен, понятен и многое упрощает (хотя и там для специфичных команд платформ юзается асм). И да, только благодаря отсутствию лишних проверок который компилятор возлагает на человека, получается достичь этих скоростей.
Даже одна лишняя проверка в цикле на уровне ядра не в удачном месте может много порезать... А так, ну да, могут писать на языках с кучей проверок на каждый пук и получится производительность как у питона ;D Вот, тогда-то "заживём" будут защищённые ОС от простых ошибок ("Супер скоростные", что тормозить будут на последних рязанях с 128ядрами, а оперативки в 256гб будет мало даже на запуск тетриса xD ), но не от человеческого фактора (x_(x_x(O_o)x_x)_x) И там снова будут ошибки и с нова будут бэкдоры
Так и будет, просто пока бэкдоры и ошибки в коде на русте - это вина погромиста,а вот в сях/крестах - это дырявый язык, понимать надо.
> Вам не смешно читать, комменты, "вумных" людей, которые говорят как всё плохо и как надо, и о защите от ошибок программистов...Неа, к сожалению не смешно.
Когда мой комп могут взломать просто поставив "специальный шрифт" на сайт (прошлая дыра в freetype) - это не смешно.
Когда grub взламывется нажатием backspace 28 раз - это тоже не смешно.
Когда CVE/RCE сыпятся как из рога изобилия - это ваще ни разу не смешно.> И тем более о Сях как о плохом языке.
Он не плохой. Он просто ужасный.
Если автор языка писал "The fundamental problem is that it is not possible to write real programs using the X3J11 definition of C. The committee has created an unreal language that no one can or will actually use."> И из них никто даже близко не берётся подумать что быстрее сей ТОЛЬКО ассемблер
Выбирающий скорость вместо корректности, остается и без первого, и без второго.
> Си же читабелен, понятен и многое упрощает
А еще С99 содержит 192 UB которые в зависимости от платформы, компилятора и даже его версии, фазы луны и астрологического прогноза могут выдавать разные результаты.
#define __is_constexpr(x) \
(sizeof(int) == sizeof(*(8 ? ((void *)((long)(x) * 0l)) : (int *)8)))
#define ICE_P(x) (sizeof(int) == sizeof(*(1 ? ((void*)((x) * 0l)) : (int*)1)))
#define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f))
ʼшидеврыʼ понятности и читабельности прям из ядра линукс> Даже одна лишняя проверка в цикле на уровне ядра не в удачном месте может много порезать...
Например возможность получения рута. Но настоящим пограммистам на такие мелочи побоку.
> А так, ну да, могут писать на языках с кучей проверок на каждый пук и получится производительность как у питона ;D
Если это такой неумелый наброс на раст - то у него проверки во время компиляции.
Если на с++ - то смартпойнтеры не дают такой большой оверхед.> Вот, тогда-то "заживём" будут защищённые ОС от простых ошибок
Например удаленный RCE? Да, это несущественные ошибки, можно на них не обращать внимание.
> ("Супер скоростные", что тормозить будут на последних рязанях с 128ядрами, а оперативки в 256гб будет мало даже на запуск тетриса xD),
Твое умение передергивать и гиперболизировать заслуживает уважения. Мало кто смог бы придумать такое еб---е сравнение.
Но если даже так, то мнение нищуков которые не смогут себе купить новое железо мало кого волнует. Пусть сидят на старых версиях.> но не от человеческого фактора (x_(x_x(O_o)x_x)_x) И там снова будут ошибки и с нова будут бэкдоры
Но их будет меньше. Этого достаточно.
Проекты становятся сложнее. И архитектурно и в коде.
Человеку не надо будет тратить свой ресурс "внимание" на мелочи типа "а какой тут енам" тк ему будет подсказывать компилятор. Следовательно будет больше сил тратить на недопущение логических ошибок.ps. вообще это забавный аргумент "раз мы не можем исправить логические ошибки, то давайте положим болт вообще на все"