Quão seguro é catar um arquivo arbitrário?

Question

Às vezes, quando eu cat um arquivo binário por engano, meu terminal fica distorcido. Nada que um reset rápido não consiga consertar, mas um atacante não poderia teoricamente criar um arquivo que, quando exibido em um terminal, executaria algum código arbitrário? Através de uma exploração no emulador de terminal ou de outra forma.

    

Answer 1

Se tal saída pode ser explorada depende do programa do terminal, e o que esse terminal faz dependendo dos códigos de escape que estão sendo enviados. Não tenho conhecimento de programas de terminal que tenham esses recursos exploráveis, e o único problema agora seria se houvesse um estouro de buffer desconhecido ou algo assim, que pudesse ser explorado.

Com alguns terminais hardware mais antigos, isso pode ser um problema quando você programa, por ex. teclas de função com esse tipo de seqüência de escape, armazenando uma sequência de comandos para essa chave no hardware. Você ainda precisaria de um toque físico para ativar isso.

Mas sempre há (como Hauke tão claramente marcado como 'braindead') pessoas dispostas a adicionar tal característica se isso resolve um problema para elas, não entendendo a brecha que elas criam. Na minha experiência com software de código aberto é que, por causa dos muitos olhos que olham para o código, é menos provável que isso aconteça como acontece com o código fechado. (Eu me lembro que no programa de e-mail no Irix da Silicon Grahpics, em meados da década de 1990, você poderia incluir comandos para serem executados na máquina do receptor, caminhos reais para executáveis, ....)

    

Answer 2

A maioria dos emuladores de terminal retornará alguma resposta, se receberem certas seqüências de escape (dê uma olhada no controle xterm documentação de seqüências ). Por exemplo, você pode enviar \e[0c para um emulador semelhante ao VT100 e enviará de volta os atributos do dispositivo, algo como \e[?1;2c (Isso é provavelmente o que Keith observou). Mas essas respostas não são seqüências arbitrárias. Ainda assim, ter um executável chamado 2c em algum lugar do seu sistema que faz algo fatal é uma má ideia.

Atualização: Os riscos são de fato maiores do que eu pensava, devido à possibilidade de definir o título de uma janela xterm e enviar de volta o título usando seqüências de escape apropriadas ( link ). Em contraste com o exemplo acima, o título pode ser uma string quase arbitrária.

    

Answer 3

Isso muda o título do terminal no GNOME Terminal 3.6.1, a menos que seja substituído por algo como PS1 :

printf "3]2;Script Kiddie was here
printf "3]2;Script Kiddie was here
printf "3]2;Script Kiddie was here
printf "3]2;Script Kiddie was here%pre%7" > test.bin
cat test.bin
7"
7" > test.bin
cat test.bin
7"

Agora abra uma nova janela do Terminal GNOME para testar a versão cat :

%pre%

Sim, isso também define o título do terminal.

Costumava haver um problema de segurança com um código de escape resultando no título sendo impresso na linha de comando , então você poderia efetivamente criar um arquivo, que quando cat ed imprimiria (não tenho certeza se você poderia colocar uma nova linha), comandos arbitrários. Ai!

    

Answer 4

Embora o uso de cat possa não resultar na execução de códigos, os códigos de escape serão processados, para que você possa ser induzido a pensar que o script é inofensivo quando, na verdade, é malicioso.

Aqui está um exemplo de comando que você pode executar, que criará um script de shell "mal-intencionado":

echo -e '#!/bin/sh\necho "...doing something bad here..."\nexit\n3[A3[Aecho "Hello dear reader, I am just a harmless script, safe to run me!"' > demo.sh
chmod a+x demo.sh

Quando você inspeciona o arquivo, parece inofensivo:

$ cat demo.sh
#!/bin/sh
echo "Hello dear reader, I am just a harmless script, safe to run me!"

Mas você deve executá-lo ...

$ ./demo.sh 
...doing something bad here...

O script funciona incluindo códigos de escape brutos para mover o cursor para cima de algumas linhas, de modo que o restante do script seja escrito sobre a parte superior do código malicioso, ocultando-o.

Quase qualquer outro programa irá revelar o roteiro para o que é. Somente programas que não processam o conteúdo do arquivo (como cat , more e less -r ) produzirão a saída enganosa.

Observe que tail e head também produzem a mesma saída enganosa. Usar "menos + F" é, portanto, mais seguro que "tail -f".

    

Answer 5

Eu definitivamente experimentei xterm inserir caracteres arbitrários em si mesmo como se eu os tivesse digitado. E, ocasionalmente, isso aparentemente incluiu o caractere de nova linha, de modo que recebi ngwerm:0riu: command not found como resposta. Não vejo razão para que alguém não possa criar um arquivo que envie comandos específicos e prejudiciais. Então, sim, pelo menos alguns terminais são suscetíveis a ataques com impacto arbitrário.

    

Answer 6

Bem, um emulador de terminal basicamente imprime os caracteres enviados para ele.

Qualquer coisa além de simplesmente imprimir um caractere na posição atual, como definir uma nova posição, mudar a cor, mudar o título, etc., é feito por seqüências de escape.

O conjunto de sequências de escape suportadas geralmente consiste em padrões bem definidos, como ANSI , que não define uma maneira de começar outros processos. Embora seja possível implementar tal sequência, não estou ciente de nenhum emulador de terminal permitindo intencionalmente tais coisas.

Em teoria, um bug como um buffer overflow pode ser usado para disparar funcionalidades arbitrárias. Mas isso seria possível em praticamente qualquer outro binário também.

    

Answer 7

Em geral, geralmente não há risco de catalogar um arquivo arbitrário. Meu método usual para analisar um arquivo é fazer o seguinte:

$ file <mystery file>
$ strings <mystery file> | less

O acima permite-me determinar o tipo de um ficheiro através do comando file e o comando strings permite-me descarregar quaisquer cadeias identificáveis de possíveis ficheiros binários que eu não tenha a certeza sobre a sua linhagem.

exemplo

saída de arquivo

$ file /bin/ls
/bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped

saída de strings

$ strings /bin/ls|less
...
across
vertical
single-column
force
never
auto
if-tty
slash
%b %e  %Y
%b %e %H:%M
long-iso
main
posix-
sort_files
?pcdb-lswd
dev_ino_pop
Try '%s --help' for more information.
Usage: %s [OPTION]... [FILE]...
List information about the FILEs (the current directory by default).
Sort entries alphabetically if none of -cftuvSUX nor --sort.
Mandatory arguments to long options are mandatory for short options too.
  -a, --all                  do not ignore entries starting with .
  -A, --almost-all           do not list implied . and ..
...