Как я устраняю / фиксируют CVEs в Ubuntu zlib пакет, когда новая версия не доступна через Кв. - добираются?

Без большего количества специфических особенностей того, что Вы желаете исправленный, и какой карман репозиториев Ubuntu, что программное обеспечение находится в для данного выпуска, невозможно дать Вам полный ответ, который является достаточно узким.

Но, я попытаюсь дать Вам обзор того, как 'исправить' проблемы безопасности в пакетах Ubuntu.

Пакеты программного обеспечения в Основных, и внесенных сообществом патчах во Вселенной, через $RELEASE-security репозитории

Для патчей безопасности, отправленных в пакетах пользователями для рассмотрения Службы безопасности в пакетах Вселенной и патчах безопасности самой Службой безопасности в Ubuntu Основные пакеты, когда-то выпустил, они доступны от $RELEASE-security репозитории (например, xenial-security) и $RELEASE-updates репозитории. Таким образом, можно просто сделать a sudo apt-get update && sudo apt-get dist-upgrade и получите все патчи.

Отслеживание отдельного CVEs в Средстве отслеживания CVE сообщит, выпустили ли CVE's фиксацию в Ubuntu уже, а также определении Службой безопасности приоритетного уровня CVE и как быстро этому нужно обращенный (значение по умолчанию является "Средним" независимо от серьезности CVE).

Пакеты, не обновленные в репозиториях

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

У Вас есть два решения для этих проблем: или восстановите пакеты сами с патчами или ожидайте обновления для приземления в Репозиториях (или чтобы кто-то отправил патчи для Службы безопасности).

Для первого решения Вы должны будете следовать Упаковочному Руководству от шага 1 до шага 3.9 и затем ступаете подробные в раздел 6, если Вы хотите отправить их для репозиториев, и создать исправленные пакеты локально в Вашей системе и установить их.

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

Пользовательское скомпилированное программное обеспечение

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

Если у Вас есть CVE, который необходимо зафиксировать, и он не фиксируется в официальных репозиториях для выпуска, который Вы используете, что Вы не должны делать, загрузить и установить пакеты от произвольного будущего выпуска. Такие пакеты могут установить прекрасный, но нет никакой гарантии, что существующее другое существующее программное обеспечение может взаимодействовать с ними. ABIs или API, возможно, изменились, возможно, значительно, возможно, нет. Тонкие изменения, возможно, достаточно для подбрасывания трудных к отладке ошибок. (если библиотека не загружается как ожидалось, приложение командной строки могло бы бросить file-not-found ошибку, даже при том, что файл команды ясно существует!)

То, что я предложил бы:

1. Проверьте, доступен ли патч для версии, Вы используете, или в отчетах CVE в другом месте, или от восходящего потока.
2. Если это, то загрузите и измените исходный пакет соответствующего пакета: Как я получаю и изменяю исходный код пакетов, установленных через Кв. - добираются?
   • Использовать quilt применять патч (см. Debian Wiki или этот Debian hwoto).
   • Я предложил бы, чтобы Вы ударили только младшую значащую часть номера версии (части после последнего -) - конечно, не ударяют часть перед первым :, число эпохи.
3. Установите пакет, так созданный.

Это, намного более вероятно, поддержит совместимость с другими компонентами ОС (в так же, как сама фиксация не повреждает что-то), все еще позволяя Вам обновить, если обновление поражает репозитории Вашего выпуска. Таким образом, можно также гарантировать, что конкретный CVE, который Вы хотите зафиксировать, фиксируется насколько можно сказать, который не может иметь место с пакетом от некоторого произвольного будущего выпуска.

Вот то, как я сделал это для своего первого запуска.

1. Я упаковал свое приложение на микрослужбы с пользовательским основным изображением Докера. Микросервисы были всеми на основе Node.js, так, чтобы была основа
2. Я развернул те сервисы использование Kubernetes / Докер Сочиняет в среды этапа/напоминания
3. Я сохранил те изображения Докера на cloud.docker.com, который сделал, чтобы хороший Докер отобразил сканер, который находит соответствующий CVE's путем взгляда в изображениях.

Это - то, как я добрался до соответствующего CVE's. Затем

4. Я считал CVE's для наблюдения, какой применялся. Эти 4 CVE's похожи:
   • inftrees.c в zlib 1.2.8 мог бы позволить контекстно-зависимым взломщикам оказывать неуказанное влияние путем усиления неподходящей адресной арифметики с указателями.
   • inffast.c в zlib 1.2.8 мог бы позволить контекстно-зависимым взломщикам оказывать неуказанное влияние путем усиления неподходящей адресной арифметики с указателями.
   • Функция inflateMark в inflate.c в zlib 1.2.8 могла бы позволить контекстно-зависимым взломщикам оказывать неуказанное влияние через векторы, включающие сдвиги влево отрицательных целых чисел.
   • Функция crc32_big в crc32.c в zlib 1.2.8 могла бы позволить контекстно-зависимым взломщикам оказывать неуказанное влияние через векторы, включающие вычисление CRC с обратным порядком байтов.

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

Для моего случая был CVE's Chrome (Chrome является основой для Node.js), который не относился к моим вариантам использования, таким образом, я проигнорировал их ожидающий восходящего потока, фиксирует. Иногда были вещи, которые нуждались в фиксации сразу же, таким образом:

5. Я обновил изображения Докера. Поскольку все микросервисы запустились с пользовательского основного изображения Докера, я мог выставить Узел и обновления ОС относительно быстро.
6. Развернитесь к этапу, испытанию с помощью дыма на этапе, и развернитесь к производству.

Я upvoted некоторые другие ответы здесь - надо надеяться, Вы получите то, что Вы ищете.