Virus en GNU / Linux: feito ou mito?

Sempre que rematou o debate virus y GNU / Linux non tarda en aparecer o usuario (normalmente Windows) que di:

«En Linux non hai virus porque os creadores destes programas maliciosos non perden o tempo facendo algo por un sistema operativo que case ninguén usa »

Ao que sempre respondín:

"O problema non é iso, pero os creadores destes programas maliciosos non perderán o tempo creando algo que se corrixirá coa primeira actualización do sistema, incluso en menos de 24 horas"

E non me equivoquei, xa que este excelente artigo publicado no número 90 (Ano 2008) da revista Todo Linux. O seu actor david santo orcero fornécenos dun xeito técnico (pero fácil de entender) a explicación por que GNU / Linux carece deste tipo de software malicioso.

100% recomendado. Agora terán material máis que convincente para silenciar a quen fale sen unha base sólida sobre este tema.

Descargar artigo (PDF): Mitos e feitos: Linux e virus

 

EDICIÓN:

Aquí está o artigo transcrito, xa que consideramos que é moito máis cómodo ler deste xeito:

================================================== ======================

O debate sobre Linux e virus non é nada novo. Cada certo tempo vemos un correo electrónico nunha lista onde se pregunta se hai virus para Linux; e automaticamente alguén responde afirmativamente e afirma que se non son máis populares é porque Linux non está tan estendido como Windows. Tamén hai frecuentes comunicados de prensa de desenvolvedores antivirus que din que lanzan versións de virus Linux.

Persoalmente tiven discusións puntuais con diferentes persoas por correo ou por lista de distribución sobre o tema de se existen ou non virus en Linux. É un mito, pero é difícil derrubar un mito ou, mellor dito, unha farsa, especialmente se é causado por interese económico. Alguén está interesado en transmitir a idea de que se Linux non ten este tipo de problemas é porque moi pouca xente o usa.

No momento de publicar este informe, gustaríame escribir un texto definitivo sobre a existencia de virus en Linux. Por desgraza, cando a superstición e o interese económico están desenfreados, é difícil construír algo definitivo.
Non obstante, trataremos de facer un argumento razoablemente completo aquí para desarmar os ataques de quen queira argumentalo.

Que é un virus?

Primeiro de todo, imos comezar definindo o que é un virus. É un programa que se copia a si mesmo e execútase automaticamente e que ten como obxectivo alterar o funcionamento normal dunha computadora, sen o permiso nin o coñecemento do usuario. Para iso, os virus substitúen os ficheiros executables por outros infectados co seu código. A definición é estándar e é un resumo dunha liña da entrada de Wikipedia sobre virus.
A parte máis importante desta definición, e o que diferencia o virus doutro malware, é que se instala un virus sen o permiso ou coñecemento do usuario. se non se instala, non é un virus: pode ser un rootkit ou un troiano.

Un rootkit é un parche do núcleo que permite ocultar certos procesos das utilidades da área de usuario. Noutras palabras, trátase dunha modificación do código fonte do núcleo cuxo propósito é que as utilidades que nos permiten ver o que se está executando nun momento dado non visualicen un determinado proceso ou un determinado usuario.

Un troiano é análogo: é unha modificación do código fonte dun servizo específico para ocultar certa actividade fraudulenta. En ambos os casos, é necesario obter o código fonte da versión exacta instalada na máquina Linux, corrixir o código, recompilalo, obter privilexios de administrador, instalar o executable remendado e inicializar o servizo –no caso do troiano– ou o sistema operativo. completo - no caso de
rootkit–. O proceso, como vemos, non é trivial e ninguén pode facer todo isto "por erro". Ambos requiren na súa instalación que alguén con privilexios de administrador execute conscientemente unha serie de pasos para tomar decisións de carácter técnico.

O que non é un matiz semántico sen importancia: para que un virus se instale, todo o que temos que facer é executar un programa infectado como usuario común. Por outra banda, para a instalación dun rootkit ou un troiano, é esencial que un humano malicioso entre persoalmente na conta raíz dunha máquina e, de xeito non automatizado, realice unha serie de pasos que son potencialmente detectables. un virus esténdese de xeito rápido e eficiente; un rootkit ou un troyano precisan que vaian detrás de nós especificamente.

Transmisión de virus en Linux:

Polo tanto, o mecanismo de transmisión dun virus é o que realmente o define como tal e é a base da súa existencia. un sistema operativo é máis sensible aos virus canto máis doado é desenvolver un mecanismo de transmisión eficiente e automatizado.

