>> "Alvaro F. Figueroa Cabezas" <[EMAIL PROTECTED]> writes:
> OpenBSD no es seguro porque es OpenBSD...
Ah, �al menos alguien me entendi�!
> El securityfocus.com, que es donde salen la mayor cantidad de
> vulnerabilidades y con la mayor rapidez que conozco
Nada m�s tomalos con un grano de sal: security focus tiende a estar un
poco "atrazado" respecto a lo que dice. Lo mismo vale para el CERT.
Si quer�s anuncios de seguridad sin que est�n (tan) te�idos de ning�n
color, suscribite a bugtraq.
> fijense el la cantidad de huecos que hay bajo "RedHat".
/me defiende a RH, hmmpf!
Linux es Linux es Linux.
Sin insultar a nadie, si un sitio de seguridad identifica un error con
un *programa* como un problema de seguridad de una distribuci�n, �qu�
puede uno pensar del sitio de seguridad? S�, exacto. Eso.
Dicho de otra forma: quiere esto decir que si yo instalo una cierta
versi�n de gmp en OpenBSD, �m�gicamente se resuelve el problema solo
porque lo estoy instalando en BSD? (cuidado, a veces la respuesta
puede ser s�, pero en general es no) El problema de seguridad (la
vulnerabilidad) est� en gmp. RH, Debian (et al) se ven /afectados/
pues existe en la distribuci�n "oficial" un paquete precompilado para
dicha distribuci�n. �Qu� hace security focus? Ve que hay un problema
en la versi�n 3.14.15 de gnomovision, revisa que Debian tiene en
potato (o slink o lo que sea) gnomovision 3.14.15 y declara a Debian
"vulnerable". No se toma la molestia de mirar el changelog (s�, los
paquetes en Debian tienen un changelog, �y el changelog realmente
sirve del algo!) y notar que la versi�n actual es 3.14.15-9, y que
all� dice:
* Fixed security problem while giving up permissions. Thanks
to Joe Cool for providing a patch. Sent upstream. (Closes:
bug#2653)
as� las cosas, lo que securityfocus diga hay que tom�rselo con un
grano immenso de sal.
> Desde el 1/6/99 salieron 47 huecos, todo eso para redhat 6.0
muchos de los huecos est�n en los programas mismos (l�ase, es tan
vulnerable RH como Debian como Slackware), pero es cierto que RH es
generalmente descuidado en lo que se refiere a sacar versiones
nuevas. Mir� los problemas reportados con Debian:
2000-03-22: Multiple Linux Vendor gpm Setgid Vulnerability
upstream
2000-03-11: wmcdplay Buffer Overflow Vulnerability
upstream
2000-02-09: GNU make /tmp Vulnerability
upstream
2000-02-02: Debian GNU/Linux MBR Vulnerability
Debian, pero esto es alguien haciedo una pataleta porque tuvo un
problema por no leer el manual.
2000-02-01: Debian GNU/Linux 2.1 apcd Symlink Vulnerability
Debian.
Mir� lo mismo para RH:
2000-03-23: Multiple Linux Vendor Domain Socket Denial of Service
Vulnerability
upstream
2000-03-22: Multiple Linux Vendor gpm Setgid Vulnerability
upstream
2000-03-10: IrcII DCC Chat Buffer Overflow Vulnerability
upstream
2000-03-09: Printtool Printer Share Password Compromise Vulnerability
RH.
2000-02-28: nmh Buffer Overflow Vulnerability
upstream
2000-02-28: Multiple Vendor "dump" Buffer Overflow Vulnerability
upstream
2000-02-26: Multiple Linux Vendor man Buffer Overrun Vulnerability
upstream
2000-02-23: RedHat Single User Mode Authentication Vulnerability
RH (y es super antig�o)
2000-02-14: Nameserver Traffic Amplification and NS Route Discovery
Vulnerability
RH (debido a la configuraci�n que instala)
2000-01-23: DNS TLD & Out of Zone NS Domain Hijacking
upstream (depende de la configuraci�n, si entend� bien)
2000-01-11: Redhat Linux lpd Vulnerabilities
upstream, pero espec�fico a RH por la configuraci�n local
2000-01-04: Multiple Linux Vendor userhelper/PAM Path Vulnerability
upstream
Lo que quiero decir es que no hay peor cosa en seguridad que tener
mala fama.
> Desde la misma fecha, pero de un anno antes (5/5/98), no hay
> _ninguna_[0] vulnerabilidad para 7.0 (que tampoco recuerdo pero
> creo incluso salio antes que RH6.0.
RH6 tiene rato afuera, casi un a�o si no estoy equivocado. Otra vez,
"eso que llamamos rosa, con cualquier otro nombre seguir�a siendo
igualmente dulce" (o amargo, en este caso particular)
> codos... openssl, openssh, etc... etc.. Estamos a un par de
> configure's, make's y make install's de distancia...
Usualmente el argumento se centra en el estado del sistema en el
instante que acaba la instalaci�n. Lado a salo ("salidos de la caja"
si se quiere), OpenBSD ofrece una configuraci�n m�s segura que
FreeBSD. Y de aqu� deriva el mito: alguien va a tener que cambiar
algo eventualmente si quiere usar el tarro para algo que OpenBSD no
tiene configurado "saliendo de la caja". �Seguir� siendo OpenBSD
"m�s" "seguro"? Pues depende de que tanto honor le haga a su nombre
el payaso que se siente a hacer los cambios, �no?
> Y tambien, el que no te deje hacer su, como usuario normal, sino
> solo como usuario del grupo wheel, y que la gente de wheel, no se
> puede pegar por telnet, tambien se le hace en otro par de
> lados... de los cuales si me acuerdo.
/etc/login.defs, IIRC
> [1] " No, zombies are a marvel. -- Sten Drescher
>
> I thought they were Just Another Thing Wrong With NFS.
Ah! ASR! De las favoritas: "Down. Not across."
> [2] Lista la cual encontre, buscando un site de acronimos, para intentar
> entender a marcelo
/me se recuerda a s� mismo no usar tantos TLAs.
/me le presta una copia de dict a Alvaro.
MEM, <g>
--
�Desea desuscribirse? Escriba a [EMAIL PROTECTED] con
el tema "unsubscribe".
