Início / unix / Perguntas / 448443
Accepted
Tim
Asked: 2018-06-08 06:28:21 +0800 CST

"execute qualquer comando que passará dados não confiáveis ​​para comandos que interpretam argumentos como comandos"

  • 772

Do manual do findutils:

Por exemplo, construções como esses dois comandos

# risky
find -exec sh -c "something {}" \;
find -execdir sh -c "something {}" \;

são muito perigosos. A razão para isso é que o '{}' é expandido para um nome de arquivo que pode conter um ponto e vírgula ou outros caracteres especiais para o shell. Se, por exemplo, alguém criar o arquivo /tmp/foo; rm -rf $HOME, os dois comandos acima poderão excluir o diretório inicial de alguém.

Portanto, por esse motivo, não execute nenhum comando que passará dados não confiáveis ​​(como os nomes dos arquivos) para comandos que interpretam argumentos como comandos a serem interpretados posteriormente (por exemplo, 'sh').

No caso do shell, existe uma solução inteligente para esse problema:

# safer
find -exec sh -c 'something "$@"' sh {} \;
find -execdir sh -c 'something "$@"' sh {} \;

Essa abordagem não garante evitar todos os problemas, mas é muito mais segura do que substituir os dados escolhidos pelo invasor no texto de um comando shell.

  1. A causa do problema é find -exec sh -c "something {}" \;que a substituição de {}não está entre aspas e, portanto, não é tratada como uma única string?

  2. Na solução find -exec sh -c 'something "$@"' sh {} \;,

    • first {}é substituído, mas como {}não está entre aspas, também não "$@"tem o mesmo problema que o comando original? Por exemplo, "$@"será expandido para "/tmp/foo;", "rm", "-rf"e "$HOME"?

    • por que {}não é escapado ou citado?

  3. Você poderia dar outros exemplos (ainda com sh -c, ou sem ele se aplicável; com ou sem findo que pode não ser necessário) onde o mesmo tipo de problema e solução se aplicam, e que são exemplos mínimos para que possamos focar no problema e na solução com pouca distração possível? Veja Maneiras de fornecer argumentos para um comando executado por `bash -c`

Obrigado.

shell

4 respostas

  1. Best Answer

    Isso não está realmente relacionado à citação, mas ao processamento de argumentos.

    Considere o exemplo arriscado:

    find -exec sh -c "something {}" \;

    • Isso é analisado pelo shell e dividido em seis palavras: find, -exec, sh, -c, something {}(sem mais aspas), ;. Não há nada para expandir. O shell é executado findcom essas seis palavras como argumentos.

    • Quando findencontra algo para processar, digamos foo; rm -rf $HOME, ele substitui {}por foo; rm -rf $HOME, e executa shcom os argumentos sh, -c, e something foo; rm -rf $HOME.

    • shagora vê -ce, como resultado, analisa something foo; rm -rf $HOME( o primeiro argumento não opcional ) e executa o resultado.

    Agora considere a variante mais segura:

    find -exec sh -c 'something "$@"' sh {} \;

    • O shell é executado findcom os argumentos find, -exec, sh, -c, something "$@", sh, {}, ;.

    • Agora, quando findfinds foo; rm -rf $HOME, ele substitui {}novamente e é executado shcom os argumentos sh, -c, something "$@", sh, foo; rm -rf $HOME.

    • shvê -ce analisa something "$@"como o comando a ser executado she foo; rm -rf $HOMEcomo os parâmetros posicionais ( começando de$0 ), expande "$@"para foo; rm -rf $HOME um valor único e é executado somethingcom o argumento único foo; rm -rf $HOME.

    Você pode ver isso usando printf. Crie um novo diretório, insira-o e execute

    touch "hello; echo pwned"

    Executando a primeira variante da seguinte forma

    find -exec sh -c "printf \"Argument: %s\n\" {}" \;

    produz

    Argument: .
Argument: ./hello
pwned

    enquanto a segunda variante, executada como

    find -exec sh -c 'printf "Argument: %s\n" "$@"' sh {} \;

    produz

    Argument: .
