     | |||||
|
Notícia
Erro em sistemas de arquivos põe Postfix em riscoEsta notícia foi visualizada 1139 vezes.
Wietse Venema, desenvolvedor do Postfix, emitiu um aviso de problema de segurança quando o servidor de e-mail é usado em conjunto com sistemas de arquivos do Linux e do Solaris. Como as versões mais recentes desses sistemas operacionais não seguem mais o padrão POSIX para links, agressores locais podem conseguir anexar arquivos às caixas de mensagens de outros usuários do Postfix. O problema afeta todas as versões mais recentes de variantes do Linux e do Solaris, segundo Venema, mas não as distribuições BSD, AIX, Mac OS X, HP-UX e outros sistemas que seguem os padrões POSIX ou X/Open. Os sistemas afetados criam hard links que, por sua vez, apontam para links simbólicos não como hard links, mas criando um link simbólico sem notificar o usuário disso. Um agressor local poderia explorar isso para anexar arquivos de dados --- sem ter permissão de escrita sobre eles --- à caixa de mensagens do servidor Postfix. Sebastian Krahmer, do Suse, foi quem descobriu esse comportamento. Ele pode ser demonstrado em distribuições Linux atuais (por exemplo, Ubuntu 8.04 e openSUSE 11) em poucos passos: $ PATH=/bin:/usr/bin:$PATH $ mkdir test $ cd test $ touch src $ ln -s src dst1 $ ln dst1 dst2 $ ls -l
Sistemas afetados pela vulnerabilidade criam dois links simbólicos no diretório, apesar de o comando $ ls -l lrwxrwxrwx 2 user users 3 Mmm dd hh:mm dst1 -> src lrwxrwxrwx 2 user users 3 Mmm dd hh:mm dst2 -> src -rw-r--r-- 1 user users 0 Mmm dd hh:mm src No caso do servidor de e-mail do Postfix, um agressor local poderia convencer o Postfix a anexar dados ao arquivo de outro usuário, incluindo a caixa de mensagens, por exemplo. Se o servidor estiver rodando com privilégios de root, isso poderia servir de vetor de ataque para um usuário local independentemente do Postfix. Se o Postfix encontrar um hard link na entrega da mensagem, ele emitirá uma mensagem de erro informando ser impossível entregá-la; por outro lado, links simbólicos seriam permitidos. Dessa forma, servidores que usem o formado Maildir ou um servidor IMAP local, como Cyrus ou Dovecot, não são afetados. Compartilhe
|
|
|||||||||||
|
||||||||||||
| ||||||||||||
Twitte isso!
Posso estar enganado, mas esse comportamento é normal.
Executei exatamente os mesmos comandos só que no “ls -l” incluí o “i” ficando “ls -li”, que pede para ser listados os INODES dos arquivos.
O comando “ln dst1 dst2” criou um HARD LINK do arquivo “dst1” com nome “dst2”. O que seria perfeitamente normal de se esperar. Uso isso desde que aprendi a diferença entre hard link e link simbólico (e isso foi em 1988 num Ultrix - Digital). Gostarei de ver a execução desses comando em *BSD, HPUX e AIX (usando “ls -li"). Vou reler as especificações POSIX sobre isso.
Vejam minha seqüencia de comandos e seus resultados:
fb@mhf:~$ type mkdir
mkdir está hasheado (/bin/mkdir)
fb@mhf:~$ type cd
cd é um comando interno do interpretador
fb@mhf:~$ type touch
touch está hasheado (/usr/bin/touch)
fb@mhf:~$ type ln
ln está hasheado (/bin/ln)
fb@mhf:~$ mkdir test
fb@mhf:~$ cd test
fb@mhf:~/test$ touch src
fb@mhf:~/test$ ln -s src dst1
fb@mhf:~/test$ ln dst1 dst2
fb@mhf:~/test$ ls -li
total 0
1411689 lrwxrwxrwx 2 fb fb 3 2008-08-17 14:01 dst1 -> src
1411689 lrwxrwxrwx 2 fb fb 3 2008-08-17 14:01 dst2 -> src
1411688 -rw-r--r-- 1 fb fb 0 2008-08-17 14:01 src
Usei o comando “type” para mostrar a localização dos comando “mkdir”, “cd”, “touch” e “ln”.
Notem que quando se usa a opção “-i” em “ls -li” a primeira coluna lista o números de inodes. Um hard link é somente uma nova entrada num diretório cujo número de INODE é o mesmo. Um link simbólico é um arquivo cujo conteúdo faz uma referência a localização do arquivo de destino.
Comparando com linguagens de programação um hard link é um novo apontador para a pesma posição de memória e um link simbólico é uma referencia ao nome original da variável.