En seguridad informática , el ataque de mil millones de risas es un tipo de ataque de denegación de servicio (DoS) que está dirigido a los analizadores de documentos XML . [1]
También se le conoce como bomba XML o como ataque de expansión de entidad exponencial. [2]
El ataque de ejemplo consiste en definir 10 entidades, cada una definida como compuesta por 10 de la entidad anterior, y el documento consiste en una única instancia de la entidad más grande, que se expande a mil millones de copias de la primera entidad.
En el ejemplo más citado, la primera entidad es la cadena " lol ", de ahí el nombre "billion laughs". En el momento en que se informó por primera vez sobre esta vulnerabilidad, la memoria de la computadora utilizada por mil millones de instancias de la cadena "lol" probablemente superaría la disponible para el proceso que analiza el XML.
Si bien la forma original del ataque estaba dirigida específicamente a los analizadores XML, el término puede aplicarse también a temas similares. [1]
El problema se informó por primera vez en 2002, [3] pero comenzó a abordarse ampliamente en 2008. [4]
Las defensas contra este tipo de ataque incluyen limitar la memoria asignada en un analizador individual si la pérdida del documento es aceptable, o tratar las entidades simbólicamente y expandirlas de forma diferida solo cuando (y en la medida en que) se vaya a utilizar su contenido.
< ? xml version= "1.0" ? > <!DOCTYPE lolz [ <!ENTIDAD lol "lol" > <!ELEMENT lolz ( #PCDATA ) > <!ENTIDAD lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;" > <!ENTIDAD lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;" > <!ENTIDAD lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;" > <!ENTIDAD lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;" > <!ENTIDAD lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;" > <!ENTIDAD lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;" > <!ENTIDAD lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;" > <!ENTITY jajaja8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;" > <!ENTITY jajaja9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;" > ]> <lolz > &lol9; </lolz>Cuando un analizador XML carga este documento, ve que incluye un elemento raíz, "lolz", que contiene el texto "&lol9;". Sin embargo, "&lol9;" es una entidad definida que se expande a una cadena que contiene diez cadenas "&lol8;". Cada cadena "&lol8;" es una entidad definida que se expande a diez cadenas "&lol7;", y así sucesivamente. Una vez que se han procesado todas las expansiones de entidades, este pequeño bloque (< 1 KB) de XML contendrá en realidad 10 9 = mil millones de "lol", ocupando casi 3 gigabytes de memoria. [5]
El ataque de mil millones de risas descrito anteriormente puede ocupar una cantidad exponencial de espacio o tiempo. La variación de explosión cuadrática provoca un crecimiento cuadrático de los requisitos de recursos simplemente repitiendo una entidad grande una y otra vez, para evitar contramedidas que detecten entidades muy anidadas. [6] (Véase la teoría de la complejidad computacional para comparaciones de diferentes clases de crecimiento).
Podría existir un ataque de "mil millones de risas" para cualquier formato de archivo que pueda contener expansiones de macros, por ejemplo, esta bomba YAML :
a : &a [ "jajajaja" , "jajajaja" , " jajajaja " , " jajajaja" , " jajajaja " , " jajajaja" ] b : &b [ *a , *a , * a , * a , *a , * a , *a , *a ] c : &c [ *b , *b , * b , * b , *b , *b , * b , * b ] d : &d [ *c , *c , *c , *c , *c , * c , *c , *c , *c ] e : & e [ *d , *d , * d , * d , *d , * d , *d , *d , *d ] f : &f [ *e , *e , *e , *e , *e , *e , *e, *e , *e , *e ] g : &g [ *f , *f , * f , *f , *f , *f , *f , *f , *f ] h : &h [ *g , *g , *g , *g , * g , *g , *g , *g , *g ] i : &i [ *h , *h , *h , *h , *h , *h , *h , *h , *h ] Esto provocó el bloqueo de versiones anteriores de Go porque el procesador YAML de Go (al contrario de la especificación YAML) expande las referencias como si fueran macros. El procesador YAML de Go se modificó para que no pueda analizar si el objeto resultante se vuelve demasiado grande.
El software empresarial como Kubernetes se ha visto afectado por este ataque a través de su analizador YAML. [7] [8] Por este motivo, se prefiere un analizador con capacidades intencionalmente limitadas (como StrictYAML) o se prefieren formatos de archivo que no permitan referencias para los datos que llegan de fuentes no confiables. [9] [ verificación fallida ]
