Pull to refresh

Comments 72

А какова собсвенно задача? Насколько я понял, поломается запуск бинарников. Вы предлагаете найти способ исправить последствия данной команды без rescue-бута?
Если так — можно попробовать через busybox сменить права, например, в grub2, который у многих стоит можно и менять параметры загрузки, и ещё много чего.
Это все лазейки. Есть одно хардкорное решение. Для него нужно, чтобы у вас стояла одна из последних версий bash (может сработать и в старых, я не проверял).
Скорее всего, просто нужно, чтобы в память была загружена какая-то программа (тот же bash, например, но, увы, встроенных функций для смены прав у него нет), которая бы умела своими штатными средствами (без вызова /bin/chmod, т.е. лишь с использованием системных вызовов) изменять права.

Например, если у вас чудом был запущен Python, то можно сделать так:

import os
[os.chmod('/lib/%s' % x, 777) for x in os.listdir('/lib') if x.startswith('ld-')]
Да, это одно из решений тоже. На самом деле busybox и grub тоже не лазейки, а вполне себе хорошие решения, но есть как минимум одно решение, которое работает даже если нет запущенного питона, busybox, и перезагружаться нельзя.
UFO just landed and posted this here
bash: /lib/ld-linux-x86-64.so: Permission denied

У меня уже вся работа остановилась, азарт ;) Действительно занимательная задача.
Решите одним любым способом, который прокатит, а то все-таки не пятница :)
Тоже хороший вариант, но он работает если у вас есть это самое /lib/ld-linux-x86-64.so, его может не быть. У меня оно такое:
ll /lib/ld-linux.so.2 
lrwxrwxrwx 1 root root 25 Aug 28 10:00 /lib/ld-linux.so.2 -> i386-linux-gnu/ld-2.19.so*


Есть другой вариант, который сработает даже если у вас есть всего один прелоадер на машине, и (намеренно оставлено пустым).
Чем плохи лазейки для решения задач? :)
Ничем, хорошие решения. Я неправильно выразился, прошу прощения.
LANG=C; IFS=; while read -d '' -r -n1 x ; do case "$x" in '') printf "\x00";; *) printf "%s" "$x";; esac done < /lib64/ld-linux-x86-64.so.2  > /bin/false
/bin/false /bin/chmod +x /lib64/ld-linux-x86-64.so.2
Хорошая попытка :) но, увы, printf — тоже утилита, которая не запустится:

$ whereis printf
Это с каких это пор printf не является встроенной командой bash?
[root@centos ~]# builtin printf
printf: usage: printf [-v var] format [arguments]
Прошу прощения, ошибся :) Видимо, у меня она и в виде встроенной команды, и в виде утилиты.
Таки работает!
Поздравляю, вы решили задачку сложным способом!

У меня было заготовлено очень похожее решение:
( while read -r -d '' ; do printf %s'\0' "${REPLY}" ; done ;  printf %s "${REPLY}" ) < /lib64/ld-linux-x86-64.so.2 > /bin/false 


Оно работает немного быстрее, но я его не полностью сам придумал, мне немного подсказали джедаи баша. Так что вам полное ура!
Простое решение как-то с редиректами связано. Пока не могу решить.
Более простое состоит в использовании busybox или другого прелоадера, который тоже может оказаться в системе, вы это конечно знаете.

С использованием чистого баша я не знаю, как можно проще решить задачу «скопировать один бинарный файл в другой бинарный файл», к которой сводится задачка из статьи. Если придумаете — будет круто :)
busybox слишком просто )
можно усложнить задачу:
chmod -x /sbin/busybox
chmod -x /lib64/ld-linux-x86-64.so.2
ctrl+d
Но после ctrl+d у вас отвалится сессия и спасет только перезагрузка и загрузочный образ или колдовство с grub (можно ли замонтировать файловую систему так, чтобы все файлы были исполняемыми, как в vfat?). Или у вас есть какой-нибудь особенно хитрый способ?
Нет, это лишь постановка задачи.
Очень правильная постановка вопроса, всегда перед запуском таких скриптов открываю браузером и читаю что же там на самом деле написано, иногда ставится то, что на самом деле не нужно — проще почитать, уловить суть автора, и сделать то же, но по своему.