Argument: ./hello; echo pwned
    • 29

  2. Parte 1:

    findapenas usa a substituição de texto.

    Sim, se você fez sem aspas, assim:

    find . -type f -exec sh -c "echo {}" \;

    e um invasor foi capaz de criar um arquivo chamado ; echo owned, então ele executaria

    sh -c "echo ; echo owned"

    o que resultaria na execução do shell echoentão echo owned.

    Mas se você adicionasse aspas, o invasor poderia simplesmente encerrar suas aspas e colocar o comando malicioso depois, criando um arquivo chamado '; echo owned:

    find . -type f -exec sh -c "echo '{}'" \;

    o que resultaria na execução do shell echo '', echo owned.

    (se você trocou as aspas duplas por aspas simples, o invasor também poderá usar o outro tipo de aspas.)

    Parte 2:

    Em find -exec sh -c 'something "$@"' sh {} \;, o {}não é interpretado inicialmente pelo shell, ele é executado diretamente com execve, portanto, adicionar aspas do shell não ajudaria.

    find -exec sh -c 'something "$@"' sh "{}" \;

    não tem efeito, pois o shell retira as aspas duplas antes de executar find.

    find -exec sh -c 'something "$@"' sh "'{}'" \;

    adiciona aspas que o shell não trata especialmente, então na maioria dos casos significa apenas que o comando não fará o que você deseja.

    Expandir para /tmp/foo;, rm, -rf, $HOMEnão deve ser um problema, porque esses são argumentos para something, e somethingprovavelmente não trata seus argumentos como comandos a serem executados.

    Parte 3:

    Suponho que considerações semelhantes se aplicam a qualquer coisa que receba entrada não confiável e a execute como (parte de) um comando, por exemplo xargse parallel.

    • 3

  3. 1. A causa do problema é find -exec sh -c "something {}" \;que a substituição de {}não está entre aspas e, portanto, não é tratada como uma única string?

    Em certo sentido, mas citar não pode ajudar aqui . O nome do arquivo que é substituído no lugar de {}pode conter qualquer caractere, incluindo aspas . Qualquer que seja a forma de citação usada, o nome do arquivo pode conter o mesmo e "quebrar" a citação.

    2. ... mas como {}está sem aspas, também não "$@"tem o mesmo problema que o comando original? Por exemplo, "$@"será expandido para "/tmp/foo;", "rm", "-rf", and "$HOME"?

    No. "$@"se expande para os parâmetros posicionais, como palavras separadas, e não os divide mais. Aqui, {}é um argumento para findem si mesmo e findpassa o nome do arquivo atual também como um argumento distinto para sh. Está disponível diretamente como uma variável no script de shell, não é processado como um comando de shell em si.

    ... por que {}não é escapado ou citado?

    Não precisa ser, na maioria das conchas. Se você executar fish, ele precisa ser: fish -c 'echo {}'imprime uma linha vazia. Mas não importa se você as cita, o shell apenas removerá as aspas.

    3. Você poderia dar outros exemplos...

    Sempre que você expande um nome de arquivo (ou outra string não controlada) como está dentro de uma string que é considerada algum tipo de código (*) , existe a possibilidade de execução de comandos arbitrários.

    Por exemplo, isso expande $fdiretamente o código Perl e causará problemas se um nome de arquivo contiver aspas duplas. A citação no nome do arquivo encerrará a citação no código Perl, e o restante do nome do arquivo pode conter qualquer código Perl:

    touch '"; print "HELLO";"'
for f in ./*; do
    perl -le "print \"size: \" . -s \"$f\""
done

    (O nome do arquivo deve ser um pouco estranho, pois o Perl analisa todo o código antecipadamente, antes de executá-lo. Portanto, teremos que evitar um erro de análise.)

    Enquanto isso passa com segurança por meio de um argumento:

    for f in ./*; do
    perl -le 'print "size: " . -s $ARGV[0]' "$f"
done

    (Não faz sentido executar outro shell diretamente de um shell, mas se você fizer isso, é semelhante ao find -exec sh ...caso)

    (* algum tipo de código inclui SQL, então XKCD obrigatório: https://xkcd.com/327/ mais explicação: https://www.explainxkcd.com/wiki/index.php/Little_Bobby_Tables )

    • 3

  4. Sua preocupação é precisamente a razão pela qual o GNU Parallel cita a entrada:

    touch "hello; echo pwned"
find . -print0 | parallel -0 printf \"Argument: %s\\n\" {}

    Isso não será executado echo pwned.

    Ele executará um shell, para que, se você estender seu comando, não tenha uma surpresa repentina:

    # This _could_ be run without spawining a shell
parallel "grep -E 'a|bc' {}" ::: foo
# This cannot
parallel "grep -E 'a|bc' {} | wc" ::: foo

    Para mais detalhes sobre o problema de spawning-a-shell, consulte: https://www.gnu.org/software/parallel/parallel_design.html#Always-running-commands-in-a-shell

    • 1

relate perguntas