<p>virtualenv Побег из песочницы</p>

CVE-2018-17793 был назначен на эту проблему (не запрошен мной).

Не могли бы вы объяснить здесь влияние на безопасность? Вызов bash для возврата к нормальной оболочке не кажется мне уязвимым местом. Я не думаю, что у кого-то сложилось впечатление, что virtualenv позволяет безопасно запускать ненадежные команды оболочки, это не то, для чего оно предназначено.

Я попросил MITER отклонить CVE

Нормально следующим образом:
(test_env) r0ot # python $ (sh 1> и 2)
(test_env) r0ot #
(test_env) r0ot # питон
Python 2.7.15 (по умолчанию, 1 мая 2018 г., 05:55:50)
[GCC 7.3.0] в linux2
Для получения дополнительной информации введите «помощь», «авторские права», «кредиты» или «лицензия».

импорт ОС
os.system ("$ (sh 1> & 2)")
(test_env) r0ot #
Если вы выполняете вредоносный код:
(test_env) r0ot # python $ (bash> & 2)
r0ot #
POC:
(test_env) r0ot # питон
Python 2.7.15 (по умолчанию, 1 мая 2018 г., 05:55:50)
[GCC 7.3.0] в linux2
Для получения дополнительной информации введите «помощь», «авторские права», «кредиты» или «лицензия».
импорт ОС
os.system ("$ (bash> & 2)")
r0ot #

Если вы выполняете вредоносный код

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

PYTHON в песочнице не защищен на 100%, и уязвимости могут привести к обходу защиты песочницы. Каковы причины использования песочницы?
Если песочницу сложно исправить, рекомендуется избегать риска в коде и получать подсказки в описании песочницы.

@ BakedPotato999 Python в виртуальной «песочнице» безопасен на 0%; он не предназначен и не обеспечивает никакой защиты от вредоносного кода. Похоже, вы очень сбиты с толку целью virtualenv.

@ BakedPotato999 Python в виртуальной «песочнице» безопасен на 0%; он не предназначен и не обеспечивает никакой защиты от вредоносного кода. Похоже, вы очень сбиты с толку целью virtualenv.

Я думаю, что приложения, работающие в этом Virtualenv, независимы и не повлияют на вашу существующую операционную систему. Закрытие песочницы восстановит все операции. С помощью песочницы вы можете тестировать программы и программное обеспечение, которые могут быть опасными. Это правильно?

Нет, совершенно не так. Цель virtualenv - позволить вам использовать определенный интерпретатор Python и набор пакетов Python (вместо пакетов, установленных системой и userdir) для запуска программ в обычной среде.

Такая «песочница» по умолчанию не должна включать системные и пользовательские пакеты, а только те, которые установлены в virtualenv. Но ничто не мешает вам, например, изменить sys.path чтобы вернуть его в систему по умолчанию или в пользовательские пакеты.

И ничто не должно вам мешать. Интерпретатор Python в virtualenv должен иметь возможность выполнять все операции, которые системный интерпретатор Python (если он есть) может выполнять при запуске одним и тем же пользователем. В противном случае было бы нарушено много общих и ожидаемых применений virtualenv.

@ BakedPotato999 virtualenv/bin/activate просто помещает исполняемый файл Python в виртуальную среду раньше на вашем пути. Он не создан для безопасности.

Я закрою это как недействительное.

Мне просто интересно, как у вас получилось, что virtualenv стал sandbox @ BakedPotato999 ?

Я искал через документы, github и с git grep и единственное появление sandbox - это:

Джеймс Гарднер написал руководство по использованию virtualenv с Pylons.

который ссылается на http://wiki.pylonshq.com/display/pylonscookbook/Using+a+Virtualenv+Sandbox (в URL-адресе которого есть sandbox ).

Кстати, URL-адрес мертв, и он здесь https://github.com/pypa/virtualenv/blob/384c8d13490f171a7ad99eeedd7fe45021a83d87/docs/index.rst

;).

Тот факт, что сейчас существует "эксплойт" https://www.exploit-db.com/exploits/45528/ и что трекеры безопасности основных дистрибутивов рассматривают это как уязвимость, довольно забавно.

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

