¿Cuál es la causa del desbordamiento de webdav? ¡Por favor ayuda! ¡Gracias!

Al escribir contenido que excede la longitud del búfer del programa, se produce un desbordamiento del búfer, lo que destruye la pila del programa, provoca que el programa falle o hace que el programa cambie a otras instrucciones. para lograr el propósito del ataque. La causa del desbordamiento del búfer es que el programa no verifica cuidadosamente los parámetros ingresados ​​por el usuario. Por ejemplo, el siguiente programa: void function(char *str) { char buffer[16]; strcpy(buffer,str }El strcpy() anterior copiará el contenido de str directamente al buffer. Siempre que la longitud de str exceda 16, el búfer se desbordará, lo que provocará que el programa se ejecute incorrectamente. Otras funciones estándar con problemas similares a strcpy son strcat(), sprintf(), vsprintf(), gets(), scanf(), etc. Por supuesto, llenar aleatoriamente el búfer para provocar que se desborde generalmente solo provocará un "fallo de segmentación" y no podrá lograr el propósito del ataque. El método más común es crear un desbordamiento del búfer, lo que hace que el programa ejecute un shell de usuario y luego ejecute otros comandos a través del shell. Si el programa es propiedad de root y tiene permisos suid, entonces el atacante tiene un shell con permisos de root y puede realizar acciones arbitrarias en el sistema.

Ataques de desbordamiento de búfer

Los ataques de desbordamiento de búfer representan la gran mayoría de los ataques a redes remotas y pueden brindar a los usuarios anónimos de Internet la oportunidad de obtener el control parcial o total de un host. Si las vulnerabilidades de desbordamiento del búfer se pueden eliminar de manera efectiva, la mayoría de las amenazas a la seguridad se pueden mitigar. Hay cuatro formas básicas de proteger los buffers contra ataques y efectos de desbordamiento del buffer. IV.1 describe métodos para hacer que los buffers no sean ejecutables a través del sistema operativo para evitar que los atacantes coloquen código de explotación. IV.2 describe formas de exigir la escritura de código correcto. IV.3 describe métodos para proteger los buffers usando la verificación de límites del compilador. Este método hace imposible el desbordamiento del búfer, eliminando así por completo la amenaza de desbordamiento del búfer, pero el costo es relativamente alto. IV.4 introduce un método indirecto que realiza una verificación de integridad antes de que el puntero del programa deje de ser válido. Aunque este enfoque no solucionará todos los desbordamientos del búfer, sí evitará la gran mayoría de los ataques de desbordamiento del búfer. Las ventajas de compatibilidad y rendimiento de este enfoque de protección se analizan luego en la Sección IV.5.

Búfer no ejecutable

Al hacer que el espacio de direcciones del segmento de datos del programa atacado no sea ejecutable, el atacante no puede ejecutar el código implantado en el búfer de entrada del programa atacado. Esta es la llamada tecnología de búfer no ejecutable. En los primeros diseños de sistemas Unix, al código del programa solo se le permitía ejecutarse dentro de segmentos de código. Sin embargo, debido a la necesidad de lograr un mejor rendimiento y funcionalidad, los sistemas Unix y MS Windows recientes tienden a colocar dinámicamente el código ejecutable en el segmento de datos, lo que también es la causa principal de los desbordamientos del búfer. Para mantener la compatibilidad del programa, no es posible hacer que todos los segmentos de datos del programa no sean ejecutables. Sin embargo, el segmento de datos de la pila se puede hacer no ejecutable para garantizar la compatibilidad del programa, y ​​tanto Linux como Solaris han lanzado parches del kernel para este propósito. Dado que pocos programas legítimos almacenan código en la pila, esta práctica crea pocos problemas de compatibilidad, con dos excepciones en Linux, donde el código ejecutable debe colocarse en la pila: Señalizar a Linux liberando el código de la pila de proceso y luego desencadena una interrupción para ejecutar el código en la pila, implementando así la señalización Unix al proceso. El parche de búfer no ejecutable permite que el búfer sea ejecutable al enviar señales. Reutilización en línea en GCC Se descubrió que gcc coloca código ejecutable en el área de la pila para su reutilización en línea. Sin embargo, desactivar esta función no causa ningún problema, sólo algunas funciones parecen no estar disponibles. La protección de la pila no ejecutable es efectiva contra ataques de desbordamiento de búfer que incrustan código en variables automáticas, pero no contra otras formas de ataques. Esta protección se puede eludir haciendo referencia a un puntero a un programa residente. Otros ataques pueden eludir la protección colocando código en el montón o en segmentos de datos estáticos.

Escribir código correcto

Escribir código correcto es una tarea muy gratificante, especialmente cuando se escriben programas en lenguaje C, que tiene fama de no estar estructurado y ser propenso a errores. Aunque a la gente le llevó mucho tiempo aprender a escribir programas seguros, todavía existen programas con vulnerabilidades de seguridad. Por lo tanto, se han desarrollado diversas herramientas y técnicas para ayudar a los programadores sin experiencia a escribir programas seguros y correctos. La forma más sencilla es utilizar grep para buscar en el código fuente llamadas a bibliotecas vulnerables, como llamadas a strcpy y sprintf, ninguna de las cuales verifica la longitud de los argumentos de entrada. De hecho, este problema existe en todas las versiones de la biblioteca estándar C. Además, se han desarrollado herramientas avanzadas de comprobación de errores, como la inyección de fallos. El propósito de estas herramientas es encontrar vulnerabilidades de seguridad en el código generando artificialmente desbordamientos aleatorios del búfer. También existen herramientas de análisis estático que pueden detectar la presencia de desbordamientos del búfer. Aunque estas herramientas pueden ayudar a los programadores a desarrollar programas más seguros, debido a las características del lenguaje C, es imposible que estas herramientas encuentren todas las vulnerabilidades de desbordamiento del búfer. Por lo tanto, las técnicas de detección de errores solo se pueden utilizar para minimizar la posibilidad de desbordamientos del búfer, pero no pueden eliminarlos por completo.