De ûndersyksgroepen Forescout Research Labs en JSOF Research hawwe de resultaten publisearre fan in mienskiplike stúdzje fan 'e feiligens fan ferskate ymplemintaasjes fan it kompresjeskema dat wurdt brûkt om dûbele nammen yn DNS-, mDNS-, DHCP- en IPv6 RA-berjochten te pakken (dûbele domeindielen yn berjochten ferpakke dy't meardere nammen befetsje). Tidens it wurk waarden 9 kwetsberens identifisearre, dy't gearfette binne ûnder de koadenamme NAME:WRECK.
Problemen binne identifisearre yn FreeBSD, lykas yn 'e netwurksubsystemen IPnet, Nucleus NET en NetX, dy't wiidferspraat wurden binne yn' e VxWorks, Nucleus en ThreadX real-time bestjoeringssystemen brûkt yn automatisearringsapparaten, opslach, medyske apparaten, avionika, printers en konsuminteelektronika. It wurdt rûsd dat op syn minst 100 miljoen apparaten wurde beynfloede troch de kwetsberens.
- In kwetsberens yn FreeBSD (CVE-2020-7461) makke it mooglik om de útfiering fan syn koade te organisearjen troch in spesjaal ûntworpen DHCP-pakket te stjoeren nei oanfallers dy't op itselde lokale netwurk sitte as it slachtoffer, wêrfan de ferwurking troch in kwetsbere DHCP-kliïnt liede nei in buffer oerstreaming. It probleem waard fermindere troch it feit dat it dhclient-proses wêryn de kwetsberens oanwêzich wie, rûn mei reset-privileezjes yn in isolearre Capsicum-omjouwing, dy't nedich wie om in oare kwetsberens te identifisearjen om út te gean.
De essinsje fan 'e flater is yn ferkearde kontrôle fan parameters, yn it pakket weromjûn troch de DHCP-tsjinner mei DHCP-opsje 119, wêrtroch jo de list "domeinsykje" kinne oerdrage nei de resolver. Ferkearde berekkening fan de buffergrutte dy't nedich is om útpakte domeinnammen te foldwaan, late ta dat troch oanfaller kontrolearre ynformaasje skreaun waard bûten de tawiisde buffer. Yn FreeBSD waard it probleem yn septimber ferline jier fêstlein. It probleem kin allinich brûkt wurde as jo tagong hawwe ta it lokale netwurk.
- In kwetsberens yn 'e ynbêde IPnet-netwurkstapel brûkt yn RTOS VxWorks lit potinsjele koade-útfiering op' e DNS-kliïntkant mooglik meitsje fanwege ferkearde ôfhanneling fan DNS-berjochtkompresje. As it die bliken, waard dizze kwetsberens foar it earst identifisearre troch Exodus werom yn 2016, mar waard nea reparearre. In nij fersyk oan Wind River gie ek net beantwurde en IPnet-apparaten bliuwe kwetsber.
- Seis kwetsberens waarden identifisearre yn 'e Nucleus NET TCP/IP-stapel, stipe troch Siemens, wêrfan twa kinne liede ta útfiering fan koade op ôfstân, en fjouwer kinne liede ta ûntkenning fan tsjinst. It earste gefaarlike probleem is relatearre oan in flater by it dekomprimearjen fan komprimearre DNS-berjochten, en it twadde is relatearre oan ferkearde parsing fan domeinnammelabels. Beide problemen resultearje yn in bufferoerstream by it ferwurkjen fan spesjaal opmakke DNS-antwurden.
Om kwetsberens te eksploitearjen, moat in oanfaller gewoan in spesjaal ûntworpen antwurd stjoere op elk legitimearre fersyk ferstjoerd fan in kwetsber apparaat, bygelyks troch in MTIM-oanfal út te fieren en it ferkear tusken de DNS-tsjinner en it slachtoffer te bemuoien. As de oanfaller tagong hat ta it lokale netwurk, dan kin hy in DNS-tsjinner starte dy't besiket om problematyske apparaten oan te fallen troch mDNS-oanfragen yn útstjoermodus te ferstjoeren.
- De kwetsberens yn 'e NetX-netwurkstapel (Azure RTOS NetX), ûntwikkele foar ThreadX RTOS en iepene yn 2019 nei't se oernommen waard troch Microsoft, wie beheind ta tsjinstferliening. It probleem wurdt feroarsake troch in flater by it parsearjen fan komprimearre DNS-berjochten yn 'e resolver-ymplemintaasje.
Fan 'e hifke netwurkstapels wêryn gjin kwetsberens fûn waarden relatearre oan kompresje fan werhelle gegevens yn DNS-berjochten, waarden de folgjende projekten neamd: lwIP, Nut/Net, Zephyr, uC/TCP-IP, uC/TCP-IP, FreeRTOS+TCP , OpenThread en FNET. Boppedat stypje de earste twa (Nut/Net en lwIP) hielendal gjin kompresje yn DNS-berjochten, wylst de oaren dizze operaasje sûnder flaters útfiere. Dêrnjonken wurdt opmurken dat earder deselde ûndersikers al ferlykbere kwetsberens hawwe identifisearre yn 'e Treck, uIP en PicoTCP-stacks.
Boarne: opennet.ru