Comments 17
А менеджеров?
Ну все сходится. Сначала появились в сми исследования в которых начали хвалить одни языки программирования и хейтить другие. А теперь к этому ещё и Офис национального директора по кибербезопасности (ONCD) Белого дома США подключили.
Похоже кто-то хорошо проинвестировал в Питон Rust и Яву и хочет теперь отбить свои инвестиции.
Python
Это тот которому все равно нужны C-шные либы (небезопасно же) для любой маломальский сложной операции, и который упадет в проде из-за опечатки в исходниках?
Упавший сервис точно не сможет отдать важные данные хакеру
Упасть в проде может что угодно и это наименьшая проблема из возможных. А либы для питона можно писать на любом языке, который поддерживает сишный ABI, в том числе и на Rust.
Да нет, ни что угодно. Большинство языков могут упасть из-за кривой логики, а код с опечаткой банально не скомпилится, а вот в Питоне такой код вполне себе запустится и будет работать, пока не вызовется что-то из файла с опечаткой...
То что использовать в теории можно любую либу с ABI это понятно, но большинство из них не на безопасных языках, и на них они переписываются только иногда и неспеша
Падение есть падение, причина почему оно упало не так важна. Когда приложение поработало и упало с null pointer reference, это как-то принципиально лучше, чем когда оно же падает с ошибкой синтаксиса? Конечно нет. Речь о том, что ошибка, при которой приложение падает, это на порядок меньшая проблема, чем уязвимость в безопастности, из-за которой атакующий может получить несанкционированный доступ к данным или запустить вредоносный код и именно об этом идет речь в рекомендации ONCD. И именно по-этому даже скриптовый язык типа Python это более предпочтительный выбор чем С/С++ если речь идет о безопастности.
И именно по-этому даже скриптовый язык типа Python это более предпочтительный выбор чем С/С++ если речь идет о безопастности.
Глупости. Скриптовые языки с точки зрения безопасТности едва ли лучше, чем C/C++. Да, там есть автоматическое управление памятью, но ещё там есть by design возможность исполнять генерируемый на лету код - например, с помощью функций наподобие exec() илиeval(), что, скажем так, ничуть не менее разрушительно, в том числе при выполнении таких типичных действий, как десериализация данных, если данные эти происходят из недоверенных источников.
Вы подменяете один класс ошибок другим. Eval по определению это функция выполнения произвольного кода, она в явном виде говорит программисту о том, что здесь в приложении есть возможность запустить код из внешнего источника. И дальше уже за разработчиком остается принятие решения о том использовать эту функцию или нет. В тоже время условный memcpy по своей семантике никакого отношения к исполнению кода не имеет и по-этому отслеживание связанных с ней уязвимостей требует больших усилий и квалификации.
Вы подменяете один класс ошибок другим.
Я ничего не "подменяю", я прямо утверждаю, что в скриптовых языках свои проблемы, и не маленькие.
В тоже время условный memcpy по своей семантике никакого отношения к исполнению кода не имеет и по-этому отслеживание связанных с ней уязвимостей требует больших усилий и квалификации.
Ну это уже просто манипуляция. Люди, которые вызывают условный memcpy(), должны понимать, как он работает, и к чему может привести потенциальная ошибка, так же, как и люди, которые вызывают условный eval() или десериализацию, должны понимать, как это работает, и к чему может привести потенциальная ошибка. Голову никогда отключать нельзя. Некоторые считают, что для скриптовых писателей квалификация необязательна, а потом огребают очередную CWE-94, которых так-то в скриптовых поделках чуть менее чем дофига (причем большинство, я подозреваю, еще не найдены).
должны понимать, как это работает, голову никогда отключать нельзя.
Агрумент "люди должны понимать" ложный по своей сути, потому что для любой задачи можно сказать "люди просто не должны совершать ошибок". Это пафосные слова, которые не имеют никакой практической пользы и не решают никакой проблемы. К примеру, так можно дойти до того, что смартпоинтеры не нужны, зачем тратить ресурсы на счетчик, если можно просто "включить голову"(с) и вовремя вызывать free(). Опять же, все еще не понятно, как из ваших рассуждений следует, что наличие определенных частных кейсов уязвимостей типа вызова eval в скриптовых языка оправдывает проблемы контроля памяти в C/C++ и почему исходя из этого эти языки одинаковы с точки зрения безопастности использования.
Агрумент "люди должны понимать" ложный по своей сути, потому что для любой задачи можно сказать "люди просто не должны совершать ошибок".
Этот аргумент существует не в вакууме, а в контексте - как ответ на ваш аргумент "вот вызов eval() явно говорит о возможности исполнения кода, поэтому в скриптовых языках не требуется особая квалификация для того, чтобы отследить места, где код потенциально может быть выполнен". В то время как конкретно для eval()это, может быть, и верно, одним eval() ом дело не ограничивается, я привел его просто как пример. Погромист может вызвать, к примеру, yaml.load() - ведь, казалось бы, какое по своей семантике этот вызов может иметь отношение к исполнению кода, ага? - и получить тот же самый CWE-94 как с куста.
P.S. И да, люди должны понимать, что они делают.
Опять же, все еще не понятно, как из ваших рассуждений следует, что наличие определенных частных кейсов уязвимостей типа вызова eval в скриптовых языка оправдывает проблемы контроля памяти в C/C++ и почему исходя из этого эти языки одинаковы с точки зрения безопастности использования.
Ну что ж, очень жаль, что вам все еще ничего не понятно, но я это как-нибудь переживу.
Погромист может вызвать, к примеру, yaml.load() - ведь, казалось бы, какое по своей семантике этот вызов может иметь отношение к исполнению кода, ага? - и получить тот же самый CWE-94 как с куста.
Проблема выполнения кода при десериализации/динамического исполнения не специфична для питона и в целом для скриптовых языков. Можно вспомнить, к примеру, Log4Shell, который стал огромной проблемой для java приложений. Значит ли это что Java "с точки зрения безопасТности едва ли лучше, чем C/C++"? Рынок разработки программного обеспечения уже давно ответил на этот вопрос.
очень жаль, что вам все еще ничего не понятно, но я это как-нибудь переживу.
Если вы не можете логически аргументировать собственную позицию, то зачем начали дисскусию? Но хорошо, "слив засчитан"(с)
Проблема выполнения кода при десериализации/динамического исполнения не специфична для питона и в целом для скриптовых языков.
Я нигде и не говорил, что она специфична только для этих языков. Я сказал, что она там присутствует by design, и как правило не требует никаких внешних сервисов для своей эксплуатации (в отличие от того же log4shell, который требует JNDI). Но в принципе да, последствия в любом случае тяжелые, просто эксплуатировать ее в скриптовых языках еще легче, чем в Java.
Рынок разработки программного обеспечения уже давно ответил на этот вопрос.
Рынку программного обеспечения (пока, со временем он этим "наестся") выгодно привлечь побольше низкоквалифицированных обезьян (отсюда все эти курсы типа "погромист на питоне с нуля за месяц"). В качестве оправдания, почему их стоит привлекать, применяются различные манипуляции типа "ну, есть языки, в которых квалификация и понимание происходящего не очень-то и нужны", а в качестве результата мы имеем тот же log4shell (это как минимум). Видите, вы даже не понимаете, что сами себе противоречите.
Если вы не можете логически аргументировать собственную позицию, то зачем начали дисскусию?
Я думал, что беседую с человеком, который хочет разобраться в вопросе, а оказалось - что с человеком, который мыслит модными на данный конкретный момент лозунгами, и которому хочется просто переспорить/перекричать другого, в том числе с помощью манипуляций. Например, я нигде не говорил, что "проблема внедрения кода специфична исключительно для скриптовых языков" или что "наличие определенных частных кейсов уязвимостей типа вызова eval в скриптовых языка оправдывает проблемы контроля памяти в C/C++". Этот бред вы придумали сами, а затем приписали мне. Ладно, не интересно.
Офис по кибербезопасности Белого дома США призвал разработчиков переходить на безопасные ЯП типа Rust