![-=[яєgєηєѕιѕ]=-](/foro/data/avatars/m/713/713087.jpg?1424577262){kind=avatar}
Acá les dejo un extracto del articulo, si quieren leerlo completo, pueden descargar el articulo en pdf desde este link: Virus en linux ¿mito o realidad?
Que es un Virus?
Se trata de un programa que se copia y se ejecuta automáticamente, y que tiene por objeto alterar el normal funcionamiento de un ordenador, sin el permiso o el conocimiento del usuario. Para ello, los virus reemplazan archivos ejecutables por otros infectados con su código.
Un virus se instala solo, sin el permiso o el concentimiento de un usuario. Si no se instala solo, no es un virus: podría ser un ser un rootkit, o un troyano.
Un rootkit es un parche al kernel que permite ocultar determinados procesos a las utilidades de área de usuario. Dicho de otra forma, es una modificación del código fuente del kernel que tiene como objeto que las utilidades que permiten ver qué se está ejecutando en cada momento no visualicen un determinado proceso, o un determinado usuario.
Un troyano es análogo: es una modificación al código fuente de un servicio concreto para ocultar determinada actividad fraudulenta. En ambos casos es necesario obtener el código fuente de la versión exacta instalada en la máquina Linux, parchear el código, recompilarlo, obtener privilegios de administrador, instalar el ejecutable parcheado, e inicializar el servicio –en el caso del troyano– o el sistema operativo completo –en el caso del rootkit–.
El proceso, como vemos, no es trivial, y nadie puede hacer todo esto “por error”. Tanto unos como otros exigen en su instalación que alguien con privilegios de administrador, de forma consciente, ejecute una serie de pasos tomando decisiones de índole técnica.
La arquitectura de Unix en general y de Linux en particular NO hace factible la dispersión de un virus
Supongamos que tenemos un virus que quiere transmitirse solo. Supongamos que ha sido lanzado por un usuario normal, de forma inocente, al lanzar un programa. Dicho virus tiene exclusivamente dos mecanismos de transmisión:
Respecto al primer mecanismo, recordemos la arquitectura de memoria virtual de Linux y cómo funcionan los procesadores intel. Estos poseen cuatro anillos, numerados de 0 a 3; a menor número, mayores los privilegios que tiene el código que se ejecute en dicho anillo.
Estos anillos corresponden con estados del procesador, y, por lo tanto, con lo que se puede hacer con un sistema estando en un anillo concreto. Linux hace uso del anillo 0 para el kernel, y del anillo 3 para los procesos. no hay código de proceso que se ejecute en anillo 0, y no hay código de kernel que se ejecute en anillo 3. solo hay un único punto de entrada al kernel desde el anillo 3: la interrupción 80h, que permite saltar del área donde está el código de usuario al área donde está el código de kernel.
El kernel mediante el uso de la memoria virtual hace creer a cada proceso que tiene toda la memoria para él solo. Un proceso –que trabaja en anillo 3– solo puede ver la memoria virtual que le han configurado, por el anillo en el que opera. No es que la memoria de los otros procesos esté protegida; es que para un proceso la memoria de los otros está fuera del espacio de direcciones. Si un proceso diese una batida a todas las direcciones de memoria, no sería capaz ni de referenciar una
dirección de memoria de otro proceso.
Como vemos, ni siquiera un virus como root puede saltar esta barrera. La única solución que queda es la transmisión entre ficheros ejecutables. Lo que tampoco funciona como veremos a continuación.
En Linux, un proceso puede hacer simplemente lo que le permita su usuario efectivo y su grupo efectivo. Es cierto que existen mecanismos para intercambiar el usuario real con el efectivo, pero poco más. Si nos fijamos donde están los ejecuables, veremos que solamente root tiene privilegios de escritura tanto en dichos directorios, como en los ficheros contenidos. Dicho de otro modo, solamente root puede modificar dichos archivos. Esto es así en Unix desde los 70, en Linux desde sus orígenes, y en un sistema de ficheros que soporte privilegios, aún no ha aparecido ningún error que permita otro comportamiento. La estructura de los ficheros ejecutables ELF es conocida y está bien documentada, por lo que es técnicamente posible que un fichero de este tipo cargue el payload en otro fichero ELF… siempre que el usuario efectivo del primero o el grupo efectivo del primero tengan privilegios de lectura, escritura y ejecución sobre el segundo fichero.
¿Cuántos ejecutables del sistema de ficheros podría infectar como usuario común? Esta pregunta tiene una respuesta simple, si queremos saber a cuántos ficheros podríamos “infectar”, lanzamos el
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
Excluimos el directorio /proc porque es un sistema de ficheros virtual que muestra información sobre cómo funciona el sistema operativo. Los archivos de tipo fichero y con privilegios de ejecución que encontraremos no suponen un problema, ya que con frecuencia son enlaces virtuales que constan como que pueden leerse, escribirse y ejecutarse, y si un usuario lo intenta, nunca funciona. También descartamos los errores, abundantes –ya que, especialmente en /proc y en /home, hay muchos directorios donde un usuario común no puede entrar–.
Este script tarda bastante. En nuestro caso particular, en una máquina donde trabajamos cuatro personas, la respuesta fue:
/tmp/.ICE-unix/dcop5265
-1205225188
/tmp/.ICE-unix/5279
/home/irbis/kradview-1.2/src
/kradview
La salida muestra tres ficheros que podrían infectarse si se ejecutase un hipotético virus. Los dos primeros son ficheros de tipo Unix socket que se borran en arranque –y que no pueden verse afectados por un virus–, y el tercero es un fichero de un programa en desarrollo, que cada vez que se recompila se borra. El virus, desde el punto de vista práctico, no se propagaría.
Por lo que vemos, la única forma de propagar el payload es siendo root. En ese caso para que un virus funcione es necesario que los usuarios tengan siempre privilegios de administrador. En ese caso sí puede infectar archivos. Pero aquí viene la trampa: para transmitir la infección, necesita mandarlo por correo a otro usuario que solamente emplee la máquina como root, y que repita el proceso.
En sistemas operativos donde es necesario ser administrador para tareas comunes o para ejecutar muchas aplicaciones diarias, esto sí se puede dar. Pero en Unix es necesario ser administrador para configurar la máquina y modificar los archivos de configuración, así que es escaso el número de usuarios que emplea como cuenta diaria la de root. En casi todas, si accedes como tal al entorno gráfico, el fondo se cambia a rojo intenso, y se repiten mensajes constantes que recuerdan que no se debe emplear esta cuenta. Finalmente, todo lo que se debe hacer como root es posible hacerlo mediante un comando sudo sin riesgo. Por ello, en Linux un ejecutable no puede infectar a otros siempre que no estemos usando la cuenta de root como cuenta de uso común; y aunque las compañías antivirus se empeñan en decir que hay virus para Linux, realmente lo más parecido que se puede crear en Linux es un troyano en área de usuario. La única forma de que estos troyanos puedan afectar algo del sistema es ejecutándolo como root y con lo privilegios necesarios. Si solemos emplear la máquina como usuarios de a pie, no es posible que un proceso lanzado por un usuario común infecte al sistema. :mota::mota::mota:
Que es un Virus?
Se trata de un programa que se copia y se ejecuta automáticamente, y que tiene por objeto alterar el normal funcionamiento de un ordenador, sin el permiso o el conocimiento del usuario. Para ello, los virus reemplazan archivos ejecutables por otros infectados con su código.
Un virus se instala solo, sin el permiso o el concentimiento de un usuario. Si no se instala solo, no es un virus: podría ser un ser un rootkit, o un troyano.
Un rootkit es un parche al kernel que permite ocultar determinados procesos a las utilidades de área de usuario. Dicho de otra forma, es una modificación del código fuente del kernel que tiene como objeto que las utilidades que permiten ver qué se está ejecutando en cada momento no visualicen un determinado proceso, o un determinado usuario.
Un troyano es análogo: es una modificación al código fuente de un servicio concreto para ocultar determinada actividad fraudulenta. En ambos casos es necesario obtener el código fuente de la versión exacta instalada en la máquina Linux, parchear el código, recompilarlo, obtener privilegios de administrador, instalar el ejecutable parcheado, e inicializar el servicio –en el caso del troyano– o el sistema operativo completo –en el caso del rootkit–.
El proceso, como vemos, no es trivial, y nadie puede hacer todo esto “por error”. Tanto unos como otros exigen en su instalación que alguien con privilegios de administrador, de forma consciente, ejecute una serie de pasos tomando decisiones de índole técnica.
La arquitectura de Unix en general y de Linux en particular NO hace factible la dispersión de un virus
Supongamos que tenemos un virus que quiere transmitirse solo. Supongamos que ha sido lanzado por un usuario normal, de forma inocente, al lanzar un programa. Dicho virus tiene exclusivamente dos mecanismos de transmisión:
- Replicarse tocando la memoria de otros procesos, anclándose a ellos en tiempo de ejecución.
- Abriendo los ejecutables del sistema de ficheros, y añadiendo su código –payload– al ejecutable.
Respecto al primer mecanismo, recordemos la arquitectura de memoria virtual de Linux y cómo funcionan los procesadores intel. Estos poseen cuatro anillos, numerados de 0 a 3; a menor número, mayores los privilegios que tiene el código que se ejecute en dicho anillo.
Estos anillos corresponden con estados del procesador, y, por lo tanto, con lo que se puede hacer con un sistema estando en un anillo concreto. Linux hace uso del anillo 0 para el kernel, y del anillo 3 para los procesos. no hay código de proceso que se ejecute en anillo 0, y no hay código de kernel que se ejecute en anillo 3. solo hay un único punto de entrada al kernel desde el anillo 3: la interrupción 80h, que permite saltar del área donde está el código de usuario al área donde está el código de kernel.
El kernel mediante el uso de la memoria virtual hace creer a cada proceso que tiene toda la memoria para él solo. Un proceso –que trabaja en anillo 3– solo puede ver la memoria virtual que le han configurado, por el anillo en el que opera. No es que la memoria de los otros procesos esté protegida; es que para un proceso la memoria de los otros está fuera del espacio de direcciones. Si un proceso diese una batida a todas las direcciones de memoria, no sería capaz ni de referenciar una
dirección de memoria de otro proceso.
Como vemos, ni siquiera un virus como root puede saltar esta barrera. La única solución que queda es la transmisión entre ficheros ejecutables. Lo que tampoco funciona como veremos a continuación.
En Linux, un proceso puede hacer simplemente lo que le permita su usuario efectivo y su grupo efectivo. Es cierto que existen mecanismos para intercambiar el usuario real con el efectivo, pero poco más. Si nos fijamos donde están los ejecuables, veremos que solamente root tiene privilegios de escritura tanto en dichos directorios, como en los ficheros contenidos. Dicho de otro modo, solamente root puede modificar dichos archivos. Esto es así en Unix desde los 70, en Linux desde sus orígenes, y en un sistema de ficheros que soporte privilegios, aún no ha aparecido ningún error que permita otro comportamiento. La estructura de los ficheros ejecutables ELF es conocida y está bien documentada, por lo que es técnicamente posible que un fichero de este tipo cargue el payload en otro fichero ELF… siempre que el usuario efectivo del primero o el grupo efectivo del primero tengan privilegios de lectura, escritura y ejecución sobre el segundo fichero.
¿Cuántos ejecutables del sistema de ficheros podría infectar como usuario común? Esta pregunta tiene una respuesta simple, si queremos saber a cuántos ficheros podríamos “infectar”, lanzamos el
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
Excluimos el directorio /proc porque es un sistema de ficheros virtual que muestra información sobre cómo funciona el sistema operativo. Los archivos de tipo fichero y con privilegios de ejecución que encontraremos no suponen un problema, ya que con frecuencia son enlaces virtuales que constan como que pueden leerse, escribirse y ejecutarse, y si un usuario lo intenta, nunca funciona. También descartamos los errores, abundantes –ya que, especialmente en /proc y en /home, hay muchos directorios donde un usuario común no puede entrar–.
Este script tarda bastante. En nuestro caso particular, en una máquina donde trabajamos cuatro personas, la respuesta fue:
/tmp/.ICE-unix/dcop5265
-1205225188
/tmp/.ICE-unix/5279
/home/irbis/kradview-1.2/src
/kradview
La salida muestra tres ficheros que podrían infectarse si se ejecutase un hipotético virus. Los dos primeros son ficheros de tipo Unix socket que se borran en arranque –y que no pueden verse afectados por un virus–, y el tercero es un fichero de un programa en desarrollo, que cada vez que se recompila se borra. El virus, desde el punto de vista práctico, no se propagaría.
Por lo que vemos, la única forma de propagar el payload es siendo root. En ese caso para que un virus funcione es necesario que los usuarios tengan siempre privilegios de administrador. En ese caso sí puede infectar archivos. Pero aquí viene la trampa: para transmitir la infección, necesita mandarlo por correo a otro usuario que solamente emplee la máquina como root, y que repita el proceso.
En sistemas operativos donde es necesario ser administrador para tareas comunes o para ejecutar muchas aplicaciones diarias, esto sí se puede dar. Pero en Unix es necesario ser administrador para configurar la máquina y modificar los archivos de configuración, así que es escaso el número de usuarios que emplea como cuenta diaria la de root. En casi todas, si accedes como tal al entorno gráfico, el fondo se cambia a rojo intenso, y se repiten mensajes constantes que recuerdan que no se debe emplear esta cuenta. Finalmente, todo lo que se debe hacer como root es posible hacerlo mediante un comando sudo sin riesgo. Por ello, en Linux un ejecutable no puede infectar a otros siempre que no estemos usando la cuenta de root como cuenta de uso común; y aunque las compañías antivirus se empeñan en decir que hay virus para Linux, realmente lo más parecido que se puede crear en Linux es un troyano en área de usuario. La única forma de que estos troyanos puedan afectar algo del sistema es ejecutándolo como root y con lo privilegios necesarios. Si solemos emplear la máquina como usuarios de a pie, no es posible que un proceso lanzado por un usuario común infecte al sistema. :mota::mota::mota:
