Comments 21
Я даже не знаю, стоило ли это публиковать в открытом доступе до появления способа противостоять этому.
UFO just landed and posted this here
похожий вектор уже использовали в рабигемз для remote execution на сервере (на котором пакеты хранятся)
только там не на опечатки был упор, а на то, что файл, описывающий пакет eval-ится на сервере (моя вольная интерпретация прочитанного здесь около года назад. искать, естессно, лень :) )
только там не на опечатки был упор, а на то, что файл, описывающий пакет eval-ится на сервере (моя вольная интерпретация прочитанного здесь около года назад. искать, естессно, лень :) )
UFO just landed and posted this here
Например, подписывать релизы и проверять подписи?
Не, это сильно сложно. Да и кому это вообще понадобится? Ой, надо ж поставить эту штуку… ага,
Не, это сильно сложно. Да и кому это вообще понадобится? Ой, надо ж поставить эту штуку… ага,
curl http://example.com/install_thingie.sh | sudo shUFO just landed and posted this here
Ну да, а я о чём. Решение есть. Просто заморачиваться не удобно.
За подписями следить разработчикам, кому же ещё. Каждому публикуемому пакету по подписи, да. Ключи можно заливать на какой-нибудь key server. Через него же отзывать скомпрометированные. Верифицировать — хотя бы через какие-то соцсети посредством того же Keybase.io. Ходить вам лично на сайт не надо, компьютер вполне может это сделать сам.
Но всё это сложнее, чем тупо скачать и установить без проверок. И даже подписи не защищают от обезьяны, не глядя жмущей «Далее, [✓] доверять Васе Пупкину с ключом 6DCB4341, далее, далее, *вводит пароль администратора*, готово». Или не глядя подписывающей что попало.
За подписями следить разработчикам, кому же ещё. Каждому публикуемому пакету по подписи, да. Ключи можно заливать на какой-нибудь key server. Через него же отзывать скомпрометированные. Верифицировать — хотя бы через какие-то соцсети посредством того же Keybase.io. Ходить вам лично на сайт не надо, компьютер вполне может это сделать сам.
Но всё это сложнее, чем тупо скачать и установить без проверок. И даже подписи не защищают от обезьяны, не глядя жмущей «Далее, [✓] доверять Васе Пупкину с ключом 6DCB4341, далее, далее, *вводит пароль администратора*, готово». Или не глядя подписывающей что попало.
Будьте внимательны при наборе номера! А то невзначай можно и не туда попасть:).
Допустим, автор пакета Вася Некуймазаев. Во-первых, это надо как-то наверняка знать. Во вторых, на keyserver лежат три ключа «Vasia Nekuimazaef» «Vasja Nekuimazaef» и «Vasjа Nekuimazaef». Какой правильный? Кстати, в этом примере две последние строки — разные. Смотрите внимательно, и больше не называйте других людей обезьянами, пока сами не можете увидеть очевидную разницу в простых строках.
В плане, наверняка знать? Автор, ключи, и всё такое можно класть рядом с прочей информацией о проекте. Вам надо только убедиться, что вы не видите, например, совершенно другой поддельный интернет, совершенно другой проект, а у вас на компьютере сохранён совершенно другой ключ.
Keyserver — это просто хостинг. Подразумевается, что вы и так знаете, что хотите там найти ключ от нужного вам Васи с нужным хешем. Которые верифицируются по другим каналам. Либо Вася вам лично в вашем блокнотике пишет хеш своего ключа своей рукой. Либо Вася просит Петю, Машу, и Сашу (или корпорацию Груша), которым вы доверяете, дать вам честное слово, что ключ с таким-то хешем принадлежит нужному Васе. Либо вы точно знаете, что Вася подписывается таким-то ником и использует такую-то аватарку, и Вася запостил хеш своего ключа на пяти различных сайтах, которым вы доверяете, поэтому у вас есть уверенность, что это именно тот Вася, который вам нужен.
Вопрос в любом случае сводится к личному доверию и принятию решения о доверии. Если эти решения принимаются безответственно, то от ЭЦП нет толку.
Keyserver — это просто хостинг. Подразумевается, что вы и так знаете, что хотите там найти ключ от нужного вам Васи с нужным хешем. Которые верифицируются по другим каналам. Либо Вася вам лично в вашем блокнотике пишет хеш своего ключа своей рукой. Либо Вася просит Петю, Машу, и Сашу (или корпорацию Груша), которым вы доверяете, дать вам честное слово, что ключ с таким-то хешем принадлежит нужному Васе. Либо вы точно знаете, что Вася подписывается таким-то ником и использует такую-то аватарку, и Вася запостил хеш своего ключа на пяти различных сайтах, которым вы доверяете, поэтому у вас есть уверенность, что это именно тот Вася, который вам нужен.
Вопрос в любом случае сводится к личному доверию и принятию решения о доверии. Если эти решения принимаются безответственно, то от ЭЦП нет толку.
При установке выдавать варнинг, что ставиться не популярный пакет.
хорошо что я не держу на компе эти Python, Node.JS и Ruby и вообще не имею привычки ставить всякую хрень вручную.
Репозитории — это, безусловно, хорошо, но надо быть с ними осторожными (в идеале).
Небольшая история: некоторое время назад я нашел пару уязвимостей на популярном хостинге репозиториев для jailbreak'нутых IOS-девайсов. Они позволяли получить полный доступ к аккаунту пользователя, включая выложенные им приложения. Учитывая популярность некоторых репозиториев, это пугало: можно было добавить вредоносный код в популярные приложения, а эти приложения улетят на устройства тем, кто захочет их установить или обновить, и смогут украсть все данные с устройства.
Небольшая история: некоторое время назад я нашел пару уязвимостей на популярном хостинге репозиториев для jailbreak'нутых IOS-девайсов. Они позволяли получить полный доступ к аккаунту пользователя, включая выложенные им приложения. Учитывая популярность некоторых репозиториев, это пугало: можно было добавить вредоносный код в популярные приложения, а эти приложения улетят на устройства тем, кто захочет их установить или обновить, и смогут украсть все данные с устройства.
Сами разрабы репозиториев могут пропарсить access.log, вытащить наиболее распространённые опечатки и закрыть к ним доступ или поставить редиректы. Проблему полностью не решит, но полегче станет
Sign up to leave a comment.
Тайпосквоттинг в репозиториях Python, Node.JS и Ruby