Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Уязвимость в Glibc, затрагивающая статически собранные suid-файлы с dlopen"	+/–
Сообщение от opennews (??), 20-Май-25, 00:35
В стандартной Си-библиотеке Glibc выявлена уязвимость (CVE-2025-4802), позволяющая добиться выполнения кода с привилегиями другого пользователя, выставляемыми при запуске приложений с флагом suid. Опасность проблемы сводят на нет условия при которых она проявляется - разработчики Glibc на смогли найти не одной suid-программы к которой была бы применима найденная уязвимость. При этом не исключено, что в обиходе могут использоваться собственные suid-прогрммы, удовлетворяющие условиям совершения атаки... Подробнее: https://www.opennet.me/opennews/art.shtml?num=63269
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 20-Май-25, 00:35	+5 +/–
когда уже выпилят этот сломанный статический nss и dlopen? Он никогда не работает и только проблемы создаёт, Обычно бинарники собирают статически не чтобы из них dlopen делать. Статический ffmpeg на дебиане вообще сегфолтится при попытке ресолвинга, очень полезно!!!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8, #17, #49

2. Сообщение от Аноним (-), 20-Май-25, 01:36	+12 +/–
> затрагивающая статически собранные suid-файлы с dlopen А теперь коронный номер - поза "фантомас в очках на аэроплане".
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #26

3. Сообщение от Xasd9 (?), 20-Май-25, 03:26	–12 +/–
лучше бы запретили бы статическую сборку и не е***и бы мозги
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #11, #13, #19

4. Сообщение от Аноним (1), 20-Май-25, 04:10	+4 +/–
зачем, когда можно её починить, а не пихать туда сомнительные вещи?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

8. Сообщение от openssh_user (ok), 20-Май-25, 07:51	–1 +/–
Можно пример, на каком моменте вы ловите segfault?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #10, #42

10. Сообщение от fi (ok), 20-Май-25, 09:26	+1 +/–
Это известный баг - когда nss от другой libc -  такое блюдо надо уметь готовить. Но что странно - так то что ссылаются на 2017-12-19  Dmitry V. Levin  <ldv@altlinux.org>         * elf/dl-load.c (is_trusted_path): Remove.         (fillin_rpath): Remove check_trusted argument and its use,         all callers changed. кто-то внес "оптимизацию" )))))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #36

11. Сообщение от adolfus (ok), 20-Май-25, 09:34	–3 +/–
Статическая сборка хороша тем, что приложение использует меньше физической памяти и работает быстрее. Каждая .so независимо от реального размера загружаемого содержимого требует, минимум, три собственных страницы физической памяти, а статическая ровно столько, сколько занимает сама библиотека. Первый вызов функции из .so требует некоторого дополнительного времени на некотороые системные действия, что особенно заметно в интерактивных приложениях, котороые во время инициализации интерфейса выполняют десятки вызовов. Выглядит это как тормоза и достигают эти тормоза нескольких секунд.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #12, #14, #15, #28

12. Сообщение от Аноним (12), 20-Май-25, 09:57	+6 +/–
> приложение использует меньше физической памяти Не неси чушь. SO либы в юнискосых системах расшарены, т.е. библиотека загружается ровно один раз даже если ее использует 100 программ. В отличие от статической линковки, лол. > некоторого дополнительного времени > некотороые системные действия А, сори, у нас тут эксперт в треде. Чему я удивляюсь...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #22

13. Сообщение от Аноним (34), 20-Май-25, 10:47	+1 +/–
Спасибо, для статической сборки уже нужен musl.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

14. Сообщение от Соль земли2 (?), 20-Май-25, 10:56	+4 +/–
> Статическая сборка хороша тем, что приложение использует меньше физической памяти и работает быстрее. Извиняюсь, но как раз динамическая сборка нужна, чтобы динамический линковщик при открытии библиотеки взял уже загруженный в shared памяти файл библиотеки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #50

15. Сообщение от Аноним (15), 20-Май-25, 10:57	–1 +/–
Статическая сборка хороша как минимум тем, что приложение будет более-менее гарантированно работать, вот это её главный плюс. Идея разделяемых библиотек в линуксе с треском провалилась, в винде оно как-то криво-косо, но работает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #16, #44, #51

16. Сообщение от Аноним (12), 20-Май-25, 11:37	+7 +/–
> Идея разделяемых библиотек в линуксе с треском провалилась "Но шмель об этом не знает и продолжает летать..."
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #18, #20

17. Сообщение от Аноним (17), 20-Май-25, 11:50	+1 +/–
Удивительно что для статической сборки кто-то использует glibc, разве это не киллер фичи компактных реализаций uclibc и musl.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #43

