Az n.runs szakértői egy webkiszolgálók és futtatókörnyezetek széles körét érintő, szolgáltatásmegtagadásra lehetőséget adó problémára hívták fel a figyelmet. A problémát a HTTP paraméterek belső adatstruktúrákká (pl. PHP-ban a $_POST asszociatív tömbbé) történő leképzésének mikéntje okozza. Az érintett szoftverek a beérkező HTTP kérések paramétereiből olyan módon építenek hash-táblákat, hogy egy támadó nagy számú kulcsütközést generálva képes lehet a kiszolgáló erőforrásainak jelentős részét lefoglalni.

Hash-tábla gyorstalpaló: A hash-tábla kulcs-érték párok összerendelésére való, leginkább azért szeretjük, mert hatékonyan lehet benne keresni. A beszúrás úgy történik, hogy ráeresztünk egy (fix hosszúságú kimenetet adó) hash-függvényt a kulcsra, és az értéket a hash kimenet szerinti táblázat (tömb) indexnél helyezzük el - a többi művelet innentől nagyjából triviális. A hash-függvény nem egy kriptográfiailag biztonságos üzenetpecsét algoritmust rejt, hanem valami lényegesen egyszerűbbet, hiszen általában kisebb kimenetméretre, viszont nagyobb teljesítményre van szükségünk.

Kulcsütközés esetén új adatstruktúrák bevezetése válik szükségessé, vagy szabad helyet kell keresni a táblában. Bár implementációtól függően ezek plusz erőforrásigénye eltérhet, az n.runs elemzése szerint a vizsgált programokban gyakori ütközés esetén a keresés O(n^2) -tel arányos műveletet igényelhet, ami nem túl jó.

A nagy számú ütközés előidézésére a támadónak két lehetősége van:

Néhány hash-függvényre jellemző, hogy ha két karakterlánc (s1 és s2) ütközik, akkor minden olyan karakterlánc ütközik, melyben s1 illetve s2 azonos pozícióban szerepelnek.  Ezek után egyetlen ütközés birtokában könnyű számos újabb ütkőzést generálni.

A másik egy középen-találkozó (meet-in-the-middle) módszer a nyers erőn alapuló támadás gyorsítására. A dolog lényege, hogy a hash függvény kimenetéből visszafelé indulva megpróbálunk eljutni az algoritmus egy köztes állapotáig, majd ezt az állapotot próbáljuk meg nyers erővel két irányból közelíteni, melynek eredményeként a bemeneti tér mérete a négyzetgyökére csökkenthető. 

Lényeg ami a lényeg: egy megfelelően összeállított, (néhány) száz kB-os POST kéréssel egy ASP.NET kiszolgáló CPU-ja 90-110 másodpercre 100%-ra ugrik, vagyis egy gigabites vonalról le lehet dönteni egy 30.000 i7-es magot ketyegtető szerverfarmot.

A Microsoft már készül a javításra, az Oracle pedig szintén tervez hozzávenni egy foltot a következő Glassfish CPU-hoz. Az Apache Tomcathez elérhetővé vált egy konfigurációs opció, mellyel meghatározható az egy lekérdezésben maximális elfogadható paraméterszám. A CRuby és JRuby legfrissebb snapshotjaiban szintén orvoslásra került a probléma. Sajnos azonban számos termék érintett ezek mellett, részletesebb lista az n.runs közleményében olvasható.

Friss: Itt található egy PoC exploit, a hibát részletező előadás pedig elérhető a 28C3 felvételei között.