Печально когда народ копипастит, не думая о последствиях (мне скрывать нечего, моя информация никому не нужно, кому нужно меня взламывать и прочие глупые отмазки).
Если подходить с позиции желания автора скрипта вам (лично вам) навредить, ваш вариант чтения скрипта в браузере — ничем не лучше. Простейшим кодом на стороне сервера по user-agent wget получает код отличный от браузера.
p.s. это я не говорю про проверки по ip адресу и т.п.
Правильно скачать скрипт к себе, у себя его посмотреть, и его же запустить.

Но зачастую, как сказал nazarpc, запускать ничего и не надо. Достаточно браузером открыть скрипт, и вручную поставить нужные пакеты.
UFO just landed and posted this here
Да, но к более мягкой все ответ уже знают.
уважаемый автор, тезисы у вас правильные, но надрывный тон огорчает. Прямо таки руки чешутся поставить картинку с британской короной и «Keep calm».

В данном конкретном случае речь шла о коде, который:

  • предполагалось запускать на новом пустом инстансе на бесплатном или грошовом хостинге
  • на него смотрят сотни пар глаз, да не просто смотрят — пуллреквесты шлют

Так что соразмерной реакцией было бы прислать автору pull-request из двух строчек, одна выводит echo «дорогой друг, ты только что запустил код из интернета, не вводи это в привычку», а вторая вычисляет SHA1 от скачанного и просит убедиться, что он совпадает с SHA1 с Гитхаба.
Статью писать не собирался, пока меня к этому не подтолкнул shanker. Надрывный тон был в комментарии, в статье его нет.

>Так что соразмерной реакцией было бы прислать автору pull-request из двух строчек…
Нет, задача тут совершенно не в том, чтобы наехать на предыдущую статью, она только пример. Задача — рассказать людям о том, как правильно делать. К тому же вы предлагаете поступить по принципу «если очень хочется, но нельзя, то все-таки можно», а это в делах связанных с безопасностью беспощадно карается угоном доступа к машинам.
Надрывный тон был в комментарии, в статье его нет.
Ага, ага:



Ну так pull-request сделайте же, spread the word.
А как связаны моя любовь к огромным заголовкам и надрывный тон?
Во-первых, качаете скрипт вы с какого-то домена, это даже не прямой линк на GitHub.
А во-вторых вам потом предлагается свой трафик через этот софт прогонять, при чем тут что за сервер и пуст он или нет?
Очень трудно спорить, когда полностью согласен. Я ж в начале написал: «тезисы у вас правильные, но надрывный тон огорчает»

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

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

Бесполезна же статья или нет пусть решает сообщество.
Беда в том, что не только автор того поста так делает.
Но ведь это то же самое, что скачать исходники программы, скомпилировать их у себя (не читая) и запустить. Так делают 99,999% юзеров.
Конечно, поощрять такое не стоит, но есть ли альтернатива?
Нет, это совсем не то же самое. При скачивании исходников вы как правило скачиваете архив, к которому выложена контрольная сумма, либо который подписан закрытым ключом автора, а открытый ключ можно достать из других источников и с достаточной уверенность убедиться в том, что этот ключ именно автора. Описанный в статье порядок работы с программами является многолетний практикой в мире UNIX и подобных, доказательством этому служит повсеместное выкладывание контрольных сумм рядом с ссылкой на скачивание. Об этом вся статья.

Если архив не подписан, всегда можно написать автору, приложить контрольную сумму и спросить.

