16 julho 2007

sudo - Voltando à sua segurança.

Boas, estive recentemente de novo envolvido em mais uma discussão sobre o comando sudo muito em voga ultimamente. Muitos aspectos do funcionamento foram discutidos e muitas possíveis situações foram imaginadas dando discussão ao que iria acontecer em cada uma delas. A discussão foi bastante produtiva.

Foi questionada a situação do sudoer usar a sua própria password de login para usar o sudo, e na sequência foi questionada a real segurança das passwords, não se encontrando à partida nenhuma falha grave nesta situação da password, pelo menos não mais grave que em qualquer outro sistema de autorização por password.

Contudo, encontrou-se um ponto fraco no sudo, que é este descrito nesta pequena parcela do manual dele:

""Once a user has been authenticated, a timestamp is updated and the user may then use sudo without a password for a short period of time (15 minutes unless overridden in sudoers)""

Então, depois da 1ª autenticação, o utilizador pode usar sudo sem password durante alguns minutos.
Atenção. Este é um detalhe que poderá vir a ser explorado por malware.

A preocupação prende-se com estes factos:
Neste momento o nº de utilizadores de gnu/linux está a crescer, e ainda bem... uma distro e suas variantes, que estão a ficar bastante conhecidas e utilizadas, usa sudo para todas as operações de sistema (vocês sabem qual é), além de outras distros que apesar de ainda usarem o método convencional, também já vêm com a opção de se usar sudo em vez da conta do root, a Debian está incluída nestas distros. Como resultado, já existe muitos utilizadores a usarem o comando sudo sempre que precisam mexer no sistema.
Outra situação já bem conhecida é que um programa pode fazer muito mais do que aparenta fazer, quer isto dizer que um joguinho engraçado com uns balões a rebentar pode estar a fazer outras coisas enquanto se joga com ele, e o fechar da janela dum programa não obriga a que este termine de funcionar, portanto o tal joguinho pode ficar com funções activas mesmo depois de o fecharmos.
Imaginemos um utilizador ciente que fez uma boa escolha no seu sistema operativo para aceder à internet com o seu Pc pessoal, encontra este joguinho, acha-lhe graça e por via de dúvidas, instala-o apenas para a sua área pessoal, evitando assim enfiar programas desconhecidos na área do seu sistema, e usando-o apenas como utilizador normal. Em principio, mesmo que este jogo seja um trojan e tenha intenções de fazer o mal, só iria conseguir danificar a área pessoal desse utilizador, mas se por acaso esse utilizador for um sudoer, o programa pode ter sido "ensinado" a testar o comando sudo em períodos regulares, fazendo-se de avestruz à espera duma janela de oportunidade, e essa oportunidade vai surgir nos minutos após o utilizador ter usado o comando sudo, pois nenhuma password vai ser pedida enquanto decorrer o timestamp do sudo, e durante este tempo o trojan pode atacar.
Durante este tempo o trojan pode modificar scripts, alterar configurações, podendo mesmo instalar outros malwares pondo-os a arrancar com os scripts de init, ficando estes malwares com previlégios avançados e a arrancar junto com o arranque do sistema, e apartir daqui pode-se esperar de tudo: backdoors abertos, spywares a recolher informação confidencial e a enviá-la para fora, o nosso sistema a virar-se contra nós, tudo do pior que se possa imaginar...

Se começarem a surgir trojans a explorar este timestamp do sudo, esses trojans poderão funcionar como a ignição que vai permitir a infecção por outros tipos de malware, e seria triste ver um dia utilizadores que mudaram para gnu/linux terem que recorrer outra vez à utilização de anti-virus e anti-spywares.

Para eliminar esta possível vulnerabilidade existem duas opções:
1ª opção-- Eliminar o timestamp, colocando o valor do mesmo a zero
timestamp_timeout "0"
Isto vai fazer que seja obrigatório inserir password a cada comando sudo, e acredito que haja a quem esta situação não agrade.

2ª opção-- Fazer o sudo apenas aceitar novos comandos dentro do timestamp se eles vierem do mesmo terminal que iniciou o timestamp. Isto quer dizer que só comandos executados na mesma consola onde foi dado o primeiro comando (o que pediu password), serão aceites sem password. E se for aberta uma 2ª consola, um comando sudo pedirá password mesmo estando ainda dentro do timestamp. ficará mais parecido com o método tradicional em que se abre uma consola e se muda para root com o comando "su". Esta opção irá também bloquear acessos abusivos ao sudo por qualquer outro programa.
Isto é conseguido colocando em "on" a flag tty_tickets:

tty_tickets
if set, users must authenticate on a per-tty basis. Normally, sudo uses a directory in the ticket dir with the same name as the user running it. With this flag enabled, sudo will use a file named for the tty the user is logged in on in that directory. This flag is off by default.


Se resolverem alterar as vossas configurações do sudo, vejam sempre man sudo e man sudoers para não cometerem erros ao editar o ficheiro /etc/sudoers, o qual deve ser editado com o programa "visudo", pois este verifica a sintaxe do ficheiro ao gravar alertando se o mesmo tem erros de sintaxe.

Isto claro está, será sempre preferível não instalar nada de origem duvidosa, mas como que cada vez mais aparecem por todo o lado programas feitos para linux, vamos acreditar que alguns deles possam ser irresistíveis.

Também existem aqueles que têm o seu sudo configurado para apenas aceder a comandos de root que não são verdadeiramente perigosos, como o mount/unmount. Nestes casos específicos, não consigo ver à partida perigos em usá-lo, pois qualquer comando mais perigoso lançado por um trojan seria ignorado desde que não estivesse na lista de comandos permitidos.


Nota: Esta informação e recomendação é meramente por prevenção, não tenho qualquer indicação que possam existir malwares a explorar esta situação, apenas alerto para a possibilidade de isso um dia vir a acontecer.

