{"id":102629,"date":"2021-12-16T03:36:46","date_gmt":"2021-12-16T01:36:46","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/perepolnenie-bufera-v-toxcore-ekspluatiruemoe-cherez-otpravku-udp-paketa"},"modified":"2021-12-16T03:36:46","modified_gmt":"2021-12-16T01:36:46","slug":"perepolnenie-bufera-v-toxcore-ekspluatiruemoe-cherez-otpravku-udp-paketa","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/perepolnenie-bufera-v-toxcore-ekspluatiruemoe-cherez-otpravku-udp-paketa","title":{"rendered":"Desbordamiento de b\u00fafer en Toxcore, explotado a trav\u00e9s del env\u00edo de un paquete UDP","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
En Toxcore, una implementaci\u00f3n de referencia del protocolo P2P de intercambio de mensajes Tox, se ha descubierto una vulnerabilidad (CVE-2021-44847) que potencialmente permite iniciar la ejecuci\u00f3n de c\u00f3digo al procesar un paquete UDP especialmente dise\u00f1ado. Todos los usuarios de aplicaciones basadas en Toxcore, donde el transporte UDP no est\u00e1 desactivado, son susceptibles a la vulnerabilidad. Para realizar un ataque, basta con enviar un paquete UDP, conociendo la direcci\u00f3n IP, el puerto de red y la clave DHT abierta de la v\u00edctima (esta informaci\u00f3n est\u00e1 disponible p\u00fablicamente en DHT, es decir, el ataque podr\u00eda haberse realizado contra cualquier usuario o nodo DHT). <\/p>\n
El problema se manifestaba en las versiones de toxcore desde la 0.1.9 hasta la 0.2.12 y se ha solucionado en la versi\u00f3n 0.2.13. Hasta ahora, solo el proyecto qTox ha lanzado una actualizaci\u00f3n que soluciona la vulnerabilidad en aplicaciones cliente. Como medida de protecci\u00f3n alternativa, se puede desactivar el uso de UDP, manteniendo el soporte de TCP. <\/p>\n
La vulnerabilidad se debe a un desbordamiento de b\u00fafer en la funci\u00f3n handle_request(), que surge por un c\u00e1lculo incorrecto del tama\u00f1o de los datos en el paquete de red. En particular, la longitud de los datos cifrados se determinaba a trav\u00e9s del macro CRYPTO_SIZE, definido como \"1 + CRYPTO_PUBLIC_KEY_SIZE * 2 + CRYPTO_NONCE_SIZE\", que posteriormente se utilizaba en la operaci\u00f3n de resta \"length - CRYPTO_SIZE\". Debido a la falta de par\u00e9ntesis en el macro, en lugar de restar la suma de todos los valores, se realizaba la resta de 1 y la suma de las otras partes. Por ejemplo, en lugar de \"length - (1 + 32 * 2 + 24)\", el tama\u00f1o del b\u00fafer se calculaba como \"length - 1 + 32 * 2 + 24\", lo que resultaba en la sobrescritura de datos en la pila, fuera del b\u00fafer. \n Fuente: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"