Comments on: Cuando pequeños detalles desencadenan complejos problemas

By: LinuxHX

LinuxHX — Wed, 09 Sep 2009 14:30:40 +0000

parchar es tanto de windows como linux, incluso diria mas de linux

0 0

By: yo mismo

yo mismo — Fri, 04 Sep 2009 17:43:40 +0000

excelente aporte.

0 0

By: Victor Muñoz

Victor Muñoz — Fri, 04 Sep 2009 17:03:49 +0000

@franco:

en tu ejemplo -como FSierra te hace saber- no tienes un puntero con nulo, el valor de este puntero es un dato previamente en el stack, pero que numero?? como el programa no a tocado mucho el stack el stack deberia estar inicializado en cero asi que ese puntero valdra solo el offset que la vriable utiliza en su frame del stack y esto depende de la ABI y como este definido el stack frame, en WindowsXP SP3 el valor es 2 por ejemplo…

El tema no tiene que ver mucho con Linux, un puntero no inicializado puede ser un problema siempre, en cualquier sistema, en Linux 2.6 puedes hacer crecer el heap hasta llegar a 00000000, y por ejemplo en solaris 10 (IA32) puedes hacer crecer el stack (crece hacia abajo) hasta 00000000.

Sin embargo, el problema aqui como te digo no son los sitemas, sino los bug mismos… hasta en el sistema mas seguro este programa el programa que te pongo a continuacion podria ser vulnerable…

INCLUSO EN OPENBSD con ASRL activo, que es una caracteristica de seguridad que los sistemas de Microsoft tambien trae.

Aqui hice un programa que demuestra que un puntero no inicializado es demasiado peligroso, incluso en Linux… te invito a compilar y correr este inocente programa (solo lo prove en WindowsXP SP3)

#define password_de_fcatrin 123456 void multiplica_dato(int *s, int multiplicador) { int *blah; blah=s; *blah=*blah*multiplicador; // cualquier tontera... }


void vulnerable(int valor) {

    int *p;

    if(valor>0) p=(int *)malloc(sizeof(int)); // asignamos el puntero... siempre????

    *p=password_de_fcatrin;

}

int main(int argc, char *argv[]) { int dato; dato=atoi(argv[1])+atoi(argv[2]); multiplica_dato(&dato,atoi(argv[3])); vulnerable(dato); printf("resultado de la operacion %d\n", dato); return 0; }

el programa suma los 2 primeros parametros y los multiplica por el tercero…
prueba usarlo con estos parametros “test 1000000000 1000000000 2″

que relacion tiene que el programa sea chico a la probabilidad que apunte a un area no mapeada? recuerda que todo aqui es deterministico, eso es lo bonito del mundo de explotar vulnerabilidades

saludos!

0 0

By: jado92mx

jado92mx — Fri, 04 Sep 2009 15:47:53 +0000

lo grandioso de lo imperfecto es qe lo puedes corregir i mejorar
bn dicho

saludos!

JaD!

0 0

By: Kekleparek

Kekleparek — Fri, 04 Sep 2009 12:38:51 +0000

errar es humano, perdonar es divino……..parchar es de windows…..

0 0

By: Salazar Leon

Salazar Leon — Fri, 04 Sep 2009 09:24:48 +0000

while(1){
puts(“LOL”);
}

0 0

By: Ares

Ares — Fri, 04 Sep 2009 04:42:25 +0000

@zeta: no sabía si pensar si sólo me ocurría a mi, pero sí, me ha pasado siempre, parecía que todo el mundo (excepto yo) había nacido con un talento mágico para encontrar bugs.

0 0

By: MG-Speed

MG-Speed — Fri, 04 Sep 2009 04:34:41 +0000

solo para agregar:

“¿Perfecto? para que queremos algo tan aburrido, nuestro mundo es imperfecto para que SIEMPRE podamos mejorarlo”

0 0

By: flipelunico

flipelunico — Fri, 04 Sep 2009 00:49:27 +0000