18. Сообщение от Аноним (15), 20-Май-25, 12:12	+1 +/–
Да, до момента появления сообщения «у вас .so версии 2.11, а нужно 2.10» (или наоборот). Снапы с флатпаками от хорошей жизни выросли, видимо?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #21, #46

19. Сообщение от OpenEcho (?), 20-Май-25, 12:18	+/–
> лучше бы запретили бы статическую сборку и не е***и бы мозги Подрабатываете в НСА ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

20. Сообщение от Аноним (-), 20-Май-25, 12:25	+/–
> "Но шмель об этом не знает и продолжает летать..." Да-да, особенно когда на каком-то копродистре вроде деба тебе срочно нужно обновить что-то чтобы исправить бесячий баг или дыру, а дебилианцы не считают это проблемой. И вот тогда начинается веселье.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

21. Сообщение от Аноним (21), 20-Май-25, 12:25	+2 +/–
В Линуксе без проблем поставить рядом 2.10 и 2.11, без хелла.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #24, #29

22. Сообщение от Аноним (-), 20-Май-25, 12:28	+3 +/–
> библиотека загружается ровно один раз даже если ее использует 100 программ. Зато с статической линковкой работает LTO. А с шареными либами - нет. Нужно ли lto или лучше пару мегабайт сэкономить - каждый решает сам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #23, #41, #47

23. Сообщение от Аноним (12), 20-Май-25, 12:32	+/–
> Зато с статической линковкой работает LTO. А с шареными либами - нет. Ну как бы логично, нет? На то они и шареные.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #25

24. Сообщение от Аноним (15), 20-Май-25, 12:37	+1 +/–
Во-первых, и с хелпом проблема. Во-вторых, уже в этот момент концепция разделяемых библиотек похерена.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

25. Сообщение от Аноним (-), 20-Май-25, 12:48	+/–
> Ну как бы логично, нет? На то они и шареные. Конечно логично, я же об этом и написал. Но то, что оно не пашет это недостаток этого самого шаренья. Просто все так расписывают преимущества shared libs, как будто у них нет недостатков. А вот мне не жалко небольшого увеличения размера аппы ради небольшого увеличения производительности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #31

26. Сообщение от Жироватт (ok), 20-Май-25, 13:58	+3 +/–
Скорее уж "Товарищ милиционер, а вот если залезть на шкаф и воооот така вооооот выгнуть восьмёркой шею, то можно увидеть в бинокль голых девок в бане на том конце улицы! Примите меры!".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

28. Сообщение от Аноним (34), 20-Май-25, 14:12	+/–
>Выглядит это как тормоза и достигают эти тормоза нескольких секунд Эм, а какого года выпуска у вас железо? >что особенно заметно в интерактивных приложениях Интерактивные приложения постоянно что-то вызывают. Очень маловероятно, что приложение с нуля загрузится в память целиком, со всеми иконками библиотеками и прочим >котороые во время инициализации интерфейса выполняют десятки вызовов Почему десятки? Вот смотрите, типовой современный сайт на php вызывает тысячи, может даже десятки тысяч файлов на один запрос. И вы всех этих тысяч файлов не увидите, для вас это займёт ну может сотню милисекунд. Так почему десктопные приложения у вас тогда тормозят несколько секунд?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #33, #52

29. Сообщение от Аноним (34), 20-Май-25, 14:14	+/–
Только в nixos и guix sd. Во всех остальных случаях начинаются танцы с контейнерами, и прочим и прочим
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #32

31. Сообщение от Аноним (31), 20-Май-25, 14:37	+1 +/–
Если логика вашей программы настолько сильно упирается в скорость вызова какой-то функции из другой библиотеки, а не в IO, например, то либо статично компилируйтесь с этой библиотекой, либо чините компиляцию / меняйте компилятор.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #34

32. Сообщение от Аноним (31), 20-Май-25, 14:43	+/–
Спешу вас расстроить, достаточно компилировать програмы с более точной версией библиотеки, которая вам нужна, а не "о, новая фича в 2.16, но всё равно буду линковаться с libcrap-2.so". Ничто не мешает положить в систему обе версии файла. На крайняк можно через переменные окружения в другую папку настроить (если бинарь нет возможности перекомпилировать правильно), либо и правда другой mount namespace сделать, если и так хотите заизолировать что-то.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #35, #37, #45

33. Сообщение от Аноним (31), 20-Май-25, 14:44	+/–
Человек наверное под виндой сидит, где кэш файловой системы по ощущениям постоянно выключен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

