В поставляемом в составе ядра Linux гипервизоре KVM выявлена (http://seclists.org/oss-sec/2018/q3/208) уязвимость (CVE-2018-10853 (https://security-tracker.debian.org/tracker/CVE-2018-10853)), позволяющая непривилегированному пользователю гостевой системы выполнить код с правами ядра в данной гостевой системе.Проблема вызвана ошибкой в коде эмуляции инструкций sgdt/sidt/fxsave/fxrstor, в котором не выполнялась проверка текущего уровня привилегий, что давало возможность выполнения данных инструкций обычным пользователем для повышения полномочий внутри гостевой системы. Проблема проявляется начиная с ядра 4.10. Патч с исправлением уже принят (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...) в состав ядра Linux. Обновления пакетов выпущены для Debian (https://security-tracker.debian.org/tracker/CVE-2018-10853), SUSE, openSUSE (https://bugzilla.novell.com/show_bug.cgi?id=CVE-2018-10853), Ubuntu (https://people.canonical.com/~ubuntu-security/cve/2018/CVE-2...) и Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=1589892). Ядра из состава RHEL проблеме не подвержены (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-10853).
Дополнительно можно упомянуть недавно выявленную (http://seclists.org/oss-sec/2018/q3/184) уязвимость (CVE-2018-14619 (https://security-tracker.debian.org/tracker/CVE-2018-14619)) в криптоподсистеме ядра, которая потенциально позволяет локальному атакующему выполнить свой код с правами ядра Linux. Тем не менее, уязвимость не представляет реальной опасности, так как около 8 месяцев назад была устранена как ошибка и только сейчас стало ясно, что эта проблема представляла угрозу безопасности (уязвимость всплыла после автоматизированного тестирования на наличие use-after-free уязвимостей в старых ядрах).
Уязвимость присутствовала в ядре 4.14 и была устранена (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...) в обновлении 4.14.8, т.е. в основном ядре просуществовала с 12 ноября по 20 декабря 2017 года. Тем не менее, короткое время уязвимость присутствовала в одном из пакетов с ядром для Fedora Linux и в пакете kernel-alt из состава RHEL для архитектур ARM64, IBM POWER9 (little endian) и IBM z.
URL: http://seclists.org/oss-sec/2018/q3/208
Новость: https://www.opennet.ru/opennews/art.shtml?num=49218
>Ядра из состава RHEL проблеме не подверженыК слову об энтерпрайсе, который тут почему-то поливают грязью.
От зависти и невежества. Кому надо, те знают, что за ядро у шапки, и прекрасно используют.
Ваистену поехавший, рхела с ядром 4.10 и новее нет. В 0.9 небось половина штеудовых багов не заработает, присвой и эту фичу успешным партнёрам интырпрайса.
Ты как-то очень наивно сравниваешь версии редхатовских ядер с мейлайном
да не, мы на самом деле не большие любители обмазаться свеженьким.
Переходим на новые версии только когда уже действительно что-то важное не удается заставить работать со старой, и бэкпорт нужных фич оказывается невозможным.
Только к этому моменту пол-ядра состит из бэкпорта, что делает сравнение по цифиркам совершенно бессмысленным
да нет, с чего вы взяли? "stable api is no sense" - не наш лозунг.
Бэкпортируются драйвера, далеко не все, зачем нам всякий мусор типа rpi, только те что актуальны крупным клиентам, отдельные api, которых хочет докер-шмокер и прочая модная похабень, исправления в поддерживаемых нами (то есть не на букву b) файловых системах, сети и т п. Наоборот в апстрим пихается своя разработка, прежде всего в области xfs - будет оно там работать или развалится - нас не очень колышет, мы засабмитили и бабос заслали, пусть дальше Линус выгребает.другое дело, что вряд ли средневзятый опеннет-др*чер сможет без подглядывания в гугл назвать принципиальные отличия между vanilla 3.10 и нынешним...каким там - не следим, сорри... 4.8? Или уже 5? 6? Какая, нахрен, разница...
В пятую центось бекпортировали kvm, но это было во времена когда редхет был лидером, а не сидел под мелкой мягкой шконкой.
Извините,в 2.6.18 пятой шапки, конечно же.
наоборот же ж - когда было что бэкпортировать. btrfs по мнению гадов ненужно, zfs опасно (и в целом работает, пусть и не изкаропке), xfs и современные правки lvm не портируются а наоборот, активно развиваются редгадами и пушатся в апстрим. Чего нынче бэкпортировать-то?
Все банально просто - это из-за того что "Проблема проявляется начиная с ядра 4.10", а в "энтерпрайзе" более старая версия...
Читай внимательно: "...короткое время уязвимость присутствовала ... в пакете kernel-alt из состава RHEL"! ;)Ну и не забываем о том, что ядра у шапки 3.10, а дырка была в 4.10 - почувствуйте разницу!
Нет тут причинно-следственной связи. Успокойтесь.
Опять в красношапке с древним ядром ничего не работает.
Дурик, кто же в интерпрайзных сборках на номер версии смотрит?
> Опять в красношапке с древним ядром ничего не работает.Какая к черту разница какое ядро на работающей системе ?
Если ты аж настолько специалист, что тебе это важно - для тебя не составит труда скомпилить необходимые новые модули под старое ведро.
Лучше расскажи мне почему 2.6.32 работает шустро как часики, а 4.10 безбожно тормозит.
Потому что нихрена не умеет?
>Лучше расскажи мне почему 2.6.32 работает шустро как часики, а 4.10 безбожно тормозит.Только после того как ты мне расскажешь почему у василисков осенью зелёное оперение на хвосте.
Тут каждый же знает!
Если у василиска на хвосте перья, а тем более зелёные - что-то пошло не так.
Дебажить нужно и заводить CVE.
>скомпилить необходимые новые модули под старое ведроСначала их придётся ещё бекпортировать.
> Лучше расскажи мне почему 2.6.32 работает шустро как часики, а 4.10 безбожно тормозит.Из-за регрессий
Ты не поверишь, разница есть! В старых ядрах не полностью работают некоторые фишки системД, например...
От беда, а РедХат не знала сие и ввела в 7-й версии системд на старых ядрах...
И не надо
12309 жеж!кстати, успехов вам скомпилировать хоть один новый модуль кроме sekelton.c под 2.6.18
Мы вот быстро сдались.
Почему, был же случай, когда они уязвимости бэкпортировали вместе с кодом драйверов
Ссылка под словом "устранена" вообще на что-то не на то.
> Проблема вызвана ошибкой в коде эмуляции инструкций sgdt/sidt/fxsave/fxrstor, в котором не выполнялась проверка текущего уровня привилегий, что давало возможность выполнения данных инструкций обычным пользователем для повышения полномочий внутри гостевой системыКаким образом это можно сделать ?
Долгое время эти sgdt и sidt были вообще непривилегированные, и никому это особо не мешало, сейчас проверка привелегий зависит от битика UIMP в CR4 и предназначена эта порнография исключительно для скрытия факта виртуализации. В патче как я гляжу просто прибили все намертво гвоздями, причем исключительно к CPL3. По индусски дыру заткнули вобщем.
Ждем ровно тех же граблей с sldt, smsw и str. Тут про них тщательно забыли.
Исправили и ладно...