Mensajes

Tendrias que analizar tu codigo. Tenes como una especie de proteccion. Fijate

El main es llamado por __libc_start_main asi que se puede suponer que a la entrada de tu main en el top de la pila tengas la ip de retorno a una direccion x de __libc_start_main, ponele que se llame ret_libc.

ESP:     ret_libc
ESP+4: main_param

Suponiendo que ese es el estado de la pila en main+0 se puede arrancar a ver como evoluciona

Código [Seleccionar] Expandir


0x08048464 <main+0>: lea    ecx,[esp+0x4] ; ECX apunta a main_param
0x08048468 <main+4>: and    esp,0xfffffff0; Alineacion de la pila a 16 bytes
0x0804846b <main+7>: push   DWORD PTR [ecx-0x4]; Mete en la pila el valor ret_libc
0x0804846e <main+10>: push   ebp; Salva ebp
0x0804846f <main+11>: mov    ebp,esp
0x08048471 <main+13>: push   ecx; Y salva ecx


Si se siguió bien el hilo, el estado de la pila a esta altura seria una cosa asi:

ESP  : ECX, o puntero a main_param
+4   : EBP
+8   : ret_libc
--- Espacio de alineacion ---
+8+a     : ret_libc
+8+a+4 : main_param

Siguiendo la ejecucion

Código [Seleccionar] Expandir


0x08048472 <main+14>: sub    esp,0x24; "malloc" de tus variables internas
0x08048475 <main+17>: mov    DWORD PTR [ebp-0x1c],ecx
0x08048478 <main+20>: mov    eax,DWORD PTR [ebp-0x1c]
0x0804847b <main+23>: cmp    DWORD PTR [eax],0x2
0x0804847e <main+26>: je     0x8048489 <main+37>
0x08048480 <main+28>: mov    DWORD PTR [ebp-0x18],0x1
0x08048487 <main+35>: jmp    0x80484af <main+75>
0x08048489 <main+37>: mov    edx,DWORD PTR [ebp-0x1c]
0x0804848c <main+40>: mov    eax,DWORD PTR [edx+0x4]
0x0804848f <main+43>: add    eax,0x4
0x08048492 <main+46>: mov    eax,DWORD PTR [eax]
0x08048494 <main+48>: mov    DWORD PTR [esp+0x4],eax
0x08048498 <main+52>: lea    eax,[ebp-0x8]
0x0804849b <main+55>: mov    DWORD PTR [esp],eax
0x0804849e <main+58>: call   0x8048374 <strcpy@plt>
0x080484a3 <main+63>: call   0x8048344 <getchar@plt>
---Type <return> to continue, or q <return> to quit---
0x080484a8 <main+68>: mov    DWORD PTR [ebp-0x18],0x0
0x080484af <main+75>: mov    eax,DWORD PTR [ebp-0x18]
0x080484b2 <main+78>: add    esp,0x24; "Free" de tus variables internas


Suponiendo que argv[1] puede crashear todo el frame de main, todos los pops que tenes aca estan infectados.

Código [Seleccionar] Expandir


0x080484b5 <main+81>: pop    ecx; ecx = 0x41414141
0x080484b6 <main+82>: pop    ebp; ebp = 0x41414141
0x080484b7 <main+83>: lea    esp,[ecx-0x4]; esp = 0x4141413d
0x080484ba <main+86>: ret   


Cuando se ejecute el ret, la direccion de retorno se va a buscar a la 0x4141413d.
Esa doble referencia que prepara la pila para el ret te obliga a conocer la direccion exacta de tu exploit. Si tenes el randomize activado es complicado, sino podes arreglartelas sabiendo que el ret se toma de una direccion que metas en la pila menos 4.
Por lo que el payload deberia contener 0x24 bytes(variables internas) + ECX + EBP + RET2EXPLOIT. Con ECX apuntando a donde esta RET2EXPLOIT + 4 y RET2EXPLOIT apuntando a tu shellcode.

Ahora bien, si alguien sabe:
- Porque guarda dos veces ret_libc en la pila si despues lo salta para volver al estado del frame anterior en main+83?

que sos complicado sangrini . Proba de mandarle mas bytes, a mi me funciono, debe haber otras boludeces en la pila a parte de tu buffer.

Igual te esta diciendo que se fue de rango con el SIGSEGV, o sea que no puede ejecutar esa instruccion. Parece que no te esta tomando el bof.
Proba de hacer ejecutable la pila.

Código [Seleccionar] Expandir

gcc -fno-stack-protector -z execstack tuprog.c

Desensamblate el binario y pasalo por gdb con stepi. Vas a tener que depurarlo a muerte .
Sino danos acceso ssh con una cuenta restringida que te ayudamos!

Felicitaciones Sagrini!

Ah sbit no es del compilador sdcc? Parece ser q sdcc ya dejo de dar soporte para los avr.
Que compilador estas usando meta??