Supoñamos que temos un virus que quere propagarse. Supoñamos que o lanzou un usuario normal, inocentemente, ao lanzar un programa. Este virus ten exclusivamente dous mecanismos de transmisión:

• Replicarse tocando a memoria doutros procesos, ancorándose a eles en tempo de execución.
• Abrindo os executables do sistema de ficheiros e engadindo o seu código –carga de pago– ao executable.

Todos os virus que podemos considerar como tales teñen polo menos un destes dous mecanismos de transmisión. O Os dous. Xa non hai mecanismos.
En canto ao primeiro mecanismo, recordemos a arquitectura de memoria virtual de Linux e como funcionan os procesadores intel. Estes teñen catro aneis, numerados do 0 ao 3; canto menor sexa o número, maiores serán os privilexios que ten o código que se executa nese anel. Estes aneis corresponden cos estados do procesador e, polo tanto, co que se pode facer cun sistema nun anel específico. Linux fai uso do anel 0 para o núcleo e do anel 3 para os procesos. non hai ningún código de proceso que se execute no anel 0 e non hai ningún código do núcleo que funcione no anel 3. Só hai un punto de entrada ao núcleo desde o anel 3: a interrupción de 80 horas, que permite saltar desde a zona onde está o código de usuario á área onde está o código do núcleo.

A arquitectura de Unix en xeral e Linux en particular non fai factible a propagación de virus.

O núcleo ao usar memoria virtual fai que cada proceso crea que ten toda a memoria para si. Un proceso –que funciona no anel 3– só pode ver a memoria virtual que se lle configurou, para o anel no que opera. Non se trata de protexer a memoria dos outros procesos; é que para un proceso a memoria dos demais está fóra do espazo de enderezos. Se un proceso superase todos os enderezos de memoria, nin sequera sería capaz de facer referencia a unha dirección de memoria doutro proceso.

Por que isto non se pode enganar?
Para modificar o comentado –por exemplo, xerar puntos de entrada no timbre 0, modificar vectores de interrupción, modificar memoria virtual, modificar LGDT ... - só é posible desde o timbre 0.
É dicir, para que un proceso poida tocar a memoria doutros procesos ou o núcleo, debería ser o propio núcleo. E o feito de que haxa un único punto de entrada e que os parámetros se pasen a través de rexistros complica a trampa; de feito, o que hai que facer pásase por rexistro, que logo se implementa como caso na rutina de atención. a interrupción das 80 horas.
Outro escenario é o caso de sistemas operativos con centos de chamadas indocumentadas para soar a 0, onde isto é posible - sempre pode haber unha chamada esquecida mal implementada na que se poida desenvolver unha trampa - pero no caso dun sistema operativo un mecanismo de paso tan sinxelo, non o é.

Por este motivo, a arquitectura de memoria virtual impide este mecanismo de transmisión; ningún proceso - nin sequera aqueles con privilexios de root - ten un xeito de acceder á memoria doutros. Poderiamos argumentar que un proceso pode ver o núcleo; teno mapeado desde o seu enderezo de memoria lóxica 0xC0000000. Pero, debido ao anel do procesador que funciona, non pode modificalo; xeraría unha trampa, xa que son áreas de memoria que pertencen a outro anel.

A "solución" sería un programa que modifica o código do núcleo cando se trata dun ficheiro. Pero o feito de que se recompilen fai que sexa imposible. O binario non se pode parchear, xa que hai millóns de núcleos binarios diferentes no mundo. Simplemente que ao recompilalo puxeran ou eliminaran algo do executable do núcleo ou cambiaran o tamaño dunha das etiquetas que identifican a versión da compilación (algo que se fai incluso involuntariamente) o parche binario non se puido aplicar. A alternativa sería descargar o código fonte de Internet, parchealo, configuralo para o hardware adecuado, compilarlo, instalalo e reiniciar a máquina. Todo isto debería facelo un programa automaticamente. Todo un reto para o campo da Intelixencia Artificial.
Como podemos ver, nin sequera un virus como root pode saltar esta barreira. A única solución que queda é a transmisión entre ficheiros executables. O que tampouco funciona como veremos a continuación.

A miña experiencia como administrador:

Hai máis de dez anos que levo xestionando Linux, con instalacións en centos de máquinas en centros de datos, laboratorios de estudantes, empresas, etc.

• Nunca conseguín un virus
• Nunca coñecín a alguén que o fixera
• Nunca coñecín a alguén que o coñecera

