Уязвимость Ghost – перекомпиляция программ на C/C++?

У меня есть сервер CentOS 6.0 с glibc-2.12-1.7.el6.x86_64, на котором запущены многие сервисы с открытым исходным кодом и некоторые из моих собственных программ на C.

Чтобы устранить уязвимость ghost, мне нужно обновить его до glibc-2.12-1.149.el6_6.5.

Так как разница в версиях кажется значительной.

Я задавался вопросом, нужно ли мне перекомпилировать мои приложения на C/C++ или даже некоторые из сервисов с открытым исходным кодом?
Как даже протестировать их, потому что протестировать все практически невозможно?

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

Приложения Linux почти всегда используют динамическую линковку с библиотекой C, что означает, что она не скомпилирована в них – она подключается во время выполнения. Это означает, что если вы обновили библиотеку C, вам не нужно ничего больше делать.

Однако, хотя это было бы очень необычно, это не невозможно, чтобы вещи были собраны со статически связанной glibc. Лучше всего просто обратиться к документации для конкретного приложения. Если это так, это почти наверняка будет явно указано.

Вы можете проверить исполняемые файлы с помощью file. Он должен сказать “dynamically linked” в выводе. Я думаю, что все еще возможно, чтобы такой бинарный файл тогда включал статическую glibc – но это было бы невероятно запутанно. Способ двойной проверки будет следующим:

ldd whatever | grep libc.so

Где whatever – это бинарный файл, который вы хотите проверить. Вы должны получить какой-то вывод. Если нет, оставьте комментарий здесь, чтобы я мог съесть свою шляпу, потому что я не верю, что кто-то создаст такую вещь.

Если вы действительно найдете настоящий статический бинарник, это не означает, что он обязательно использовал glibc. Вам нужно будет подтвердить это, обратившись к исходному дереву, документации или разработчикам.

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

Я тоже видел это из вторых и третьих рук. Однако я не видел фактического описания такого случая. Честно говоря, я думаю, что это очень маловероятно.

Во-первых, Red Hat Enterprise Linux сохраняет базу своих пакетов так долго, как это возможно, и поддерживает строгую двоичную совместимость. Если вы проанализируете версии glibc, 2.12-1.7.el6.x86_64 против 2.12-1.149.el6_6.5 (предположительно здесь отсутствует .x86_64), у вас получится, что это версия 2.12 для обеих версий, локальная (RHEL) версия 1.7 против 1.149 (т.е., около 142 наборов исправлений). Одна из них для el6 (т.е., RHEL 6), другая для el6_6.5 (т.е., 5-й раунд обновлений, включенных в “новый выпуск” RHEL 6). Они должны быть очень близки, никаких заметных различий для пользователя, кроме исправлений ошибок, разумеется.

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

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