@Fsierra estas en lo correcto creo que aqui hay un erorr de conceptos, y no es malo admitir los errores

saludos

0 0

By: FSierra

FSierra — Thu, 03 Sep 2009 22:25:46 +0000

@Franco (la arroba, ¿es una costumbre de IRC?), te cito:
“Esto ocurre cuando se usa una variable que debería apuntar a un objeto válido en memoria, pero al no ser inicializada apunta a la dirección 0 (null pointer dereference).”
¿Lo ves? “Al no ser inicializada apunta a la dirección 0″. Eso es lo que has dicho, y es incorrecto. No es malo reconocer un error
El error al que te refieres en tu artículo no es un segmentation fault: es una referencia a NULL.

0 0

By: rex hauser

rex hauser — Thu, 03 Sep 2009 21:17:07 +0000

Concuerdo con alguien por ahi. Es una pena que no se mencione ni por si acaso la nueva release (13.0) de Slackware! La distro mas antigua y, a mi modo de ver, THE BEST!

0 0

By: mrjavo

mrjavo — Thu, 03 Sep 2009 20:51:20 +0000

Toda mi vida me convencieron que en la NULL no se podia trabajar… y ahora me dicen q si….aaaaaaaahhhH!!!!! wajapen!!?

0 0

By: FSierra

FSierra — Thu, 03 Sep 2009 19:56:22 +0000

Franco, un detalle: un puntero no inicializado apunta a NULL sólo si fue declarado static o fuera de una función. Un puntero no inicializado apunta a una dirección aleatoria, a menos que tengas un compilador que haga explícitamente la asignación a NULL por defecto para los punteros no inicializados.

0 0

By: tezeract

tezeract — Thu, 03 Sep 2009 19:52:15 +0000

Debian no usa SELinux http://wiki.debian.org/SELinux viene desactivado por defecto. Por algo debian no lo usa no?

Tengo entendido que CentOS, RHEL, etc usan SELinux. hah
Una buena practica para mantener seguridad a nivel de kernel es desactivar modulos de kernel que uno no usa. Los menos utilizados son a veces los menos mantenidos y con mas fallas. Para que decir los que estan marcados como EXPERIMENTAL, etc. Un claro ejemplo de esto es el modulo que soporta el protocolo SCTP (una lastima, SCTP > TCP + UDP).

0 0

By: tezeract

tezeract — Thu, 03 Sep 2009 19:43:25 +0000

Cada vez que C++ introduce nuevos “features”, funcionan bien, pero solo funcionan bien en sí, en el momento en que usas dos features distintos, hay un alto chance de que quede la cagada.

No. Pero lo que si pasa es que no falta el homínido que se pone a reimplementar weas que están en la biblioteca standard tratandolas de hacer interoperar con la librería standard, lo cual no es recomendable. Siempre hay una forma “C++” de hacer las cosas y si no es posible, aun tienes las bibliotecas Boost que son peer-reviewed por varios miembros del comité de standards de C++ y bastante robustas.

0 0

By: Miguel

Miguel — Thu, 03 Sep 2009 19:39:53 +0000

Punteros NOOOOOOOOOOOOOO!!!!!! jajaja

0 0

By: mrjavo

mrjavo — Thu, 03 Sep 2009 19:33:10 +0000

OffTopic:

@krao
Chan!!… no se, no le hago a esos gustillos jajajaja

0 0

By: got kormano?

got kormano? — Thu, 03 Sep 2009 19:11:51 +0000

krao: Somos varios

0 0

By: krao

krao — Thu, 03 Sep 2009 18:49:40 +0000

OT:

@Leopard @Inkubot Grande Slackware!

Bienvenidos todos aquellos que quieran probarla y comentarla.

0 0

By: Soulwave

Soulwave — Thu, 03 Sep 2009 18:47:25 +0000

Wait. ¿Un artículo con un bug en linux y no apareció “Trabajos+Esteban”?