Coñezo máis xente que viu o monstro do Lago Ness que non viu virus Linux.
Persoalmente, admito que fun imprudente e puxen en marcha varios programas que os autoproclamados "especialistas" chaman "virus para Linux" - a partir de agora chamaréilles virus, para non facer o texto pedante -, a miña conta habitual contra a miña máquina, para ver se é posible un virus: tanto o virus bash que circula por alí - e que, por certo, non infectou ningún ficheiro - como un virus que se fixo moi famoso e apareceu na prensa . Intentei instalalo; e despois de vinte minutos de traballo, desistín cando vin que unha das súas demandas era ter o directorio tmp nunha partición do tipo MSDOS. Persoalmente, non coñezo a ninguén que crea unha partición específica para tmp e a formatea en FAT.
De feito, algúns chamados virus que probei para Linux requiren un alto nivel de coñecemento e que se instale o contrasinal de root. Poderiamos cualificar, como mínimo, como un virus "crappy" se precisa a nosa intervención activa para infectar a máquina. Ademais, nalgúns casos requiren un amplo coñecemento de UNIX e do contrasinal de root; que está bastante lonxe da instalación automática que se supón que debería ser.

Infección de executables en Linux:

En Linux, un proceso pode simplemente facer o que o seu usuario efectivo e o seu grupo efectivo permiten. É certo que hai mecanismos para intercambiar ao usuario real con efectivo, pero pouco máis. Se observamos onde están os executables, veremos que só root ten privilexios de escritura nestes directorios e nos ficheiros contidos. Noutras palabras, só root pode modificar estes ficheiros. É o caso de Unix desde os anos 70, en Linux desde as súas orixes e nun sistema de ficheiros que admite privilexios, aínda non apareceu ningún erro que permita outro comportamento. A estrutura dos ficheiros executables ELF é coñecida e está ben documentada, polo que é tecnicamente posible que un ficheiro deste tipo cargue a carga útil noutro ficheiro ELF ... sempre que o usuario efectivo do primeiro ou o grupo efectivo do primeiro teñen privilexios de acceso, lectura, escritura e execución no segundo ficheiro. Cantos executables do sistema de ficheiros podería infectar como usuario común?
Esta pregunta ten unha resposta sinxela, se queremos saber cantos ficheiros poderiamos "infectar", lanzamos o comando:

$ find / -type f -perm -o=rwx -o \( -perm -g=rwx -group `id -g` \) -o \( -perm -u=rwx -user `id -u` \) -print 2> /dev/null | grep -v /proc

Excluímos o directorio / proc porque é un sistema de ficheiros virtual que mostra información sobre como funciona o sistema operativo. Os ficheiros de tipo de ficheiro con privilexios de execución que atoparemos non supoñen ningún problema, xa que adoitan ser ligazóns virtuais que parecen ser lidas, escritas e executadas e se un usuario o intenta, nunca funciona. Tamén descartamos moitos erros, xa que, especialmente en / proc e / home, hai moitos directorios nos que un usuario común non pode entrar - Este script leva moito tempo. No noso caso particular, nunha máquina onde traballan catro persoas, a resposta foi:

/tmp/.ICE-unix/dcop52651205225188
/tmp/.ICE-unix/5279
/home/irbis/kradview-1.2/src
/kradview

A saída mostra tres ficheiros que se poderían infectar se se executase un hipotético virus. Os dous primeiros son ficheiros tipo socket Unix que se eliminan ao iniciar -e non poden ser afectados por un virus-, e o terceiro é un ficheiro dun programa de desenvolvemento, que se elimina cada vez que se recompila. O virus, desde un punto de vista práctico, non se estendería.
Polo que vemos, o único xeito de estender a carga útil é ser root. Neste caso, para que un virus funcione, os usuarios sempre deben ter privilexios de administrador. Nese caso, pode infectar ficheiros. Pero aquí está o problema: para transmitir a infección, cómpre levar outro executable, envialo por correo a outro usuario que só use a máquina como root e repetir o proceso.
Nos sistemas operativos nos que é necesario ser administrador de tarefas comúns ou executar moitas aplicacións diarias, pode ser o caso. Pero en Unix é necesario ser administrador para configurar a máquina e modificar os ficheiros de configuración, polo que o número de usuarios que a conta raíz utiliza como conta diaria é pequeno. É máis; algunhas distribucións de Linux nin sequera teñen a conta root activada. En case todos, se accedes ao contorno gráfico como tal, o fondo cambia a vermello intenso e repítense mensaxes constantes que lembran que non se debería usar esta conta.
Finalmente, todo o que se ten que facer como root pode facerse cun comando sudo sen risco.
Por esta razón, en Linux un executable non pode infectar a outros mentres non esteamos a usar a conta root como a conta de uso común; E aínda que as empresas antivirus insisten en dicir que hai virus para Linux, realmente o máis parecido que se pode crear en Linux é un troiano na área de usuario. A única forma en que estes troianos poden afectar algo no sistema é executándoo como root e cos privilexios necesarios. Se normalmente usamos a máquina como usuarios comúns, non é posible que un proceso iniciado por un usuario común poida infectar o sistema.