Por lo que pude seguir del hilo me parece que no estan hablando del mismo lenguaje.
Lo que pusiste Meta es C y me parece que skapunky esta hablando de asm, no? Capaz que estoy diciendo barbaridades  , corrijanme si me equivoco.

Esta parte del código viene así:

Código [Seleccionar] Expandir

#include <avr/io.h>
#include <avr/pgmspace.h>
#include <util/delay.h>
#include "usb_debug_only.h"
#include "print.h"Por lo que veo, hay que quitar los # que son como comentarios, si los deja los lee como comentario y el compilador lo ignora.

Código [Seleccionar] Expandir


include <avr/io.h>
include <avr/pgmspace.h>
include <util/delay.h>
include "usb_debug_only.h"
include "print.h"

Si eso es C, no son comentarios los #, son directivas de compilacion.

Por ejemplo:

Código [Seleccionar] Expandir

// Teensy 2.0: LED is active high
#if defined(__AVR_ATmega32U4__) || defined(__AVR_AT90USB1286__)
#define LED_ON        (PORTD |= (1<<6))
#define LED_OFF        (PORTD &= ~(1<<6))

// Teensy 1.0: LED is active low
#else
#define LED_ON    (PORTD &= ~(1<<6))
#define LED_OFF    (PORTD |= (1<<6))
#endif

Si las macros __AVR_ATmega32U4__ y __AVR_AT90USB1286__ estan definidas, el compilador te va a tomar LED_ON y LED_OFF como

Código [Seleccionar] Expandir

#define LED_ON        (PORTD |= (1<<6))
#define LED_OFF        (PORTD &= ~(1<<6))

Sino

Código [Seleccionar] Expandir

#define LED_ON    (PORTD &= ~(1<<6))
#define LED_OFF    (PORTD |= (1<<6))

Cual es la diferencia? Lo puso en el comentario "LED is active high".
Al parecer en la nueva version de la placa para encender el led hay que poner a 1 el bit 6 del puerto D del micro (PD6 = pin numero 31) mientras que en la placa 1.0 lo encendes con un cero, lo que te obliga a hacer un esquema pull up (o un inversor) para encender el led.
PORTD imagino que debe leer el estado del puerto D.

De hecho si te fijas en una imagen que pusiste en el primer post de los pines de la placa teensy, vas a ver que en el pin 6 dice "led on 6", bueno ese es el bit 6 del puerto D y ahi es donde tenes que conectar el led (ponele en serie una resistencia de 4,7k para no quemar la salida del micro y manda todo a GND).

Mira te encontre mas info, asumiendo que el modulo tipc esta cargado.

Dan Rosenberg reportando el problema.
:http://www.spinics.net/lists/netdev/msg144701.html

Código [Seleccionar] Expandir

static inline int msg_calc_data_size(struct iovec const *msg_sect, u32 num_sect)
{
int dsz = 0; <<<<
int i;

for (i = 0; i < num_sect; i++)
dsz += msg_sect[i].iov_len; <<<<
return dsz;
}

Que es llamada para construir el msg en msg_build

Código [Seleccionar] Expandir


static inline int msg_build(struct tipc_msg *hdr,
    struct iovec const *msg_sect, u32 num_sect,
    int max_size, int usrmem, struct sk_buff** buf)
{
...
dsz = msg_calc_data_size(msg_sect, num_sect);
if (unlikely(dsz > TIPC_MAX_USER_MSG_SIZE)) { <<<< trunc
*buf = NULL;
return -EINVAL;
}
...
res = !copy_from_user((*buf)->data + pos, <<<< heap overflow
      msg_sect[cnt].iov_base,
      msg_sect[cnt].iov_len);
...


Lo saque del src de mi kernel. Como explotarlo? bue se me ocurre crear un server y un cliente que se le conecte en local para despues usar llamar a sendmsg. Hay ejemplos en la red:
:http://www.mail-archive.com/tipc-discussion@lists.sourceforge.net/msg00125.html

Ahora si el kernel no tiene cargado este modulo fuistes . Bueno nada por ahi capaz que no puedas aprovecharte de este error en particular pero buscando otros estoy seguro que te las vas a poder rebuscar para explotarlos  .

Lo q podes hacer es fijarte los anuncios de seguridad en lugar de buscar por exploits derecho viejo:
:http://www.debian.org/security/2010/dsa-2126

Por ejemplo:
-CVE-2010-3859 Dan Rosenberg reported an issue in the TIPC protocol. When the tipc module is loaded, local users can gain elevated privileges via the sendmsg() system call.

Tenes buena data como para buscar si existe el exploit o eventualmente buscar si podes encontrar el error y hacerte el exploit.

Estamos de acuerdo que si te dice resistencia de entrada es porque el dispositivo tiene entradas definidas.
Que dispositivo estas viendo? A lo mejor con un ejemplo concreto se te pueda ayudar mejor.