UCRL-MA-121788
CIAC-2316 R.0
John Fisher
Agosto, 1995
Este documento foi preparado como um trabalho patrocinado por uma agência do Governo dos Estados Unidos. Nem o Governo dos Estados Unidos, nem a Universidade da Califórnia, ou qualquer um de seus empregados, faz qualquer garantia, expressa ou implícita, ou assume qualquer responsabilidade legal ou responsabilidade pela precisão, completude ou utilidade de qualquer informação, aparato, produto ou processo nomeado, ou erpresenta que seu uso não irá infringir direitos de particulares. A referência a qualquer produto, processo ou serviço, por nome de marca, fabricante, ou outro, não necessariamente constitui ou implica um endosso, recomendação ou favorecimento pelo Governo dos Estados Unidos ou a Universidade da Califórnia. Os pontos de vista e opiniões dos autores expressos aqui não necessariamente esclarecem ou refletem os do Governo dos Estados Unidos ou da Universidade da Califórnia, e não podem ser usado como propaganda ou para fins de endosso de produtos.
A referência a qualquer produto comercial específico não constitui ou implica seu endosso, recomendação ou favorecimento pelo CIAC, a Universidade da Califórnia, o Departamento de Energia dos Estados Unidos, ou o Governo dos Estados Unidos.
O trabalho foi executado sob os auspícios do U. S. Department of Energy pelo Lawrence National Laboratory sob o Contract W-7405-Eng-48.
xhost
xauth
xdm
xrsh no X11R5
O X Window goza de grande popularidade com os usuários, em uma variedade de ambientes. Seu modelo cliente/servidor de administração de aplicações permite uma interação poderosa e flexível entre os usuários e os computadores. Infelizmente, o poder vem ao custo da segurança. O X Window, se não for apropriadamente administrado, pode criar uma vulnerabilidade séria. Este trabalho explora a maioria dos problemas de segurança e as soluções no X Window.
Pode parecer estranho que uma interface gráfica possa ser uma séria vulnerabilidade de segurança potencial. Para quem é iniciante, vamos dar uma olhada em como o X Window funciona, e como ele pode ser um problema.
O X Window é, na verdade, em seu nível mais baixo, um protocolo de comunicação, chamado de Protocolo X. Este protocolo é usado em um único computador, ou em uma rede de computadores. Ele não está preso a algum sistema operacional e está disponível em uma ampla variedade de plataformas. O X Window utiliza um modelo Cliente-Servidor para a comunicação de rede. Este modelo permite que um usuário execute um programa em um lugar, mas controle o mesmo a partir de outro lugar diferente.
Contrário à convenção comum de cliente-servidor, o usuário trabalha na
verdade no servidor X, que oferece uma tela, um teclado e um mouse. Ele é
chamao de servidor por que gera as entradas e gerencia as saídas dos clientes.
Os clientes X são aplicações, como o xterm, o emacs ou o xclock.
Eles recebem e processam as entradas e retornam as saídas.
Na maioria dos casos, o servidor e os clientes estão rodando no mesmo computador (host). Mas o Protocolo X é flexível torna possíveis muitas configurações diferentes. De fato, um terminal X é uma tela, teclado e mouse que não tem capacidade computacional. A única coisa que ele pode fazer é processar as mensagens do Protocolo X, que vem de clienets sendo executados em outros sistemas. Mesmo se o servidor está sendo executado em um host, pode ser desejável rodar um cliente em um host remoto, mesmo se estiver em outro prédio ou mesmo em outro estado.
Assim, o que isto tem a ver com segurança do computador? Os clientes que podem executar em um servidor devem ser cuidadosamente controlados. Uma vez que múltiplos clientes estão rodando no mesmo servidor, um controle cuidadoso de sua inter-comunicação deve ser observado. Se um cliente pode enviar informações para outro cliente, ou se um cliente pode capturar informações que eram para outro cliente, o sistema pode ser vulnerável.
Alguns exemplos de comunicação entre o servidor X e o cliente X incluem o seguinte:
Qualquer cliente que pode acessar um servidor pode potencialmente acessar e alterar qualquer comunicação X que esteja ocorrendo. Isto inclue o seguinte:
xterm, que incluem um login e senha
xterm, para executar um
comando.
Claramente, os servidores X são inerentemente perigosos. E o que é pior, muitos servidores são vendidos com o acesso liberado para todo o mundo como configuração padrão.
Qual a melhor forma de proteger um servidor X? Duas abordagens diferentes estão disponíveis: autenticação de host e autenticação de tokens. Cada uma será discutida a seguir.
A autenticação de host é a aceitação podencial de uma conexão baseado em
sua origem. Tipicamente, a origem será determinada pelo endereço IP do host
que faz a conexão. Uma vez que um usuário tenha se conectado a um Servidor X,
o servidor está potencialmente aberto a conexões de qualquer host. Um programa
chamado xhost está disponível para controlar em um nível
host-a-host quais hosts podem apresentar clientes no Servidor X. Mas a maioria
dos hosts suportam múltiplos usuários, e é impossível especificar quais
usuários em um host em particular tem acesso.
A segunda forma de autenticação é a verificação de cada cliente baseado no
token que eles apresentam. Usando um programa chamado xauth, cada
cliente recebe um "magic cookie", um valor aleatório que ele deve oferecer ao
Servidor X para receber permissão de acesso.
Certamente o mecanismo mais utilizado para a segurança do X é o programa
xhost. Ao mesmo tempo que é fácil de usar, o xhost é
um pouco inflexível.
O uso do programa xhost é direto. Cada servidor X mantém uma
lista de hosts que podem ou não ter acesso. O programa xhost é
usado para alterar esta lista. A sintaxe da linha de comando é conforme
segue:
xhost
xhost +bar.foo.org
A partir daí, qualquer usuário e programa naquela máquina pode se comunicar com nosso servidor X.
xhost -bar.foo.org
xhost +
xhost -
Sem nenhum parâmetro, o xhost informa se o controle de acesso
está atualmente liado e quais máquinas tem acesso permitido. Esta é a única
forma que o xhost pode ser executado remotamente, mesmo se a máquina remota
esteja na lista de acesso. Quando o xhost é utilizado, um usuário
de um host não-autorizado que tentar uma conexão receberá a seguinte
resposta:
Xlib: connection to "display:0.0" refused by server
Xlib: Client is not authorized to connect to Server
Note que desabilitar o acesso ao hosts após a conexão ter sido completada não irá afetar as conexões existentes. O server deve ser resetado para interromper conexões já estabelecidas.
Isto é uma funcionalidade. Uma forma inteligente de usar o
xhost é somente ligar o acesso ao hosts pelo período que ele
precisa para iniciar um cliente naquele host. A seguir, o acesso é
desabilitado. O cliente irá continuar a rodar, mas o acesso ao host será
novamente desabilitado.
O controle de acesso xhost é certamente bem fácil de usar. Um
único probrama com uma sintaxe simples é necessário.
A simplicidade do xhost é um benefício e um problema. Todas as
conexões de um host devem ser aceitas ou rejeitadas -- não em uma base
usuário-por-usuário, programa-por-programa ou conexão-por-conexão. Para muitos
ambientes, onde numerosos usuários tem permissão de acesso a um particular
host, esta é uma solução insuficiente. E certamente a maior parte dos
computadores que rodam servidores X tem múltiplas contas de usuário, e qualquer
usuário que pode fazer o logon no computador pode também acessar o servidor X,
como o localhost, evitando completamente o controle de acesso do
xhost.
Infelizemente, muitos servidores X, como os servidores NCD, sistemas SGI, e o Mac X para o Macintosh vem com o controle de acesso desabilitado por padrão. Para usuários não familiarizados com a vulnerabilidade de servidores X, isto pode criar um problema de segurança real.
O xhost tem uma prioridade superior à autenticação de token.
Qualquer usuário pode acrescentar sistemas à lista de acesso do
xhost sem qualquer privilégio especial ou assistência do
administrador do sistema.
O servidor X pode controlar o acesso de um usuário a um servidor X pelo uso
de um magic cookie. Este é essencialmente um código de acesso que
pode ser lido pela máquina, e que é gerado de forma aleatória. Cada cliente X
deve fornecer o mesmo valor de magic cookie para o servidor antes de receber
permissão de acesso. Este valor é armazenado no arquivo
.Xauthority. Ele pode ser ou criado pelo X Display Manager, ou
pelo usuário, no início de cada sessão.
Para o usuário que está logado somente em uma máquina, o reforço de
segurança está presente mas é transparente. Cada novo cliente executado por
aquele usuário naquela máquina irá encontrar o magic cookie e iniciar
sem reclamações. Mas muitos usuário trabalham em múltiplas máquinas ao mesmo
tempo. Como um cliente X em uma máquina remota irá saber qual o magic cookie?
É aí que entra o programa xauth.
O programa xauth é usado para edição e apresentação da informação de
autorização do magic cookie do usuário. Uma vez que o magic cookie seja
apresentado em uma forma que pode ser lida por seres humanos, ele pode ser
enviado a um host remoto. Naquele host remoto, o xauth é usado
novamente para inserir o magic cookie no arquivo .Xauthority do
usuário. Assumindo que um arquivo .rhosts está configurado para o
usuário, passar a informação de autorização para um host remoto (digamos
ahost.foo.org) pode ser feito com um comando:
xauth extract - $DISPLAY | rsh ahost.foo.org xauth merge -
O primeiro comando escreve o magic cookie para o host atual ($DISPLAY) na
saída padrão (o hífen). Esta informação é passada via pipe para o comando de
shell remoto, que executa o comando xauth na máquina ahost.foo.org. O magic
cookie é então lido na entrada padrão (novamente, o hífen) e acrescentado ao
arquivo .Xauthority. O resultado é que o usuário que executou
este comando pode agora executar clientes X em ahost.foo.org, e ter os mesmos
apresentados no Servidor X. É importante ter as permissões configuradas
corretamente no arquivo .Xauthority. Ele deve ter permissão de
leitura/escrita somente para o dono (ou seja, deve ser
"-rw-------"). Além disto, tenha cuidado com o NFS exportando um
diretório home, mesmo como read-only! Ele pode ser montado, permitindo que o
arquivo .Xauthority seja lido.
Note o melhoramento chave aqui. O usuário que executar este comando é o único usuário em ahost.foo.org que pode conectar um cliente X ao servidor X. Todos os outros usuários em ahost.foo.org ainda tem o acesso bloqueado a esta sessão X.
O X Display Manager, xdm, é um cliente que fornece janelas de
login para múltiplos servidores X. Quando um usuário faz login através do X
Display Manager, o xdm escreve um magic cookie no diretório home
do usuário, no arquivo .Xauthority. Os servidores X não são
sempre máquinas stand-alone. Eles podem ser terminais X também, cuja única
função é executar clientes de outros sistemas. Este tipo de máquinas erquer um
xdm para fornecer uma tela de login inicial. Máquinas stand-alone
também podem utilizar o xdm. Além de fornecer uma seqüência de
login mais amigável, o xdm fornece suporte para a autenticação de
magic cookie. Esta autenticação deve primeiro ser ligada pela seguinte entrada
de recurso X no arquivo /usr/lib/X11/xdm/xdm-config:
DisplayManager*authorize: true
Com isto, o xdm irá gerar um novo magic cookie a cada vez que
um usuário faz o login, e armazenar aquele valor no seu arquivo
.Xauthority.
Se o xdm não está sendo utilizado, ainda é possível usar este
tipo de autenticação. Isto será explicado a seguir.
O xdm irá administrar o arquivo .Xauthority para
você, mas se o xdm não estiver sendo usado, ainda é possível ter
autenticação usando magic cookie. O único problema é que em muitos servidores
X11, o usuário precisa gerar o valor chave mágico (o OpenWindows é uma exceção
-- ele irá gerar um magic cookie quando iniciado). Isto pode ser feito de
várias formas. Por exemplo, se o Korn shell está sendo usado, ele possui um
gerador de números aleatórios interno:
randomkey=`ksh -c 'echo $(( $RANDOM * $RANDOM * 2 ))'`
xauth add ${HOST}:0 . $randomkeySe o ksh não estiver senod usado, o clock pode ser usado para obter uma "chave randômica":
randomkey=`date +"%y%m%d%H%M%S"`
xauth add ${HOST}:0 . $randomkeyO xrsh é um script fornecido com o X11R5, no diretório
contrib/clients/xrsh. Para os usuários que executam clientes remotamente via o
rsh, este pode ser um script bem útil. Ele utiliza o xauth para copiar
automaticamente o código do magic cookie para a máquina remota antes de
executar o cliente remoto. Por exemplo, para executar uma janela
xterm no host foo, escreva:
xrsh -auth xauth foo xterm
A autorização é agora feita em uma base usuário-por-usuário, não em uma base host-por-host. Em um ambiente em que um host suporta um grande número de usuários, isto pode ser muito importante.
Os programas xdm e xauth consomem algum tempo
tanto para o administrador quanto para o usuário final, para usar e manter.
Eles exigem um bom entendimento do modelo cliente-servidor do X por parte do
usuário.
Note que a autorização de magic cookie deve ser utilizada em acréscimo à
segurança com xhost. De fato, "xhost -" deve ser
utilizado para desabilitar todo acesso baseado em host.
O programa xterm é usado para fornecer ao usuário um prompt de
linha de comando (um shell no Unix). Como uma grande quantia de interação
usuário/computador crítica ocorre em um prompt de linha de comando, é
importante poder executar este programa com segurança. O programa
xterm possui várias vulnerabilidades que são importantes
mencionar.
Uma funcionalidade de acesso de escrita fornecidda pelo xterm
NÃO deve ser utilizada. Os SendEvents são eventos de teclado e botões que
foram gerados artificialmente (ou seja, não foram gerados por teclado ou
mouse). Por padrão, o xterm recusa todas as solicitações
SendEvent do servidor X. Este comportamento pode ser ignorado, entretanto, de
duas formas. A primeira forma é acrescentar uma definição de um recurso X ou
no arquivo .Xdefaults ou no arquivo
app-defaults/Xterm:
xterm*allowSendEvents: True
A segunda forma de permitir que o Servidor X envie eventos X é através do
menu Main Options do xterm (que pode ser acessado pressionando a
tecla Ctrl ao mesmo tempo que se pressiona o botão esquerdo do mouse). NENHUM
destes deve jamais ser feito, uma vez que eles abre o xterm a
comunicação de outras fontes que não o usuário que iniciou o mesmo.
O acesso de leitura é controlado através de um mecanismo diferente. No menu
Main Options há uma opção "Secure Keyboard". Quando ligada, TODOS os eventos
de keyboard são enviados exclusivamente à janela do xterm (a
interação de mouse não é modificada). Isto evita que outros clientes capturem
eventos de teclado críticos, como a digitação de uma senha. Obviamente, só um
cliente X por vez pode ter esta opção ligada. Esta opção é útil para entrada
de dados, mas é realmente impraticavel para o uso contínuo, por que deve ser
desligada para que se possa interagir com outras janelas.
Os seguintes boletins CIAC foram liberados, que se relacionam diretamente ao X Window:
xterm do X11R5 que não contém o Patch Level
26 contém uma vulnerabilidade de segurança em sua capacidade de log. Esta
vulnerabilidade permite que um usuário não autorizado obtenha acesso de
root. Se o programa xterm contém o bit de permissão
"s" (setuid) configurado, e o comando "xterm -l" cria um arquivo
"XtermLog.axxxx", então a vulnerabilidade pode existir.
As seguintes Notas CIAC são relacionadas diretamente ao X Window:
Todos os Boletins e Notas acima estão disponíveis no servidor Web do CIAC, em http://ciac.llnl.gov.
| Telefone | (510) 422-8193 |
| Fax | (510) 423-8002 |
| STU-III | (510) 423-2604 |
| Correio Eletrônico | ciac@llnl.gov |
| SKYPAGE de Emergência | 800-SKYPAGE pin# 855-0070 |
| Servidor FTP Anônimo | ciac.llnl.gov (IP 128.115.19.53) |
| BBS | (510) 423-3331 (9600 Baud) (510) 423-4753 (2400 Baud) |