Bienvenido de nuevo a Spotlight de Vulnerabilidades de Sherlock, donde destacamos una vulnerabilidad impactante descubierta durante una auditoría de Sherlock. Esta semana, examinamos una denegación de servicio encontrada en el concurso de @GMX_IO por @0xdeadbeef____ y @IllIllI000. Créditos a @int0x1catedCode por el desglose.

Resumen de la vulnerabilidad: La vulnerabilidad permite a un atacante manipular el flujo de ejecución de órdenes al proporcionar longitudes de razones de reversión falsas que no coinciden con los datos reales. Esto provoca que el manejo de errores del protocolo lea regiones de memoria incorrectas, lo que puede interrumpir el proceso de ejecución o causar un comportamiento inesperado al procesar órdenes fallidas.

Pasos del ataque: 1. Fase de configuración Desplegar un contrato malicioso que implemente un comportamiento de revert personalizado. El contrato malicioso debe ser invocable por el protocolo objetivo (por ejemplo, como manejador de callback). 2. Crear datos de revert maliciosos Estructurar los datos de revert con un parámetro de longitud falsificado. 3. Ejecutar la orden a través del protocolo Crear una orden que desencadene la interacción con el contrato malicioso. Cuando el protocolo procese la orden y llame al contrato malicioso, revertirá con los datos creados. El manejo de errores del protocolo intenta decodificar la razón del revert utilizando la longitud falsa. 4. Desencadenar un desbordamiento de lectura de memoria El protocolo lee la memoria en función del parámetro de longitud falsa. Esto provoca que lea más allá de los límites reales de los datos de revert.

¿Cuál es el impacto? Denegación de servicio: Los pedidos pueden no ejecutarse correctamente, bloqueando operaciones legítimas del protocolo como la liquidación de posiciones malas. Disrupción en la ejecución de pedidos: El procesamiento por lotes de pedidos puede ser detenido, afectando a múltiples usuarios. Gas griefing: Procesar datos de reversión malformados puede consumir un gas excesivo.

La causa raíz: 1. Parámetros de longitud no verificados: El protocolo confía en el valor de longitud proporcionado en los datos de reversión sin validación 2. Falta de verificaciones de límites: No hay verificación de que la longitud reclamada coincida con el tamaño real de los datos

La Mitigación: 1. Siempre valida la Longitud de los Datos de Reversión 2. Implementa Límites de Longitud Máxima

Estamos orgullosos de haber ayudado a asegurar @GMX_IO a través de este descubrimiento. Cuando realmente necesita estar seguro, Sherlock es la elección correcta.