34. Сообщение от Аноним (34), 20-Май-25, 16:57	+/–
>Если логика вашей программы настолько сильно упирается в скорость вызова какой-то функции из другой библиотеки, а не в IO, например, то либо статично компилируйтесь с этой библиотекой Так не пойдёт. Байты всё равно надо откуда-то прочитать. Количество байт от метода линковки зависит слабо, и условный бинарник на 100 Мб всё равно не будет прочитан мгновенно, по сравнению с динамически слинкованным
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

35. Сообщение от Аноним (34), 20-Май-25, 17:01	+/–
О титан, не слишком ли тяжёл небосвод, не устал ли его держать? Согласен, что сделать можно, только мало кто делает. Тот же appimage у меня из коробки не запустился, так как какой-то библиотеки у меня не оказалось. Хотя казалось бы
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

36. Сообщение от Аноним (36), 20-Май-25, 18:50	+/–
Левин небось за это повышение получил. Может даже старлея дали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #38

37. Сообщение от Аноним (36), 20-Май-25, 19:06	+/–
> На крайняк можно через переменные окружения в другую папку настроить И насколько хорошо это работает мы можем посмотреть в том числе и по сабжевой новости. И нет, проблемы танцевать красиво с «другими папками», неймспейсами, небом и аллахом нет. Проблема есть в том, что эти танцы надоели ещё пятнадцать лет тому назад, если не все двадцать, и судя по набирающим популярность флатпакам, аппимиджам и снапу — не только мне одному.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

38. Сообщение от Аноним (38), 20-Май-25, 20:06	+/–
Так он её выпилил как раз потому, что она нигде не используется. Очень похоже, что кто-то с помощью нейросетки пытается поднять себе KPI, внося тормоза в нормальный код.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

41. Сообщение от adolfus (ok), 20-Май-25, 22:23	+1 +/–
Ничего вы по памяти не сэкономите. Загруженная ранее .so будет отображена полностью в ваше адресное пространство, даже если вы из нее используете маленькую функцию. Это в отношени кода. Плюс у вас будет отображение секций инициализированных данных и неинициализированных, даже если функция, которую вы вызываете, их не использует. Именно поэтому вместе с .so нормальные пакеты предоставляют .a, собранные из мелких объектных модулей, ни на какие другие не ссылающиеся. Это для тех, кто понимает, что такое динамическое связывание и чем оно отличается от статического. Я пишу, в основном, математику и если заказчик не возражает, использую gsl, которую сам компилирую и собираю как в .so, так и в .a, так что разницу в призводительности и в отношении свободной памяти в куче (malloc) чувствую непосредственно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

42. Сообщение от Аноним (42), 20-Май-25, 23:22	+/–
~$  /usr/lib/x86_64-linux-gnu/libc.so.6 GNU C Library (Debian GLIBC 2.36-9+deb12u9) stable release version 2.36. Запустить  ffmpeg-7.0.2-amd64-static отсюда: https://johnvansickle.com/ffmpeg/ и попытаться сделать любой сетевой запрос, как-то связанный с nss, например подать ссылку с любым доменом на вход приводит к сегфолту. На других версиях обычно был не сегфолт, а просто ресолвинг не работал. Претензия в том, что в статический билд вообще попадает динамическая загрузка nss. Вместо этого должен быть либо стаб, либо фоллбэк, поддерживающий какую-то минимальную конфигурацию
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #53

43. Сообщение от Аноним (42), 20-Май-25, 23:24	+/–
В посте выше ссылка на сайт со статическими билдами и там зачем-то glibc (а помимо прочего ещё и x11 влинкован).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

44. Сообщение от Аноним (42), 20-Май-25, 23:28	+/–
и там гарантированно не будет работать ресолвинг
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

45. Сообщение от Аноним (42), 20-Май-25, 23:32	+/–
Пакетные менеджеры мешают т.к не умеют ставить одновременно 2 разных минорных весрии. В gentoo это кое-как решается preserved-libs, но он используется только в случае обновления библиотеки на более новую. Рач же сносит старую библиотеку при обновлении даже когда она используется, сводя всю ценность линковки к точной версии на нет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

46. Сообщение от Аноним (42), 20-Май-25, 23:36	+/–
Снапы с флетпаками выросли сугубо от хорошей жизни менеджера, который ничего лучше не смог придумать. Впрочем, линковка к точной версии библиотеки не спасёт от конфликта символов внутри процесса. Если в windows линковка происходит к dllname.dll:funcname, то в линуксах просто к funcname или в лучшем случае к funcname:SYMVER... что не исключает возможности как одинаковых funcname, так и одинаковых funcname:SYMVER в разных процессах...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

