Исследователи безопасности из группы Zero, созданной компанией Google для предотвращения атак, совершаемых с использованием ранее неизвестных уязвимостей, опубликовали (https://googleprojectzero.blogspot.com/2018/09/a-cache-inval...) детали эксплуатации уязвимости (CVE-2018-17182) в подсистеме vmacache ядра Linux, о которой сообщалось (https://www.opennet.me/opennews/art.shtml?num=49305) на прошлой неделе. Продемонстрирован процесс создания рабочего эксплоита при наличии возможности обращения к уже освобождённому блоку памяти (use-after-free), вызванной отсутствием проверки переполнения 32-разрядного номера последовательности в vmacache.Уязвимость может быть эксплуатирована для повышения привилегий любым локальным процессом, который может выполняться достаточно долго для переполнения счётчика ссылок (около часа, если доступен MAP_FIXED) и способного выполнять маппинг областей памяти при помощи системных вызовов mmap()/munmap() и создавать потоки через вызов clone(). Отдельно отмечается, что указанные системные вызовы не требуют каких-то особых привилегий и обычно доступны даже из sandbox-окружений (например, допустимы в sandbox-окружении процесса отрисовки браузера Chrome и присутствуют в списке разрешённых системных вызовов Docker).
Проблема появилась в ядре 3.16 и исправлена в обновлениях 4.18.9, 4.14.71, 4.9.128, 4.4.157 и 3.16.58. Работа эксплоита продемонстрирована в Ubuntu 18.04 я ядром linux-image-4.15.0-34-generic, в том числе атака может быть совершена из изолированных окружений на базе Docker. В Debian (https://security-tracker.debian.org/tracker/CVE-2018-17182) и Ubuntu (https://people.canonical.com/~ubuntu-security/cve/2018/CVE-2...) проблема пока остаётся неисправленной и обновления пакетов ещё не сформированы. Исправление уже доступно в Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=1631206#c8). Ситуация с исправлением пока не ясна для RHEL (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-17182) и SUSE (https://www.suse.com/security/cve/CVE-2018-17182/).
В качестве временной меры защиты от предложенного эксплоита можно установить sysctl kernel.dmesg_restrict и kernel.panic_on_oops.URL: https://googleprojectzero.blogspot.com/2018/09/a-cache-inval...
Новость: https://www.opennet.me/opennews/art.shtml?num=49345
А я вот сьодня такую "уязвимость" нашол:
echo $((07+1))
echo $((08+1))
Кто обьяснит почему так и задумано?
:~$ echo $((00+1))
1Дальше объяснять надо?
Да, 0+1=1
0n - формат числа в восьмеричной системе. Поэтому он ругается на 08 - в восьмеричной такого числа нет, будет 10.
Пролистай man bash. Чему кроме нагромождения костылей могли посвятить столько писанины? А распечаткой zsh-all можно было бы замотать Землю в дьявольский кокон (предварительно вырубив все леса для производства такого количества бумаги). Одумайтесь!
Да ладно?$ echo $((08+1))
9
$ echo $((07+1))
8
$
mksh 56cВыкиньте свой bash.
А export OCTAL_CONST=ON у Вас не работает?
$ export OCTAL_CONST=ON
$ echo $((08+1))
9Видимо нет
bc, awk, caches[, LWKT]
UNIX way
Наверно с нуля начинаются восмиричные числеecho $((010))
12-msk:/user> echo $((08+1))
9
что я делаю не так?
Пользуешься POSIX-совместимым shell. А они башем.
Ну как бы те кто сугубо в линуксах живут, да - им на шелл без разницы.
А если что то еще есть, но тут без посикса никуда не денешься. Даже массивы нужно клепать самостоятельно, ибо их нет.
Используешь какую-то экзотику вместо стандартда де-факто. Или экзотические настройки, что в случае шелла - одно и то же