FreeBSD-ի, IPnet-ի և Nucleus NET-ի խոցելիությունը կապված է DNS սեղմման իրականացման սխալների հետ

Forescout Research Labs և JSOF Research խմբերը հրապարակել են սեղմման սխեմայի տարբեր ներդրման անվտանգության համատեղ ուսումնասիրության արդյունքները, որոնք օգտագործվում են DNS, mDNS, DHCP և IPv6 RA հաղորդագրություններում կրկնօրինակ անուններ փաթեթավորելու համար (հաղորդագրությունների մեջ տիրույթի կրկնօրինակ մասերի փաթեթավորում): որոնք ներառում են բազմաթիվ անուններ): Աշխատանքի ընթացքում հայտնաբերվել է 9 խոցելիություն, որոնք ամփոփված են NAME:WRECK ծածկագրի տակ։

Խնդիրներ են հայտնաբերվել FreeBSD-ում, ինչպես նաև IPnet, Nucleus NET և NetX ցանցային ենթահամակարգերում, որոնք լայն տարածում են գտել VxWorks, Nucleus և ThreadX իրական ժամանակի օպերացիոն համակարգերում, որոնք օգտագործվում են ավտոմատացման սարքերում, պահեստում, բժշկական սարքերում, ավիոնիկայում, տպիչներում: և սպառողական էլեկտրոնիկա: Ենթադրվում է, որ առնվազն 100 միլիոն սարք տուժել է խոցելիությունից:

  • FreeBSD-ում (CVE-2020-7461) խոցելիությունը հնարավորություն է տվել կազմակերպել իր կոդի կատարումը՝ ուղարկելով հատուկ նախագծված DHCP փաթեթ հարձակվողներին, որոնք գտնվում են նույն տեղական ցանցում, ինչ զոհը, որի մշակումը ղեկավարվում է խոցելի DHCP հաճախորդի կողմից: դեպի բուֆերային արտահոսք: Խնդիրը մեղմացվեց այն փաստով, որ dhclient գործընթացը, որում առկա էր խոցելիությունը, աշխատում էր վերակայման արտոնություններով մեկուսացված Capsicum միջավայրում, որը պահանջում էր բացահայտել մեկ այլ խոցելիություն՝ դուրս գալու համար:

    Սխալի էությունը պարամետրերի սխալ ստուգման մեջ է, DHCP սերվերի կողմից DHCP 119 տարբերակով վերադարձված փաթեթում, որը թույլ է տալիս փոխանցել «տիրույթի որոնման» ցուցակը լուծիչին: Բուֆերի չափի սխալ հաշվարկը, որն անհրաժեշտ է չփաթեթավորված տիրույթի անունները տեղավորելու համար, հանգեցրել է նրան, որ հարձակվողի կողմից վերահսկվող տեղեկատվությունը գրվում է հատկացված բուֆերից դուրս: FreeBSD-ում խնդիրը շտկվել է դեռ անցյալ տարվա սեպտեմբերին։ Խնդիրը կարող է օգտագործվել միայն այն դեպքում, եթե դուք մուտք ունեք տեղական ցանց:

  • RTOS VxWorks-ում օգտագործվող IPnet ցանցային ներկառուցված փաթեթի խոցելիությունը թույլ է տալիս հնարավոր կոդի կատարումը DNS հաճախորդի կողմից՝ DNS հաղորդագրությունների սեղմման սխալ մշակման պատճառով: Ինչպես պարզվեց, այս խոցելիությունը առաջին անգամ հայտնաբերվել է Exodus-ի կողմից դեռ 2016 թվականին, բայց այդպես էլ չշտկվեց: Wind River-ին ուղղված նոր հարցումը նույնպես անպատասխան է մնացել, և IPnet սարքերը մնում են խոցելի:
  • Siemens-ի կողմից աջակցվող Nucleus NET TCP/IP փաթեթում հայտնաբերվել են վեց խոցելիություններ, որոնցից երկուսը կարող են հանգեցնել հեռահար կոդի կատարման, իսկ չորսը կարող են հանգեցնել ծառայության մերժման: Առաջին վտանգավոր խնդիրը կապված է սեղմված DNS հաղորդագրությունների ապասեղմման ժամանակ սխալի հետ, իսկ երկրորդը՝ դոմեյն անունների պիտակների սխալ վերլուծության հետ։ Երկու խնդիրներն էլ հանգեցնում են բուֆերի արտահոսքի՝ հատուկ ձևաչափված DNS պատասխանները մշակելիս:

    Խոցելիությունը շահագործելու համար հարձակվողը պետք է միայն հատուկ մշակված պատասխան ուղարկի խոցելի սարքից ուղարկված ցանկացած օրինական հարցման, օրինակ՝ MTIM հարձակում իրականացնելով և DNS սերվերի և զոհի միջև տրաֆիկին միջամտելու միջոցով: Եթե ​​հարձակվողը մուտք ունի տեղական ցանց, ապա նա կարող է գործարկել DNS սերվեր, որը փորձում է հարձակվել խնդրահարույց սարքերի վրա՝ ուղարկելով mDNS հարցումներ հեռարձակման ռեժիմում:

  • NetX ցանցի խոցելիությունը (Azure RTOS NetX), որը մշակվել է ThreadX RTOS-ի համար և բացվել է 2019 թվականին Microsoft-ի կողմից ստանձնելուց հետո, սահմանափակվել է ծառայության մերժմամբ: Խնդիրն առաջացել է լուծիչի ներդրման մեջ սեղմված DNS հաղորդագրությունների վերլուծության սխալի պատճառով:

Փորձարկված ցանցի կույտերից, որոնցում DNS հաղորդագրություններում կրկնվող տվյալների սեղմման հետ կապված խոցելիություններ չեն հայտնաբերվել, անվանվել են հետևյալ նախագծերը՝ lwIP, Nut/Net, Zephyr, uC/TCP-IP, uC/TCP-IP, FreeRTOS+TCP: , OpenThread և FNET: Ավելին, առաջին երկուսը (Nut/Net և lwIP) ընդհանրապես չեն աջակցում սեղմում DNS հաղորդագրություններում, մինչդեռ մյուսներն իրականացնում են այս գործողությունը առանց սխալների։ Բացի այդ, նշվում է, որ նախկինում նույն հետազոտողները արդեն հայտնաբերել էին նմանատիպ խոցելիություններ Treck, uIP և PicoTCP stacks-ում:

Source: opennet.ru

Добавить комментарий