А если кто-нибудь скачивает не проверяя, ну так 99% пользователей Windows в свое время тоже так поступали, да и сейчас большинство так и делает. Но нельзя опускать руки, нужно стремиться к тому, чтобы делать правильно, тем более большинство пользователей пользуются официальными репозиториями, а там все проверки делаются за вас.
Описанный в статье порядок работы с программами является многолетний практикой в мире UNIX и подобных, доказательством этому служит повсеместное выкладывание контрольных сумм рядом с ссылкой на скачивание.

выкладывание контрольных сумм идет со времен дайлапов, когда вероятность скачивания битого архива была непомерно высока. И сверка контрольных сумм была не вопросом безопасности, а элементарным контролем того, что таки файло докачалось и докачалось правильно.

Что касается установки пакетов из Сети, то это дело такое… Для более-менее крупных пакетов действительно зачастую существуют контрольные суммы. И то не всегда. А для кучи мелких скиптов и односточников — нет. И весь интернет полон различных советов по настройке того и этого с помощью тех или иных команд. И всегда остается вероятность, что где-то среди этих 1-2 строчных советов появится один с rm -rf / в середине. И кроме внимательных глаз и здравого смысла ничего не спасет.
Да в общем согласен полностью, подписи надо проверять.
Я вот замечал такую странную вещь: 80% людей боятся запускать присланные bat файлы, но все из них с радостью запускают присланный exe.
У батника в винде по дефолту значек страшнее!
exe-файлы кто только не присылает, а батниками пользуются одни хакеры!

А если серьезно, то exe можно подписать.
Стоит еще заметить, что с технической точки зрения этот способ ужасен. Допустим, в распространяемом софте обнаружилась уязвимость. Что сделают люди, которые распространяют софт по-человечески, через пакеты? Правильно, просто выкатят обновление. А в этом случае — совершенно непонятно.

И спасибо большое: я после вчерашнего сам очень сильно хотел пост написать на эту тему.
Видимо, они перевыложат скрипт. Исключение: если скрипт выложен на pastebin, тогда всё совсем плохо.
А мы потом ловим 100-тысячный ботнет из одноразовых виртуалок!
UFO just landed and posted this here
Это отвратительно. Как напоминает капитан очевидность, безопасность и удобство находятся на разных концах одной и той же палки, и абсолютная безопасность недостижима, но отказываться от разумных действий вовсе? Остается только надеяться, что несколько раз нарвутся и прекратят.
UFO just landed and posted this here
HTTPS выполняет совершенно другую задачу, он не дает вообще никаких гарантий по поводу содержания. Это разные задачи, они по разному решаются.

Ну и что, что сертификат валиден? А если сервер сломали? Еще и не у таких ломали, вспомните фиаско с взломом kernel.org. В том случае кстати все получилось легко исправить только потому, что был инструмент, git, который работал с контрольными суммами.
UFO just landed and posted this here
Неверно. В репозиториях Ubuntu и пакеты подписаны, но ключа на них самих нет, ключ есть только на сборочных серверах. Так работает защита в глубину, система разделяется на части и между ними ставятся перегородки.

Если репозиторий или зеркало взломать, пакеты подписать все равно не получится, и apt-get не даст поставить пакет с неправильной контрольной суммой, т.к. в списке пакетов, подписанным в свою очередь закрытым ключом, которого в репозитории тоже нет, контрольная сумма указанна другая другая, а у нового подмененного файла со списком пакетов подпись не совпадет.

Матчасть полезно знать. Теперь вы видите отличия от HTTPS, которое гарантирует только защищенное соединение точка-точка, и иногда подлинность сервера с котором вы соединяетесь, но ничего больше.

Поэтому кстати зеркала можно http отдавать без опасений.
Вопрос кстати хороший.
У меня были почти такие же мысли, когда я homebrew устанавливал. Пожалуй, больше не стоит так делать :)
Они мало понимают в безопасности если такое делают, не стоит думать, что других уязвимостей у них нет.

