Защищают ли Apache общие объекты CommandLine от внедрения командной строки?

Question

Я хочу использовать библиотеку Java org.apache.commons.exec для вызова исполняемого файла.Защищает ли объект CommandLine от ввода в командной строке?Например, если я позвоню:

String singleStringArgument = "-whatever;rm -rf ~/*"; // evil looking argument!
CommandLine cl = new CommandLine(new File(pathToExe,exeName)); 

cl.addArgument(singleStringArgument);  // oh no!

Executor exe = new DefaultExecutor();
exe.execute(cl);

, будет ли rm -rf ~/* работать в дополнение к предполагаемой команде?Если да, то как лучше всего защититься от этого?

API говорит addArgument() "обрабатывает цитирование", но я не уверен, что это означает в этом контексте.Я мог бы создать тестовый сценарий, чтобы увидеть, что происходит на моем компьютере с Linux, но я хочу быть уверен, что это безопасно и на других платформах.

Answer 1

; это особенность оболочки. Если вы не создадите командную строку вокруг sh -c или что-то в этом роде, вы не сможете войти в нее. Дело не в том, что общие средства безопасны, а в том, что вы даже не запускаете программу с уязвимостью.

CLI Commons включает класс Process. Класс Process не задокументирован для запуска оболочки. Документально подтверждено выполнение exec с указанными аргументами того, что вы говорите.

Согласно комментарию, одно из чудес открытого исходного кода заключается в том, что вы можете прочитать исходный код. Если версия X Commons-CLI делает то, что вам нравится, зависит от нее и не обновляйте без перепроверки.

Answer 2

То есть вы управляете командой (pathToExe) и беспокоитесь только об аргументе?Насколько хорошо вы знаете команду?Есть ли шанс, что он может выполнить другую программу?Есть ли шанс, что он может сделать что-то разрушительное, даже не вызывая вторичную команду?Есть ли в программе какие-либо другие уязвимости (переполнение буфера и т. Д.)?

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

Answer 3

Мое предложение состоит в том, чтобы сделать программу ошибочной, если это возможно, на стороне безопасности и только выдавать команды самостоятельно, а не тупо выполнять фрагменты команд или передавать аргументы, выданные конечным пользователем.Есть много вариантов инъекций.; уже обсуждался.Вы также можете использовать обратные пометки (обтекание rm -rf ~/* в обратные пометки заставляет оболочку сначала интерпретировать его). Пользователь также может случайно или намеренно вызывать псевдонимы.Список вещей, которые могут пойти не так, бесконечен.