La discusión sobre si C es de bajo o alto nivel siempre se ha dado. Al menos yo lo considero cercano al bajo nivel por lo mismo que menciona scatter.

Hace unos años atrás, C era lo mas alto que podías ir; ahora con los lenguajes modernos (Java, Python) (C++ NO) la barra se desplaza y C es considerado bajo nivel. O sea, el nivel de abstracción no es una característica intrínseca del lenguaje, sino una medida en función del resto.

Para mi Torvalds no es ningún gurú, viva C++0x

“C++ is an octopus made by nailing extra legs onto a dog”. Cada vez que C++ introduce nuevos “features”, funcionan bien, pero solo funcionan bien en sí, en el momento en que usas dos features distintos, hay un alto chance de que quede la cagada.

0 0

By: tezeract

tezeract — Thu, 03 Sep 2009 18:45:24 +0000

@visualcubb

Aun si una significativa porción de los addendums al standard (formerly C++0x, ahora C++1x) no estuvieron a tiempo, y si bien algunos fueron descartados (notoriamente los concepts), una significativa porción de ellos ya se encuentra implementada en los compiladores utilizados de forma más amplia tales como Visual C++ y GNU C++ compiler (g++).

0 0

By: Luis

Luis — Thu, 03 Sep 2009 18:06:44 +0000

@haldrik:
SeLinux era solo una via para explotar el bug en cuestion… asi que el que Debian no lo traiga no te salvaria….

Eso si… Debian no era vulnerable a este bug en particular, ya que este solo se encontraba presente en los kernel 2.6.30 y 2.6.30.1, Debian stable usa uno anterior. Claro esto no quiere decir que Debian sea mas seguro… ya que hay bugs similares que si lo han afectado.

Luis

0 0

By: Linux

Linux — Thu, 03 Sep 2009 18:05:52 +0000

La imperfección siempre estará presente, da lo mismo en el lenguaje que esté desarrollado el programita porque todos tienen su lado débil, todas las distribuciones de Linux, tienen algo en sí que hacen que el desarrollador mejore esos errores de programación…

0 0

By: Simon urzua

Simon urzua — Thu, 03 Sep 2009 17:47:55 +0000

Ufff no me imagino en que escenario podria explotarse esa vulnerabilidad…. Quedara para las peliculas

0 0

By: abuelita

abuelita — Thu, 03 Sep 2009 17:45:13 +0000

OFFTOPIC:
¿Ahora se puede puntuar la opinión de los editores o sólo éste es el caso?

0 0

By: kone

kone — Thu, 03 Sep 2009 17:42:30 +0000

Grabde catrin, poniendole nivel a FW

0 0

By: visualcubb

visualcubb — Thu, 03 Sep 2009 17:30:24 +0000

Para todos los “que se manejan” en C o C++ y nombraron C++0X, les hace falta una buena actualización, es C++1x, no 0X, ya no sale este año.

0 0

By: haldrik

haldrik — Thu, 03 Sep 2009 17:18:48 +0000

Debian no usa SELinux http://wiki.debian.org/SELinux viene desactivado por defecto. Por algo debian no lo usa no?

0 0

By: X_X

X_X — Thu, 03 Sep 2009 17:11:01 +0000

X_X@linux-x6vl:~> cat fail.c
int main(int argc, char *argv[]) {
int *p;
*p = 0;
}
X_X@linux-x6vl:~> gcc fail.c -o fail
X_X@linux-x6vl:~> ./fail
Violación de segmento
X_X@linux-x6vl:~>

Si la perfeccion existiera, entonces seriamos perfectos idiotas.

0 0

By: GeekDays » Vulnerabilidad en Linux

GeekDays » Vulnerabilidad en Linux — Thu, 03 Sep 2009 16:41:55 +0000

[...] Via:Fayerwayer Categories: Software Tags: Comentarios (0) Referencias (0) Dejar un comentario Referencia [...]

0 0