Re: virus en linux
Hola,
On Fri, Nov 26, 2004 at 02:52:36PM +0100, txipi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hola nmag,
>
> On Fri, 26 Nov 2004 07:32:48 +0000
> nmag@softhome.net wrote:
>
> > insuficientes... Y finalmente ¿por qué Cohen mismo presento un Virus
> > residente en 1984 para sustentar su tesis?
>
> Tengo en mis manos el libro de Cohen y presenta muchisimos ejemplos de
> virus no residentes. Si quieres te paso bibliografía.
Basarse en una única definición, un único libro o un único autor,
uhm!, como que hay que pensarlo un poco más... Ahora la definición
de Virus es un concepto que aún sigue en discusión, y si bien es
cierto que la definición de Cohen es la más popular, eso no garantiza
que tenga que ser ley.
Yo discrepo mucho de la clasificasión de los Virus actuales,
Todos tienen la idea general de lo que es un Virus y prácticamente
se llega a la falsa idea que cualquier cosa puede ser un Virus,
definitivamente un error, hacen de la palabra Virus un Super
Conjunto de lo que es Código malicioso cuando no es así, en real
sentido Virus es una clase de Código malicioso, pero en
fin a esas cosas se llega por la mala costumbre.
Y actualmente dicen que los gusanos, troyanos, y demás nombres
extraños son Virus, creo que sería bueno utilizar bien las palabras
en su real contexto siempre basandonos en el lenguaje y su significado
Solo hay que pensar en la idea descabellada Gusano = Virus, podría
ser también entonces Humano = Virus... por favor!
>
> > Además el origen de los Virus data de los años 60 y no los 80, el
> > primero que trató el tema fue nada más y nada menos que John Von
> > Neumann el cual en su libro Teoría y Organización de Autómatas
> > complicados habla de programas que se reproducen solos...
>
> Los autómatas autorreplicantes se ven ya justo después de la formulación
> de la Máquina de Turing, pero nadie le había puesto el cascabel al gato
> para referirse a ellos con el término "virus informático".
Son el origen.
>
> > Es bien sabido que el Juego Core War se reproducia solo y presentaba
> > las técnicas iniciales que dieron origen al termino residente, este
> > fué el primer virus así como el Reaper destruia las copias hechas por
> > el core war se convertiría en el primer antivirus, todo en los años
> > 60, nada mas y nada menos...
>
> Lo conozco, pero me parece que un repeater y cualquier otro código
> participante en una core war no entienden el concepto de residencia en
> memoria como lo entiendes tú, es decir, no monitorizan el sistema en
> busca de nuevas víctimas de manera residente, sino que en el código de
> su propio programa lo único que hacen es copiarse por memoria.
Y otro punto de debate es tal vez que usted está tratando de
atribuir controles a la residencia... eso no tiene nada que ver
basta que un programa permanezca ejecutandose (así no haga nada)
para ser residente. Ahora, ¿usted esta asociando Residencia con
Búsqueda de nuevas víctimas? ¿La residendica es acaso Propiedad
únicamente del código malicioso?
>
> > El primer Core War fue idea de Victor Vyssotsky, Robert Morris Sr.
> > y Dennis Ritchie que escribieron un programa en 1960.
> > Inicialmente un juego pero es el verdadero origen de los virus.
>
> Claro, ya digo que los autómatas finitos deterministas autorreplicantes
> de los primeros desarrollos con máquinas de turing son también el
> verdadero origen de los virus. Por eso me quedo con esa definición:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Y ¿qué pasó con el cascabel y el gato de más arriba?
> autómata autorreplicante, sin entrar en residencias u otras técnicas.
Definitivamente usted tiene el concepto y sostiene que para que un
programa sea virus no tiene necesidad de estarse ejecutando. Yo por
el contrario sostengo que sí, y también reconozco que hay aplicaciones
que pueden hacer lo que usted menciona y a los cuales les atribuyo
el sentido de código malicioso, que en opinión personal no
necesariamente es virus.
>
> > En este juego, cada jugador presenta cierto número de programas en
> > lenguaje ensamblador y se les da el nombre de organismos, que conviven
> > (REPITO conviven) en la memoria del ordenador con los organismos de
> > los demás participantes.
>
> Lo conozco, ya he jugado, bastante divertido el redcode.
>
> > Si usted se ampara solo en lo de Cohen eso es su asunto.
>
> Me amparo en la definición del inventor del término (que no del
> concepto). Pero si quieres usar otras definiciones que exijan
> residencia, me gustaría que me pasaras referencias a esas definiciones,
> para que me documente.
>
> > > La técnica de residencia no se implementó hasta bien avanzados los
> > > 80 y hasta entonces sí había virus y salían en las noticias.
> > Eso es mentira.
>
> Si quieres decir que algo es mentira, arguméntalo, por favor. Si no,
> paso de entrar en debates de: "eso es mentira", "no, es verdad!".
>
Si no me equivoco, en esos años (60) los únicos medios de grabación
comunes eran las tarjetas perforadas y los programas venian en circuitos
impresos, así que la mayoría de procesos y programas se cargaban
permanecian residentes y de ahí se ejecutaban mientras el equipo
estubiese encendido. Esta es la característica inicial de los
Sistemas Operativos, y el nombre del Core War viene básicamente de
ahí se podría considerar como Guerra de Núcleos.
> > > > > 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.
> > > Vale, entonces estamos de acuerdo. No hace falta programar un
> > > demonio para hacer un virus en UNIX.
> > No me atribuya términos que no he puesto, el puede serlo es referido
> > al proceso en segundo plano, por si no comprendió su propia pregunta.
>
> O no entiendes bien castellano o no me explico bien: la pregunta "¿No
> puede ser un proceso normal corriendo en segundo plano?" tiene un sujeto
> elíptico (omitido) que es "Un virus", referente a la frase anterior. Si
Si un virus se ejecuta en segundo plano tiene características de
demonio, por que los demonios no son mas que procesos en segundo
plano con controles adicionales. El hecho simple de hacer un proceso
en segundo plano que monitoree las llegadas de paquetes de instalación
para modificarlos, los convierte en forma implícita en demonios por que
tienen que tener ciertos controles de entrada/salida y ser continuos
hasta que el sistema operativo les diga lo contrario. Así que afirmar
alegremente que no es necesario programar un demonio como que se
contradice...
> lo has entendido de otra manera, o me expresé mal o lo entendiste mal,
> pero en la pregunta no veo mucho indicio de ambigüedad.
Ok.
>
> > De todas formas un demonio no es más que un proceso en segundo plano
> > con mayores controles...
>
> ¿Y son esos mayores controles absolutamente necesarios para hacer un
> virus? Yo creo que no.
En todo caso para que no haga colera :) ¿qué es entonces para usted
(del ejemplo que plantea) que un proceso en segundo plano esté
"vigilando" al arribo de paquetes para modificarlos? ¿no tiene
controles acaso? ¿no por lo menos debe verificar cuando un paquete
ya fué infectado? ¿eso último no es un control? y bla bla bla
>
> > Eso es mentira... es bien sabido de todos los problemas que tiene
> > un cliente de correo en Windows, por lo general un virus llega
> > y puede ejecutarse solo sin concentimiento del usuario..., es
> > muy diferente a que se pregunte... en muchos casos es por las
> > funcionalidades que le dan los desarrolladores de Windows a los
> > usuarios, en Windows cualquier cosa es un Virus. Así que no
> > trate de compararlo, yo creo que eso si es bien tonto.
>
> No he entendido muy bien este párrafo (usar puntos ayudaría), pero por
> lo que creo entender, ¿dices que si eres un usuario muy precavido en
> Windows es posible que te infectes, mientras que en GNU/Linux nunca?
>
De verdad los contextos son diferentes, los sistemas operativos
en mención también... compararlos es un absurdo, y en ese punto
me incluyo... Pero por lo que se, Windows siempre ha hecho cosas
a espaldas de los usuarios y estos muchas veces sin tener concimiento,
esos, por lo general son los puntos que explotan los dis que Virus
para entrar en el sistema. Sólo ponga en tela el siguiente caso
un Windows sin antivirus, y descargando y ejecutando aplicaciones
en usuario normal, no administrador; Ahora contemple el siguiente caso
un GNU/Linux con un usuario que no sea root haciendo lo mismo. Al
Windows lo pongo sin Antivirus por que este no es parte del sistema
operativo, Ahora ninguno de los dos escalará a Administrador o
Root según el caso ¿Quién corre el risgo real de ser infectado?
>
> > > Claro, pero ya no es necesario ser root, con infectar a un usuario
> > > normal que descargue cosas para luego instalarlas, ya hay otra vía
> > > de escalada de privilegios.
> > Eso es bien cierto, se puede escalar vía suid
>
> No me refiero a ejecutables con el bit de SUID activado, sino porque
> explícitamente el usuario ejecuta "su" para hacer el "make install".
El make install es para los códigos que son compilados en un equipo
con GNU/Linux, ahora es cierto que su proceso en segundo plano podría
modificar los códigos para meter algo indevido o incluso después de
obtenido el objeto binario... Pero no seamos fatalistas, acaso cuando
yo compilo una aplicación, tengo que hacerla como root? acaso no se
puede usar prefix? y en este caso un usuario con muy poca experiencia
o casi nula (que básicamente son los usuarios vulnerables) cree que
se de el lujo de realizar el proceso de compilación?
Por lo general un novato ejecuta sus procesos en su usuario normal
de trabajo, de ahi puede escalar a procesos de configuración o
update via contraseña requerida para acceder a la configuración
de la impresora y demás... y por lo general cuando eso ocurre
se cambian los privilegios pero solo para esa aplicación, de
igual forma cuando quiere isntalar un paquete, el sistema lo hace
solo pidiendole la contraseña, por tanto el sistema al descargar
el paquete lo hara en root, su proceso en segundo plano con privilegios
de niño manuelito podrá siquiera modificar dicho paquete?
O es que acaso usted instruye a trabajar como root a sus clientes?
>
> > saliendo del contexto... No trate de generalizar y dar a entender que
> > los Virus al igual que en los Windows funciona en GNU/Linux
>
> Nunca he dicho eso, si crees que lo he dicho, cópiame dónde lo dije.
>
> > diferencia muy grande, usted mismo habla de escalar en privilegios, en
> > Windows por más que se sea un usuario diferente del administrador el
> > virus entra y ya esta en todo el sistema... Básicamente por la ficción
> > en el pobre diseño de privilegios de ese Sistema Operativo.
>
> Creo que no te has dado cuenta de que existe una parte de Windows que se
> ejecuta en RING-0 y otra en RING-3. Creo que tampoco te has dado cuenta
Pero no funciona, al menos he visto personas programar y ejecutar
aplicaciones como usuario normal, explotar el asunto del VB script
del exploter y permitirle al proceso escalar a más, el hecho es bien
simple, Los windows son una farsa en diseño de privilegios, puede
distribuirlos bien eso nadie lo niega pero es suficiente que el exploter
se ejecute para ya tener un hueco de seguridad, por que es parte del
sistema y el siempre ejecutara cosas con todos los privilegios aun
el usuario este restringido. Por eso es una ficción, los códigos
maliciosos modernos atacan ese tipo de vulnerabilidades para
saltarse los privilegios.
> de que NTFS tiene un sistema de ACLs sobre ficheros bien implementado. Y
> creo que tampoco te has dado cuenta de que los procesos en Windows NT y
> superiores sí tienen protección de memoria. Aún con todo esto, se pueden
> hacer cosas en Windows NT y modificar el sistema, shatters o lo que sea,
> pero de ahí a decir que la protección es una "ficción" ya va un mundo.
He visto ordenadores que solo trabajaban a nivel de usuario común y haber
quedado infectados de forma completa. Ahora usted puede decir mala
política de privilegios, yo lo comprendo, pero no se de windows, no
lo uso y tampoco me interesa usarlo, lo que si tengo bien en claro
es que un cliente al que se le cree un usuario en GNU/Linux puede
hacer y deshacer en su sesión, y después venir el administrador y
eliminar dicha cuenta sin que esto represente mayores consecuencias...
En windows se puede lo mismo permitiendole al usuario hacer todo lo
que quiera sin sacrificar privilegios? creo que no? todo esto en
incognita por que de verdad no uso windows, salvo esa mala experiencia
de programar hace poco un agentillo para los clientes que no quieren
migrar a gnu/linux por lo demás no se...
>
> Mira, yo soy un entusiasta del Software Libre como conocerás pocos, pero
> decir este tipo de farsas ayuda más a la gente pro-Windows que a la
> comunidad del Software Libre.
>
> FUD también se puede hacer desde nuestro lado de la trinchera, y eso
> daña más que ayuda.
Eso siempre lo he visto en muchos foros, y por lo general es gente
adepta a microsoft que se aluden por tal asunto, yo se que de igual
forma ellos en sus foros hacen FUD de gnu/linux, y que acaso ellos
tienen mayores ventajas? acaso solo ellos pueden hacerlo? osea que
a ellos si les es permitido rajar a voz en cuello y nosotros calladitos?
Estas mal...
>
> > > Jajajajaja muy bueno. Existen soluciones conocidas a tantos
> > > problemas y siguen existiendo esos problemas... Si tienes un
> > > problema con el alcohol, pues muy fácil, ¡deja de beber! :-DDDD Si
> > > tienes un problema con los estudios, muy fácil, ¡estudia más!
> > Pero son soluciones usted mismo lo ha dicho.
>
> Claro que lo he dicho y no lo he discutido. Pero ese no es el punto de
> debate.
>
> > > En Windows pasa lo mismo: el Blaster arrasó con todos los Windows
> > > que pilló por delante porque nadie había aplicado el parche al RPC,
> > > publicado meses antes. La solución estaba publicada, pero la gente
> > > pasa de todo eso.
> > Pero hay diferencias... como siempre los privilegios en este SO son
> > solo una ficción...
>
> Dime en qué te basas para afirmar eso o seguiré pensando que no tienes
> ni idea de win32asm, win-internals ni diseño de Sistemas Operativos.
No uso windows y no me interesa, pero si se de SO's en realidad usted
al parecer sólo conoce el diseño de sistemas operativos desde el punto
de vista de Microsoft... Nuevamente se esta cerrando por un solo punto
de vista, eso es un error... Microsoft no es el unico SO y su diseño
mucho menos.
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
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (GNU/Linux)
>
> iD8DBQFBpzUkNSlVRUN1G/QRAibSAJ4hfP19SVvWkv+SQ6gMYe8dcJ49DACcDe82
> WYBCEgKNb0aSN8HZafaOJwA=
> =3St2
> -----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)
Reply to: