Cambio extraño de dirección durante el desbordamiento del búfer

Navega tus respuestas
4

Estaba probando un desbordamiento de búfer y sucedió lo siguiente:

Ladirecciónderetornoestáen0xbffff7bc,loquedescubríenlaspruebas.Loreemplacéconelvalorquequería0xbffff636.

Cuandosellamaareturn,parecedirigirseaunadireccióndiferentealaqueagregué.Desdelatrazaposteriorsepuedeverqueprobótodaslasdireccionesjuntoaesa.

Sinembargo,reemplazó0xbffff636con0xbffff71b.Claramente,nocambiólasotrasdireccionesalasqueintentóregresarenelbacktrace1a6,pero0esincorrecto.Pareceque#0deberíahabersido0xbffff636peroseeditó,comotodaslasotrasdireccionesdespuésdequeseprobaron.

¿Cuálesunaposiblerazónporlaquesecambióladirección?

EDIT/UPDATE

Estomuestraloqueestáenladirección0xbffff636queeslamitaddeuntrineoNOP.Elbúferesde500bytes,ladirecciónderetornoestáen540offset.

Actualmente estoy en un punto de ruptura en la declaración de devolución, y lo que es extraño es que hacer una traza hacia atrás en el punto muestra que se intentó con 0xbffff636 como un punto de devolución, pero aún no he regresado. Cuando continúo y devuelvo, el backtrace se convierte en el backtrace que publiqué originalmente con '0xbff636' convirtiéndose en '0xbffff71b'. Pensé que podría añadir eso.

ACTUALIZACIÓN2 Aquí está la parte relevante del código del libro:

Enlugardecontinuar,continúo'siguiente'atravésdelprogramahastaquedejélafunciónrecv_linequecopiólosdatosenunbúfer(solicitudllamada)quesepasó.Esafunciónvolvióbienyaquenotoquésudirección.Ahoracontinuéatravésdelafuncióndelcontroladoranteriorhastaquelleguéalfinalyestoesloquevi:

Parece que no encuentra 0xbfff636 válido cuando lo ve por primera vez. He hecho desbordamientos en este entorno antes, por lo que estoy bastante seguro de que no hay protecciones.

Nota : estoy compilando con -g marca de depuración. Ejecuto el proceso como sudo. Luego adjúntelo al proceso en ejecución con gdb

    
pregunta dylan7 07.01.2016 - 06:42
fuente

3 respuestas

3

Después de una investigación adicional, resultó que cuando se construía la carga útil utilizando la declaración de impresión de Python, se añadió una línea de 0a justo antes del código de shell y después del último NOP que daba como resultado un código que no se puede cortar. Descubrí esto experimentando con el programa C del libro, que creaba exactamente la misma carga útil, pero funcionó cuando lo ejecuté. Después de usar la declaración de impresión de Perl para crear el archivo de carga útil, no se agregó 0a y el exploit tuvo éxito. Fue sutil pero lo atrapé.

    
respondido por el dylan7 09.01.2016 - 22:47
fuente
5

La aleatorización del diseño del espacio de direcciones (ASLR) y la prevención de ejecución de datos (DEP) son técnicas que se utilizan para evitar que los desbordamientos de búfer se aprovechen con éxito.

ASLR usa ubicaciones de desplazamiento aleatorio donde un ejecutable del sistema se carga en la memoria.

DEP marca las áreas de la memoria como ejecutables o no ejecutables y permite que los datos solo se ejecuten en las ubicaciones marcadas de la memoria del ejecutable.

Cuando los dos se combinan, se vuelve increíblemente difícil explotar las vulnerabilidades en aplicaciones que usan código de shell.

Sin embargo, no es imposible. Hay maneras en que estas técnicas pueden ser evitadas. El siguiente enlace es un documento técnico que explica una situación en la que se omiten ASLR y DEP: enlace

    
respondido por el Jeroen - IT Nerdbox 07.01.2016 - 07:28
fuente
1

¿Comenzaste a partir de una instrucción a mitad de la pila? Si haces esto, entonces el valor que ya estaba en la memoria podría devolverse si no se eliminó como se esperaba.

Esta es una explicación posible del comportamiento.

Hay un ejemplo brillante de esto en el último 3 de este video.

    
respondido por el TheJulyPlot 07.01.2016 - 09:10
fuente

Lea otras preguntas en las etiquetas

El efecto de los banners de servicio ocultos o falsificados en los escáneres de vulnerabilidad ¿cuál es un desafío válido para la autenticación de 2 factores?