Como evitar ataques de sequência de escape nos terminais?

Lendo os detalhes do CVE-2009-4487 (que trata do perigo de seqüências de escape nos arquivos de log) , fico um pouco surpreso.

Para citar CVE-2009-4487 :

O nginx 0.7.64 grava dados em um arquivo de log sem limpar caracteres não imprimíveis, o que pode permitir que atacantes remotos modifiquem o título de uma janela ou possivelmente executem comandos arbitrários ou sobrescrevam arquivos, através de uma solicitação HTTP que contém uma sequência de escape para um emulador de terminal.

Claramente, não se trata realmente de uma falha de segurança no nginx, mas nos emuladores de terminal.

Certamente, talvez catum arquivo de log para o terminal ocorra apenas por acidente, mas grepum arquivo de log é bastante comum. lesstalvez higienize as seqüências de escape, mas quem sabe quais comandos do shell não mudam as seqüências de escape ...

Tendo a concordar com a resposta do verniz :

A sabedoria das fugas de resposta de terminal em geral tem sido questionada em intervalos regulares, mas ainda assim nenhum dos principais programas de emulação de terminal achou adequado descartar essas seqüências, provavelmente em uma tentativa equivocada de compatibilidade com a tecnologia não usada nos anos 1970. [..] Em vez de culpar todo e qualquer programa que grava arquivos de log, seria muito mais produtivo, do ponto de vista da segurança, fazer com que os programas de emulação de terminal parem de fazer coisas estúpidas e, assim, conserte este e outros problemas de segurança uma vez. e para todos.

Assim, minhas perguntas:

Como posso proteger meu xterm, de modo que não seja mais possível executar comandos ou substituir arquivos por meio de seqüências de escape?

Quais emuladores de terminal para o X estão protegidos contra esse ataque?

Os terminais VT100 (que todos os emuladores modernos de terminal imitam até certo ponto) suportam vários comandos problemáticos, mas os emuladores ou distribuições modernos desativam os mais problemáticos e os menos úteis. Aqui está uma lista não exaustiva de sequências de escape potencialmente arriscadas (sem incluir as que simplesmente tornam a exibição ilegível de alguma forma):