Abraços
ArameFarpado

16 comentários:

Como se muda o timestamp? Estive a ver as manpages, mas não encontrei nada que explique a sintaxe.

poix, a sintaxe é danada neste ficheiro.
só nalguns ensaios que fiz, deu para perceber alguma coisa:
o visudo testa-te a sintaxe do ficheiro ao saires. o sudo não consegue funcionar se o ficheiro tiver erros na sintaxe, parece que não tem mesmo como contorná-los.

então:
timestamp_timeout é um integer, logo tem que ter um valor numérico inteiro, e no man sudoers fala que intergers têm que estar no meio de aspas

então a sintaxe é
timestamp_timeout "0"

só que timestamp_timeout não pode ficar numa linha separada.
deverá já existir uma linha longa com as opções configuradas à tua conta, há que adicionar este parametro à linha existente, e mantê-la como uma linha única na mesma.

o mesmo se vai passar para o tty_tickets on, mas aqui não sei se o on precisa ficar entre aspas... é questão de lerem o man sudoers com atenção.

Eu experimentei por só timestamp_timeout "0", mas dá erro. A sintaxe correcta é:
Defaults timestamp_timeout=0

Para o tty_tickets é que não sei.

Se o sudo tiver esta falha, então o gksudo também a deve ter, não?

Boa, descubriste essa treta mais depressa do que eu :)
fixe

gksudo? desconheço... podes dar uma descrição de como funciona?
em principio se for apenas uma gui de acesso ao sudo, corrigindo o sudo deverá corrigir o outro.

Mais ou menos. É útil para executares atalhos do desktop com os mesmos privilégios que o sudo. Se criares um atalho para o nautilus correr com privilégios de root, metes no comando gksudo nautilus.

gksu is a frontend to su and gksudo is a frontend to sudo. Their primary purpose is to run graphical commands that need root without the need to run an X terminal emulator and using su directly.

Então é isso. basta alterar o sudo que estarás a alterar também o gksudo

Já agora, convém testares se a alteração fez efeito. para isso lança uns comandos só de informação como
sudo lsmod (por exemplo)

mas, não achas preferível a outra solução do tty_tickets ?
eu acho que ficava quase igual ao método tradicional.

se amanhã precisares alterar qq coisa que precise de vários comandos, vai ser uma seca estar sempre a meter a password. :)

Eu tinha percebi essa "vulnerabilidade" há alguns meses e não achei nada seguro continuar usando ele com essa configuração. Deixei de usar o sudo a um bom tempo, atualmente me logo como root em um emulador de terminal quando preciso usar alguns comandos especiais, se tomar cuidado, é bem mais seguro e prático que a configuração padrão do sudo.

Bruno Tsubouchi (isto hoje está cheio de brunos ;) )

a configuração default varia de distro para distro.
por exemplo, no meu sistema Debian, o sudo vem apenas a permitir usar mount e unmount
e ainda por cima o mount tem a opção noexec.

se eu quisesse mesmo substituir o su pelo sudo, tinha que 1º configurar os comandos que queria usar.

isto depende dumas distros para outras, nada como ver primeiro o que o nosso sudo pode fazer e se acharmos que ele tem poderes mais perigosos, então tomar precauções.

Abraços

Ok.... timeout :)

antes de irem já a correr fazer alterações, até porque não há pressa, examinem primeiro o que o sudo no vosso sistema pode fazer, consultando o que está em /etc/sudoers

é que nem todos os comandos de root podem fazer mal; mount, unmount, modprobe, lsmod, rmmod, e mais alguns não podem provocar estragos no sistema sozinhos. olhem para cada comando autorizado e vejam o que cada um faz para decidirem se eles podem mudar o sistema ou não.

agora se usam uma distro em que não se usa a conta root e faz-se tudo com sudo, então podem crer que esse sudo não tem permissões lá muito limitadas como originalmente deveria ter, e nessas, o risto é real.
pelo que tenho lido do sudo, deu-me a ideia que o sudo não foi pensado para substituir completamente a conta root, ou não traria o timestamp ligado a 15 minutos como default.
ele tem as defesas, só que estão desactivadas por default.

é como disse antes noutro artigo:
aumentar as facilidades leva a baixar a segurança. se começamos a mudar a maneira normal do linux funcionar, então a sua robusta segurança vai ao chão... isso é limpinho.

Abraços

João Grilo disse...
16 julho, 2007 10:57
 

Fiquei curioso com este post e fui testar aqui no Ubuntu que uso no trabalho. Acabei por confirmar a ideia que sempre tinha do sudo, é "session-oriented" (se é que se pode dizer isto): por cada terminal é pedida a password e o ticket é específico para esse terminal, ora confirmem lá :)

Confirmo isso agora mesmo João. Eu uso o Kubuntu 7.04 e testei o sudo numa janela de terminal. Imediatamente a ter executado uma função sudo abri outra janela e executei essa mesma função com o sudo. De ambas as vezes este pediu-me password. Por isso, como sugestão a quem usa Ubuntu e variantes deste, executem comandos com sudo, gksudo, e kdesu num terminal e sem privilégios noutro.

Rodrigo Leão disse...
16 julho, 2007 13:28
 

Pois é, aqui no Ubuntu 7.04 essa função da flag tty_tickets já é "on" por default.

""Pois é, aqui no Ubuntu 7.04 essa função da flag tty_tickets já é "on" por default.""

Boa, não sabia desse pormenor, e quando o tentei saber, não obtive uma resposta concreta... Então as novas versões de ubunto já vêm com uma das protecções activa.
Assim a situação já está aceitável, e fica equivalente ao processo original de mudar para root numa consola.

É bom saber destas confirmações.