Si se explotan, estas fallas pueden permitir a los atacantes obtener acceso no autorizado a información confidencial o, en general, causar problemas
Se ha identificado una vulnerabilidad (ya catalogada bajo CVE-2022-37454) en la implementación de la función hash criptográfica SHA-3 (Keccak), ofrecida en el paquete XKCP (eXtended Keccak Code Package).
La vulnerabilidad identificada puede provocar un desbordamiento del búfer durante el procesamiento datos formados. El problema se debe a un error en el código de una implementación específica de SHA-3, no a una vulnerabilidad en el algoritmo en sí.
El paquete XKCP se promociona como la implementación oficial de SHA-3, desarrollado con la ayuda del equipo de desarrollo de Keccak, y se utiliza como base para funciones para trabajar con SHA-3 en varios lenguajes de programación (por ejemplo, el XKCP El código se usa en el módulo Python hashlib, el paquete Ruby digest-sha3 y las funciones PHP hash_*).
Según el investigador que identificó el problema, pudo usar la vulnerabilidad para violar las propiedades criptográficas de la función hash y encontrar la primera y segunda preimágenes, así como determinar colisiones.
El motivo de la falla de segmentación es que los scripts intentarán escribir más datos en un búfer de los que puede contener. Tal vulnerabilidad se conoce como desbordamiento de búfer, que OWASP describe como» probablemente la forma más conocida de vulnerabilidad de seguridad de software «.
Una pequeña variante del código causará un bucle infinito: simplemente reemplace 4294967295 con 4294967296. Tenga en cuenta la similitud con CVE-2019-8741 , otra vulnerabilidad que encontré que afectó el firmware de más de 1.400 millones de dispositivos Apple, que también provocó un bucle infinito.
Además, se anuncia la creación de un exploit prototipo, que permite lograr la ejecución de código al calcular el hash de un archivo especialmente diseñado. Potencialmente, la vulnerabilidad también se puede usar para atacar algoritmos de verificación de firmas digitales usando SHA-3 (por ejemplo, Ed448). Está previsto que los detalles de los métodos de ataque se publiquen más adelante, después de la eliminación generalizada de la vulnerabilidad.
Se supone que este tipo de comportamiento no debe ocurrir en lenguajes «seguros» como Python y PHP, ya que verifican que todas las operaciones de lectura y escritura estén dentro de los límites del búfer. Sin embargo, el problema es que la vulnerabilidad está presente en el lenguaje C «inseguro» subyacente…
Aún no está claro cómo afecta la vulnerabilidad a las aplicaciones existentes en la práctica, ya que para que el problema se manifieste en el código, se debe usar el cálculo de hash cíclico en bloques, y uno de los bloques procesados debe tener un tamaño de aproximadamente 4 GB (al menos 2 ^ 32 – 200 bytes).
Al procesar los datos de entrada a la vez (sin cálculo secuencial del hash por partes), el problema no aparece. Como método de protección más simple, se propone limitar el tamaño máximo de los datos involucrados en una iteración del cálculo hash.
El código vulnerable se publicó en enero de 2011, por lo que se tardó más de una década en encontrar esta vulnerabilidad. Parece ser difícil encontrar vulnerabilidades en las implementaciones criptográficas, a pesar de que juegan un papel fundamental en la seguridad general de un sistema. (¡Quizás la gente ni siquiera esté buscando tales vulnerabilidades, ya que ni esta vulnerabilidad en XKCP ni la vulnerabilidad de Apple mencionada anteriormente son elegibles para ningún programa de recompensas por errores!)
La vulnerabilidad se debe a un error en el procesamiento de bloques de los datos de entrada. Debido a una comparación incorrecta de los valores con el tipo «int», se determina un tamaño incorrecto de los datos pendientes, lo que hace que la cola se escriba fuera del búfer asignado.
En particular, se menciona que al comparar, se utilizó la expresión «parcialBlock + instancia->byteIOIndex«, que, con valores grandes de las partes componentes, condujo a un desbordamiento de enteros. Además, hubo un encasillado incorrecto «(int sin firmar)(dataByteLen – i)» en el código, lo que provocó un desbordamiento en los sistemas con un tipo size_t de 64 bits.
Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.