Если у вас нет выбора и нужно ставить, делайте так:
wget https://getcomposer.org/download/1.0.0-alpha8/composer.phar
md5sum composer.phar
df1001975035f07d09307bf1f1e62584  composer.phar 


А потом вот так: www.google.ru/search?q=df1001975035f07d09307bf1f1e62584
мб лучше забрать getcomposer.org/installer, потом как-то убедится что он действительно без изменений, а потом его запустить?
Если можете просмотреть код и убедиться, то спокойно можно скачивать. Если нет, лучше брать релиз. Обратите внимание, что в этой штуке в конце вшита куча сертификатов, это видимо значит, что сама эта штука все проверяет как положено.

Но я код не читал, могу ошибаться.
Про убунту:
Далее считаете контрольную сумму, sha256 у них на сайте нет, поэтому пойдет md5: «md5sum ubuntu-14.04.1-desktop-amd64.iso»

Есть всё — md5, sha1, sha256 и даже цифровые подписи к ним (*.gpg):
releases.ubuntu.com/trusty/
UFO just landed and posted this here
Проверка чексумм руками — чистой воды карго-культ. Если злоумышленник вам может подсунуть плохой файл, что ему мешает подменить «хорошую» чексумму на плохую и наоборот во всём трафике?

А если у вас чексумма по https, то не выделывайтесь и качайте файлы по тому же https.

Криптографическая проверка файлов полагается не на «сравнение хешей глазками», а на использование открытого/закрытого ключей, желательно с кейрингами.

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

Знаете, у статьи есть привкус истерики.
Не согласен с вами. Я написал специально, что нужно искать другие источники, того который лежит на сайте вместе с программой, очевидно недостаточно.

Это не дает полной гарантии, как и любое аналогичное действие, но значительно лучше, чем ничего.
Это вообще ничего не даёт. Если кто-то настолько заморочился, что подменил на официальном сайте по https и софт и страничку с контрольными суммами, то он сможет и на других сайтах опубликовать ту же информацию (напр. повыкладывать самостоятельно на торрентах), хотя скорее всего за него это проделают обычные юзеры (в смысле, поддельная инфа распространится по другим сайтам точно так же, как распространилась настоящая).
Для того, чтобы проверка чексуммы стала полностью бесполезной, необходимые условия такие:
— взломан сервер на котором лежит программа;
— подменены чексуммы во всех других местах.

А если взлом произведен недавно? А если взломано только зеркало? Должно выполниться больше условий для того, чтобы в итоге запустился вредоносный код.

Итог — проверка хэшей и поиск их в гугле безусловно полезна, вопрос только в том, насколько. Безопасность же это не все или ничего, это не черно-белая штука, можно только увеличить ее с некоторой вероятностью.
А если взломано только зеркало?
В таком случае поможет следующий алгоритм:
1. качаем файл с зеркала,
2. смотрим контрольную сумму на официальном сайте и сравниваем.
Гугление контрольной суммы — мартышкин труд.
Насчет мартышкиного труда не согласен, но я согласен что лучше искать по запросу вида «packagename sha1» или подобного. И конечно проверять подпись, если она есть.
Скажите, а когда вы искать будете, MiM вам чексуммы подменять будет в одну сторону или в обе? Я бы в обе подменял. Ищите одно, в поисковик уходит другое, в результатах вам показывают результаты для «другого», а чексумма — от первого.
Вы совершенно правы, но MiM это только один из случаев. К тому же одно дело сделать MiM на один сайт, другое — на все, включая гугл по https.
Совершенно правильно. Потому софт надо запускать не методом «скачивания бинарников из интернетов», а через систему управления пакетами, которая куда лучше вас умеет разбираться с криптографией.
Согласен, дописал в конец статьи совет пользоваться только репозиториями (официальными, т.к. сторонний репозиторий тоже нужно проверять перед добавлением) в случае отсутствия полного понимания у человека.
Sign up to leave a comment.

Articles