• Os comandos arbitrários do arquivo de log em rxvt e Eterm relatados por HD Moore . Esses são realmente grandes erros, felizmente corrigidos por muito tempo.
• O comando answerback, também conhecido como Return Terminal Status, chamado por ENQ( Ctrl+E). Isso insere o texto no terminal como se o usuário o tivesse digitado. No entanto, este texto não está sob controle do atacante: é o próprio nome do terminal, geralmente algo como xtermou screen. No meu sistema (compressão Debian), o xterm retorna a string vazia por padrão (isso é controlado pelo answerbackStringrecurso).
• Os comandos Enviar Atributos do Dispositivo ESC [ ce amigos. O terminal responde com ESC [ … c(onde …pode conter dígitos e sinais de pontuação ASCII apenas). Essa é uma maneira de consultar alguns recursos do terminal, principalmente obsoletos, mas talvez usados ​​por aplicativos antigos. Novamente, a resposta do terminal é indistinguível da entrada do usuário, mas não está sob controle do invasor. A sequência de controle pode parecer uma tecla de função, mas somente se o usuário tiver uma configuração incomum (nenhuma das configurações usuais que encontrei possui uma sequência de escape válida da tecla de função que é um prefixo da resposta do terminal).
• As várias funções de controle do dispositivo (o DCS escapa, começando com ESC P).
  • Não sei que mal pode ser causado DECUDK(defina teclas definidas pelo usuário) em um emulador de terminal típico.
  • DECRQSS(Request Status String) é outro comando ao qual o terminal responde com uma sequência de escape, desta vez começando com \eP; isso pode ser problemático, pois \ePé uma chave válida ( Alt+ Shift+ P).
  • O Xterm possui mais dois recursos experimentais: ESC P + p …e ESC P + q …, para obter e definir seqüências de caracteres termcap. A partir da descrição, isso pode ser usado pelo menos para modificar o efeito das teclas de função.
• Vários comandos do relatório de status: ESC [ … n(Relatório de status do dispositivo). O terminal responde com uma sequência de escape. A maioria dessas seqüências de escape não corresponde às seqüências de escape das teclas de função. Parece problemático: o relatório ESC [ 6 né da forma onde e são seqüências de dígitos, e isso pode parecer com alguns modificadores.ESC [ x ; y RxyF3
• Comandos de manipulação de janelas ESC [ … t.
  • Alguns deles permitem que a janela do xterm seja redimensionada, iconificada etc., o que é perturbador.
  • Alguns deles fazem com que o terminal responda com uma sequência de escape. A maioria dessas seqüências de escape parece de baixo risco, no entanto, existem dois comandos perigosos: as respostas ESC [ 2 0 te ESC [ 2 1 to rótulo e o título do ícone da janela do terminal, respectivamente, e o atacante pode escolher esses.
  • Pelo menos no Debian squeeze, o xterm ignora esses comandos por padrão; eles podem ser ativados configurando o allowWindowOpsrecurso ou seletivamente através do disallowedWindowOpsrecurso. O Gnome-terminal no Ubuntu 10.04 implementa até as respostas ao título por padrão. Não verifiquei outros terminais ou versões.
• Comandos para definir o título do terminal ou o nome do ícone. No xterm e na maioria dos outros terminais X, eles são . Em Tela, a sequência de escape é . Acho que a preocupação com esses comandos é superestimada. Embora eles permitam uma certa quantidade de travessuras, qualquer página da Web tem o mesmo problema. Atuar em uma janela baseada apenas em seu título e não em sua classe é semelhante a abrir um arquivo cujo nome foi dado a você por uma parte não confiável, ou não citar uma expansão variável em um script de shell ou dar um tapinha no nariz de um cão raivoso - não reclame se você for mordido.ESC ] digit ; title ESC \ESC k title ESC \

Acho a resposta de Varnish falsa. Parece que ele está tentando mudar a culpa, ou no modo nazista de segurança (qualquer preocupação de segurança, genuína ou não, justifica o blackballing de um recurso).

A sabedoria das fugas de resposta de terminal em geral tem sido questionada em intervalos regulares, mas ainda assim nenhum dos principais programas de emulação de terminal achou adequado descartar essas seqüências, provavelmente em uma tentativa equivocada de compatibilidade com a tecnologia não usada nos anos 1970. (…)
Em vez de culpar todo e qualquer programa que grava arquivos de log, seria muito mais produtivo, do ponto de vista da segurança, fazer com que os programas de emulação de terminal parem de fazer coisas estúpidas e, assim, conserte esse e outros problemas de segurança de uma vez e para todos.

Muitas das respostas são recursos úteis: um aplicativo precisa saber coisas como a posição do cursor e o tamanho da janela. Definir o título da janela também é muito útil. Seria possível confiar inteiramente nas ioctlchamadas para elas, no entanto, isso exigiria código e utilitários adicionais para fazer essas ioctlchamadas e transformá-las em texto no estilo unix, transmitindo descritores de arquivos. Mudar essas interfaces agora seria muito trabalhoso, com pouco benefício.

Os arquivos de texto não devem conter caracteres não imprimíveis, como caracteres de controle. Geralmente, espera-se que os arquivos de log sejam arquivos de texto. Os arquivos de log não devem conter caracteres de controle.

Se você está preocupado que um arquivo pode conter sequências de escape, abra-o em um editor, ou vê-lo com lesssem -rou -Ropção, ou visualizá-lo através de cat -v.

Não é tão simples assim; muitas pessoas têm código para definir o xtermtítulo como parte do prompt ou etc., e por muito boas razões (como qualquer pessoa que esteja shutdownna máquina errada da janela do terminal errada pode lhe dizer!). Consertá-lo adequadamente envolve, portanto, a introdução de contextos de segurança e, dessa forma, complicar seriamente a interação entre shells e emuladores de terminal e provavelmente os arquivos de pontos das pessoas. Ou você pode optar pela solução de baixo custo para higienizar qualquer coisa que possa ser exibida em um terminal; isso se reduz amplamente a caracteres de controle que escapam, o que provavelmente deve ser feito de qualquer maneira apenas para destacá-los (já que em um arquivo de log eles podem indicar alguém tentando injetar código de shell).

(À parte, o punycode é uma instância mais grave do mesmo tipo de problema - e, no entanto, se tornou um padrão oficial. Às vezes, a segurança se resume a mitigar projetos inseguros que estão fora do controle de alguém.)