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