-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hola,
On Thu, 25 Nov 2004 12:48:36 +0000 [EMAIL PROTECTED] wrote: > No es tan solo hacer copias de si mismo, un virus tiene que ser > aut�nomo y debe permanecer ejecutandose, sino no tiene sentido Esto es err�neo, un programa que infecta a otro programa es un virus, no tiene por qu� ser residente, puede funcionar solo programa a programa. Te remito de nuevo a la definici�n del creador del t�rmino, Fred Cohen, all� por los 80. > el nombre virus sali� exactamente de la definici�n de los virus > biol�gicos... por algo se le puso el nombre de virus... En DOS > se le conocia como programa residente, en GNU/Linux lo m�s > similar es un Demonio... La idea es que el un virus tiene la > capacidad de por si s�lo multiplicarse... y reproducirse en tanto > medio tenga posibilidad... Una vez que es ejecutado, este > permanece vivo y ejecutandose sin necesidad de estar ejecutando > cada vez un script infectado (como el en caso de su ejemplo). Partiendo de una idea err�nea (solo se es virus en la medida que se es residente), llegamos a m�s conclusiones err�neas: a) Un virus en GNU/Linux tendr�a que funcionar como un demonio para permanecer residente. �Por qu�? �No puede ser un proceso normal corriendo en segundo plano? b) Un script no puede permanecer vivo y ejecut�ndose �Por qu� no? En el texto ana�izamos los virus con ejemplos en shell script porque son m�s f�ciles de entender, pero tambi�n programo en ensamblador y modifico ficheros ELF. Sin embargo, �si no hago un demonio no es un virus? Rid�culo. > No seamos exagerados, si el paquete ha sido descargado de un sitio > oficial, se tienen que pasar muchas barreras, primero se tendr�a > que haber vulnerado los servidores del sitio oficial de la distro > que estemos usando, luego se tendr�a que haber cambiado el paquete > y tambi�n los cambios en las firmas de verificaci�n... en realidad > lo creo poco probable... Este caso se da por lo general cuando > se descargan paquetes de sitios de origen dudoso... Sigues sin entender el ejemplo. El paquete es el original al llegar al PC infectado. No ha habido que crackear ning�n servidor. El paquete est� bien al descargarse, todo correcto. El problema es que si te lo bajas como un usuario normal, y ese usuario normal se ha infectado previamente, puede haber un proceso v�rico en segundo plano que detecte ese paquete en tu $HOME y lo modifique. No es nada dif�cil. > Igualmente exagerado, un programa que este ejecutandose constantemente > puede lanzar aplicaciones en segundo plano tantas veces quiera... pero > estas siempre con sus mismos privilegios... Claro, es que de eso trata el ejemplo: 1) Un fichero, digamos prueba_1.2.3-i386.deb, descargado de un sitio oficial por el usuario "victima". 2) Un proceso, digamos virus-proc, ejecut�ndose con privilegios del usuario "victima". 3) virus-proc detecta que prueba_1.2.3-i386.deb est� en /home/victima, lo abre, lo modifica y lo cierra (tiene permisos, �no?). 4) victima hace un su y se convierte en root 5) desde root hace: dpkg -i prueba_1.2.3-i386.deb y ejecuta el .deb modificado por el virus, con privilegios de root. > Ahora si soy un poquitin descuidado, y descargue el paquete usando > el mismo usuario pues cuando escale a root antes de hacer el dpkg > pues verifico la SUMA MD5 del paquete la cual habra cambiado por > el cambio inducido que menciona en su ejemplo, ahora la pregunta es > alguien en su sano juicio instalar�a un paquete que difiera de la MD5 > provista... �? �Sueles hacer md5sum de los paquetes que instalas y comprobarlo con la suma oficial? Enhorabuena, nunca te entrar�n as�. Pero yo conozco a mucha gente que no lo hace. > Y tampoco caigamos en la exageraci�n por lo general cuando uno > actualiza su sistema lo hace directamente en root usando herramietnas > como apt y estas escribiran los .deb descargados con los privilegios > correspondientes para los cuales no tendr� permiso la aplicaci�n > que menciona ejecutando cosas en segundo plano. S�, lo normal es no infectarse, pero el escenario que planteo no es descabellado cuando se trata de software que no est� en el APT. > Pues es mentira no lo hacen... Solo trabaje con timeout con procesos > de entrada y salida y vera que las se�ales siguien siendo las mismas > que usaban en DOS y el multiprocesamiento, es solo un artificio, > solo funciona dentro del mismo bloque de sentencias... Eso en los > win2k, y verdaderamente es muy desagradable programar en esos SO's. Creo que no te has pegado realmente con kernel32.dll ni ntoskrnl o hablas de oidas. Lo siento. - -- Agur txipi wget -O - http://sindominio.net/~txipi/txipi.gpg.asc | gpg --import Key fingerprint = CCAF 9676 B049 997A 96D6 4D7C 3529 5545 4375 1BF4 A man is not complete until he is married -- then he is finished. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBpkTmNSlVRUN1G/QRApwJAKCoTAveakvGBWJRi9jAUlI98f9/CACfe6y4 PR8Sq+F6TM1NTt+SyJF1oMs= =F4ku -----END PGP SIGNATURE-----