Mitos e mentiras:

En Linux atopamos moitos mitos, enganos e mentiras simples sobre virus. Fagamos unha lista deles baseada nunha discusión que tivo lugar hai un tempo cun representante dun fabricante de antivirus para Linux moi ofendido por un artigo publicado nesta mesma revista.
Esa discusión é un bo exemplo de referencia, xa que toca todos os aspectos dos virus en Linux. Imos revisar todos estes mitos un por un tal e como foron discutidos nesa discusión específica, pero que se repetiu tantas veces noutros foros.

Mito 1:
"Non todos os programas maliciosos, especialmente os virus, precisan privilexios de root para infectar, especialmente no caso particular de virus executables (formato ELF) que infectan outros executables".

Resposta:
Quen fai esa afirmación non sabe como funciona o sistema de privilexios Unix. Para afectar a un ficheiro, un virus precisa o privilexio de ler –debe lelo para modificalo– e escribir –debese escribir para que a modificación sexa válida– no ficheiro executable que quere executar.
Isto sempre é así, sen excepcións. E en todas e cada unha das distribucións, os usuarios non root non teñen estes privilexios. Entón, simplemente sen non ser raíz, a infección non é posible. Proba empírica: na sección anterior vimos un sinxelo script para comprobar o rango de ficheiros que poden verse afectados por unha infección. Se o lanzamos na nosa máquina, veremos como é insignificante e nulo con respecto aos ficheiros do sistema. Ademais, a diferenza de sistemas operativos como Windows, non precisa privilexios de administrador para realizar tarefas comúns con programas usados ​​habitualmente por usuarios normais.

Mito 2:
"Tampouco precisan ser root para entrar no sistema remotamente, no caso de Slapper, un verme que, explotando unha vulnerabilidade no SSL de Apache (os certificados que permiten a comunicación segura), creou a súa propia rede de máquinas zombies en setembro de 2002".

Resposta:
Este exemplo non se refire a un virus, senón a un gusano. A diferenza é moi importante: un verme é un programa que explota un servizo para que Internet se transmita. Non afecta aos programas locais. Polo tanto, só afecta aos servidores; non a máquinas particulares.
Os vermes sempre foron moi poucos e de incidencia insignificante. Os tres realmente importantes naceron nos anos 80, época na que Internet era inocente e todos confiaban en todos. Lembremos que foron os que afectaron a sendmail, fingerd e rexec. Hoxe as cousas son máis complicadas. Aínda que non podemos negar que aínda existen e que, se non se controlan, son extremadamente perigosos. Pero agora, os tempos de reacción aos vermes son moi curtos. É o caso do Slapper: un verme creado sobre unha vulnerabilidade descuberto - e remendado - dous meses antes da aparición do propio verme.
Incluso supoñendo que todos os usuarios de Linux tiñan Apache instalado e funcionando todo o tempo, simplemente actualizar os paquetes mensualmente tería sido máis que suficiente para non correr nunca ningún risco.
É certo que o erro SSL que causou Slapper foi crítico - de feito, o erro máis grande atopado en toda a historia de SSL2 e SSL3 - e como tal resolveuse en poucas horas. Que dous meses despois de atopar e resolver este problema, alguén fixo un verme nun erro que xa foi corrixido e que este é o exemplo máis poderoso que se pode dar como vulnerabilidade, polo menos tranquiliza.
Como regra xeral, a solución aos gusanos non é mercar un antivirus, instalalo e perder o tempo de computación manténdoo residente. A solución é facer uso do sistema de actualización de seguridade da nosa distribución: unha vez actualizada a distribución, non haberá problemas. Executar só os servizos que precisamos tamén é unha boa idea por dous motivos: melloramos o uso dos recursos e evitamos problemas de seguridade.

Mito 3:
"Non creo que o núcleo sexa invulnerable. De feito, hai un grupo de programas maliciosos chamados LRK (Linux Rootkits Kernel), que se basean precisamente na explotación de vulnerabilidades nos módulos do núcleo e na substitución dos binarios do sistema.".