47. Сообщение от Аноним (-), 21-Май-25, 00:26	+/–
> Зато с статической линковкой работает LTO. А с шареными либами - нет. > Нужно ли lto или лучше пару мегабайт сэкономить - каждый решает сам. Как бы тебе сказать то? Вгрузить в RAM 10 инстансов кутей, допустим, никак не пару мегабайт экономии будет. Вот 200 мегов RAM - это еще может быть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

49. Сообщение от Аноним (49), 21-Май-25, 11:34	+/–
> когда уже выпилят этот сломанный статический nss и dlopen > разработчики Glibc не смогли найти ни одной suid-программы, к которой была бы применима найденная уязвимость когда начнут находить, тогда может кто и профинансирует выпиливание.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

50. Сообщение от adolfus (ok), 23-Май-25, 13:49	+1 +/–
>> Статическая сборка хороша тем, что приложение использует меньше физической памяти и работает быстрее. > Извиняюсь, но как раз динамическая сборка нужна, чтобы динамический линковщик при открытии > библиотеки взял уже загруженный в shared памяти файл библиотеки. Динамическая сборка годится только тогда, когда общая библиотека используется несколькими программами и в этом случае память, возможно, экономится. Кто-то первый загрузил и остальные уже используют загруженное, отображая библиотеку в свое адресное пространство. "Единоличное" же использование общих библиотек одним приложением не имеет особого смысла, поскольку кроме этого приложения никакое другое этими библиотеками пользоваться не может и этому приложению в любом случае придется всякий раз их загружать и привязывать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

51. Сообщение от adolfus (ok), 23-Май-25, 13:57	+/–
> Статическая сборка хороша как минимум тем, что приложение будет более-менее гарантированно > работать, вот это её главный плюс. Идея разделяемых библиотек в линуксе > с треском провалилась, в винде оно как-то криво-косо, но работает. В никсах нет "разделяемых" библиотек, но есть совместно используемые объекты (shared object), которые иногда называются "общие библиотеки".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

52. Сообщение от adolfus (ok), 23-Май-25, 14:34	+/–
>[оверквотинг удален] > Эм, а какого года выпуска у вас железо? HP Zbook c 32 Гбайт ОЗУ и ПП-диском. >>что особенно заметно в интерактивных приложениях > Интерактивные приложения постоянно что-то вызывают. Очень маловероятно, что приложение > с нуля загрузится в память целиком, со всеми иконками библиотеками и > прочим >>котороые во время инициализации интерфейса выполняют десятки вызовов > Почему десятки? Вот смотрите, типовой современный сайт на php вызывает тысячи, может > даже десятки тысяч файлов на один запрос. Сайт кеширует в памяти содержимое всех этих мелких файлов и выгружает их только тогда, когда нужно освободить физическую память под более насущные задачи. По крайней мере, кешируются все индексы, мелкие таблицы, типа LUT ("справочники") и все страницы баз данных, к которым были недавние обращения, если они "не мешают". > И вы всех этих тысяч файлов не увидите, для вас это займёт ну может сотню > милисекунд. Так почему десктопные приложения у вас тогда тормозят несколько секунд? Они у всех на старте (речь именно об этом, не так ли?) тормозят. Просто померяйте, сколько времени у вас загружается libreoffice writer с пустым файлом ($ libreoffice --writer) без предзагрузки .so и и с их предзагрузкой (второй запуск $ libreoffice --writer)? Вот разница и будет тем временем, которое требуется на загрузку и привязку всех требуемых .so. Второй запуск у меня занимает менее секунды в отличие от первого, который в зависимости от того, что в данный момент работает (например, maple считает, используя всю доступную память), может составлять до 20 секунд. Также десктопные приложения, использующие динамическую сборку меню, панелей и прочих виджетов, всегда тормозят, поскольку процесс компиляции описания, сборка, инициализация, рендеринг файла отрисовки и отрисовка стартует не при загрузке приложения, а при первом обращении и занимает времени гораздо больше, чем просто отрисовка команд из готового файла, сформированного в случае статического интерфейса, и полностью подготовленного к работе в процессе связывания приложения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

53. Сообщение от fi (ok), 28-Май-25, 10:15	+/–
это вопрос к сборщику  ffmpeg, есть и libnss_*.a Я решал эту проблему через chroot - но то был демон, ему было полезно.  Не видит .so , то и не грузит. возможно правка /etc/nsswitch.conf поможет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема