Hola, On Thu, Nov 25, 2004 at 09:47:34PM +0100, txipi wrote: > 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.
Si bien es cierto Fred Cohen hace referencia a cualquier cosa que se autoreproduzca en cualquier sentido... Pues le llamer�a temerario darle la categor�a de Virus... El nombre es m�s amplio y una �nica definici�n no es suficiente... Pero en fin muchas personas gastan palabras tratando de dar un significado a la palabra Virus y no caer� en el mismo asunto, si para usted la defici�n de Cohen es correcta pues est� bien, Para mi el t�rmino tiene que tener relaci�n con la palabra Virus en el sentido biol�gico (por que la palabra es originaria de la Biolog�a). Y no se diga que esto no es posible o es moderno por que este enfoque es el que se usaba en los 80's para los virus inform�ticos... yo lo recuerdo... > 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? Puede serlo como no. La idea es que tiene que poderse ejecutar de manera independiente. Pero obviamente tiene mejores caracter�sticas si es un demonio esto a nivel de programaci�n ya que en realidad los demonios son procesos que se ejecutan en segundo plano como usted lo describe s�lo que con caracter�sticas de control adicionales... > b) Un script no puede permanecer vivo y ejecut�ndose > > �Por qu� no? Claro que puede, es muy sencillo, no me trate de hacer tonto que conozco muy bien el SO. > 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. Pero de igual forma se respondi� en la tercera parte, por lo general uno usa herramientas del sistema para descargar los ficheros, por ejemplo apt y este correo como root, si tiene un proceso virico corriendo en segundo plano en su user normal, no podr� hacer nada... > 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". S�lo en ese caso. Si se remite a la respuesta anterior, si el usuario es distinto el virus no tiene nada que hacer. > 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?). Vuelva a pensar en un proceso realizado por apt, que pone el deb en /var/cache/apt/archives con privilegios root, podr�a hacerle algo? > 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. Pues simple descuido, si uno descarga un paquete es buena idea siempre verificar la suma MD5... algo que evidentemente mostrar�a que el paquete ha cambiado... usted har�a el dpkg -i sobre el paquete si ve que la suma MD5 no coincide? si no me equivoco esa es una de las recomendaciones m�s b�sicas... > �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. Pues eso debe ser una costumbre... Y si no ya esta la receta y la soluci�n al problema que usted plantea... y entonces de que problema habla... cuando existe una soluci�n a un problema, este deja de serlo. > 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. Obviamente, por eso es bien simple, si el paquete que quiero ejecutar no es de un repositorio oficial de mi distro favorita, pero necesito tenerlo, que me cuesta crear un usuario adicional al que siempre uso y meter ah� a diestra y siniestra todo aplicativo? es dif�cil acaso? es dif�cil crear usuarios? se pueden crear cientos... obviamente si tengo un usuario espec�fico para ese tipo de pruebas, ser�a un error mio bajar un paquete oficial ahi y despu�s instalarlo como root. > Creo que no te has pegado realmente con kernel32.dll ni ntoskrnl o > hablas de oidas. Lo siento. Pues no, lo digo por experiencia, hace poco tube la desagradable tarea de programar en Windows 2000 y o sorpresa sigue siendo igual de malo... Definitivamente un mal dise�o de la arquitectura de ese Sistema Operativo. Yo de verdad lo siento por las personas que lo utilizan, pero ese ya es su problema... de verdad que los timan bien feo. Saludos! > > - -- > 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----- -- # nmag only # gnupg 0x978B82FF [pgp.mit.edu] && GNU/Linux Registered User 312624 sub boo{$q=pack q;N;,join q++,reverse split q--,shift;$q=~s;\s+$;\n; ;$q} do {printf /%s/,boo($_)} for(9112662581, 676371445, 2158412302)