Resposta:
Un rootkit é basicamente un parche do núcleo que permite ocultar a existencia de certos usuarios e procesos das ferramentas habituais, grazas a que non aparecerán no directorio / proc. O normal é que o utilicen ao final dun ataque, en primeiro lugar, van explotar unha vulnerabilidade remota para acceder á nosa máquina. Despois emprenderán unha secuencia de ataques para aumentar os privilexios ata que teñan a conta raíz. O problema cando o fan é como instalar un servizo na nosa máquina sen ser detectado: aí entra o rootkit. Créase un usuario que será o usuario efectivo do servizo que queremos ocultar, instala o rootkit e oculta tanto a este usuario como todos os procesos pertencentes a este.
Como ocultar a existencia dun usuario é útil para un virus é algo que poderiamos discutir en profundidade, pero un virus que usa un rootkit para instalarse parece divertido. Imaxinemos a mecánica do virus (en pseudocódigo):
1) O virus entra no sistema.
2) Localice o código fonte do núcleo. Se non o é, instálao el mesmo.
3) Configure o núcleo para as opcións de hardware que se aplican á máquina en cuestión.
4) Compila o núcleo.
5) Instale o novo núcleo; modificando LILO ou GRUB se fose necesario.
6) Reinicie a máquina.

Os pasos (5) e (6) requiren privilexios de root. É algo complicado que os pasos (4) e (6) non sexan detectados polos infectados. Pero o curioso é que hai alguén que cre que hai un programa que pode facer o paso (2) e (3) automaticamente.
Como culminación, se atopamos con alguén que nos di "cando hai máis máquinas Linux haberá máis virus" e recoméndanos que "teñamos instalado un antivirus e o actualicemos constantemente", pode estar relacionado coa empresa que vende. o antivirus e as actualizacións. Sexa desconfiado, posiblemente o mesmo propietario.

Antivirus para Linux:

É certo que hai bo antivirus para Linux. O problema é que non fan o que defenden os defensores do antivirus. A súa función é filtrar o correo que pasa de malware e virus a Windows, así como verificar a existencia de virus de Windows en cartafoles exportados a través de SAMBA; polo que se usamos a nosa máquina como pasarela de correo ou como NAS para máquinas Windows, podemos protexelas.

Ameixa-AV:

Non remataremos o noso informe sen falar do principal antivirus para GNU / Linux: ClamAV.
ClamAV é un antivirus GPL moi potente que compila a maior parte do Unix dispoñible no mercado. Está deseñado para analizar os anexos das mensaxes de correo electrónico que pasan pola estación e filtralos por virus.
Esta aplicación intégrase perfectamente con sendmail para permitir o filtrado de virus que se poden almacenar nos servidores Linux que proporcionan correo ás empresas; ter unha base de datos de virus que se actualiza diariamente, con soporte dixital. A base de datos actualízase varias veces ao día e é un proxecto animado e moi interesante.
Este poderoso programa é capaz de analizar virus ata en anexos en formatos máis complexos para abrir, como RAR (2.0), Zip, Gzip, Bzip2, Tar, MS OLE2, ficheiros MS Cabinet, MS CHM (HTML COprinted) e MS SZDD .
ClamAV tamén admite ficheiros de correo mbox, Maildir e RAW e ficheiros executables portátiles comprimidos con UPX, FSG e Petite. O par Clam AV e o spamassassin son o par perfecto para protexer aos nosos clientes Windows dos servidores de correo Unix.

CONCLUSIÓN

Á pregunta ¿Hai vulnerabilidades nos sistemas Linux? a resposta é certamente si.
Ninguén na súa boa mente o dubida; Linux non é OpenBSD. Outra cousa é a xanela de vulnerabilidade que ten un sistema Linux que se actualiza correctamente. Se nos preguntamos, hai ferramentas para aproveitar estes buracos de seguridade e explotalos? Ben, si, pero non son virus, son exploits.

O virus debe superar varias dificultades máis que os defensores de Windows puxeron sempre como un fallo / problema en Linux e que complican a existencia de virus reais: núcleos que se recompilan, moitas versións de moitas aplicacións, moitas distribucións, cousas que non se pasan automaticamente ao usuario de forma transparente, etc.–. Os "virus" teóricos actuais deben instalarse manualmente desde a conta raíz. Pero iso non se pode considerar un virus.
Como sempre lles digo aos meus alumnos: non me creas, por favor. Descarga e instala un rootkit na máquina. E se queres máis, le o código fonte dos "virus" no mercado. A verdade está no código fonte. É difícil para un virus "autoproclamado" seguir nomeando así despois de ler o seu código. E se non sabe ler código, unha única medida de seguridade sinxela que recomendo: use a conta raíz só para xestionar a máquina e manter actualizadas as actualizacións de seguridade.
Só con iso é imposible que che entren virus e é moi improbable que gusanos ou alguén atacen a túa máquina con éxito.