0day подтвержден! : D

Очень забавно, ха-ха и все такое, но учитывая, что CVE была создана для
этот и несколько других трекеров также перечисляют его, теперь он достигает
точка траты значительного времени, которое должно быть потрачено на реальную безопасность
другими словами, теперь у нас есть своего рода DoS на нашу безопасность
инфраструктура. Так что давай уложим это в постель, пожалуйста: этот "побег из песочницы"
это не уязвимость.

@ 0cjs Я только что доказал, что с его помощью можно получить root-доступ, как это не уязвимость?

1. Я не вижу на вашем снимке экрана свидетельств того, что вы использовали что-либо, связанное с virtualenv, для получения root-доступа. Немного подозрительно, что там упоминается установка Ruby Version Manager в домашнем каталоге root , хотя для этого есть объяснения, совместимые с реальным эксплойтом.
2. Я не могу придумать правдоподобный механизм для того, чтобы делать то, что вы делали, за исключением использования чего-либо вне virtualenv, поскольку virtualenv не имеет и не использует suid или аналогичные файлы, и ни в какой момент он не принимает на себя привилегии какого-либо пользователя, кроме того, который его запускает. (Я не говорю, что механизма не существует, но вы должны предоставить хотя бы некоторое представление о том, где может быть эта проблема. Если вы сообщили об этом ответственно, вы должны сообщить об этом и кому вы сообщил об этом.)

Одно из правдоподобных объяснений вышесказанного заключается в том, что на скриншоте не отображаются строки с символом sudo -s и запрос пароля. Это, вместе с частично удаленной установкой RVM для пользователя root, даст именно такой результат, вообще ничего не используя.

@ 0cjs Я фактически отключил его, потому что он работал, я все еще тестирую, чтобы убедиться, что это не из-за моей устаревшей системы, я фактически согласен с тем, что это был другой эксплойт ядра, который однажды проявил себя в virtualenv снова тестирую еще.

Что ж, вам следует еще немного подтвердить вещи, прежде чем сообщать об инструментах, которые по своей конструкции позволяют запускать произвольные программы и код от имени текущего пользователя. Сообщать об этом как об уязвимости virtualenv примерно столько же, сколько об уязвимости Bash, потому что вы также использовали Bash выше, или об уязвимости GCC, потому что она использовалась для компиляции некоторого кода, который вы запускали в какой-то момент.

Я ни о чем не сообщал ...?

корень @kali : ~ / test_env # python $ (bash> & 2)

Вау, это мило, но на самом деле вам не нужно использовать $ () ... вы могли бы просто ...

root @ kali : ~ / test_env # echo "это шарлатанство"

чтобы «обойти» механизмы песочницы virtualenv.

@ BakedPotato999 вам удалось получить от выполнения произвольного кода python (или другого) от имени root ... до выполнения произвольного кода python (или другого) от имени root. Что вы предлагаете - это проблема безопасности, которая возникает в первой ситуации во второй?

Вау, какая серьезная проблема. Как я могу использовать программное обеспечение, предназначенное для одного дела, если оно не может безопасно делать что-то еще? Пожалуйста, порекомендуйте.

@ednix liveoverflow?

@ednix Вы не можете. Вы никогда не должны снова использовать оболочку Unix, потому что ее нельзя безопасно использовать для _ некоторых_ целей.

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

Фактически эта «проблема» напомнила мне, что ее можно использовать для адресации https://github.com/pypa/virtualenv/issues/1334 - есть ли у кого-нибудь код POC, с которого мы можем начать?

Nexus от Sonatype предоставляет прокси для pypi.org. Прокси-сервер позволяет помещать в карантин любой пакет с рейтингом уязвимости выше заданного порогового значения.

Из-за этого ошибочного CVE virtualenv был помещен в карантин. Когда недопонимание приводит к подаче CVE, это оказывает реальное влияние на пользователей, а также приводит к потере времени и усилий участников.

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

MITER установил CVE как оспариваемый. Возможно, вам удастся заставить Sonatype уважать эту информацию.

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

Мы вообще не должны жить, жизнь опасна