Athari za Kimsingi katika Zana ya Kudhibiti Kifurushi cha Snap

Qualys ametambua athari ya tatu ya hatari mwaka huu (CVE-2022-3328) katika matumizi ya snap-confine, ambayo huja na alama ya mizizi ya SUID na inaitwa na mchakato wa snapd ili kuunda mazingira ya kutekelezwa kwa programu zinazosambazwa katika vifurushi vinavyojitosheleza. katika muundo wa snap. Athari hii inamruhusu mtumiaji wa ndani asiye na usalama kufikia utekelezaji wa msimbo kama mzizi katika usanidi chaguo-msingi wa Ubuntu. Suala hilo limerekebishwa katika toleo la snapd 2.57.6. Sasisho za kifurushi zimetolewa kwa matawi yote yanayotumika ya Ubuntu.

Jambo la kufurahisha ni kwamba, uwezekano wa kuathiriwa ulianzishwa wakati wa mchakato wa kurekebisha athari sawa ya Februari katika snap-confine. Watafiti waliweza kuandaa unyonyaji wa kufanya kazi ambao hutoa ufikiaji wa mizizi kwa Ubuntu Server 22.04, ambayo, pamoja na mazingira magumu katika snap-confine, pia inahusisha udhaifu mbili katika mchakato wa njia nyingi (CVE-2022-41974, CVE-2022-41973) , inayohusishwa na kupitisha ukaguzi wa mamlaka wakati utumaji wa amri za bahati nasibu na kazi isiyo salama kwa viungo vya mfano.

Athari katika snap-confine inasababishwa na hali ya mbio katika lazima_mkdir_and_open_with_perms() chaguo za kukokotoa, iliyoongezwa ili kulinda dhidi ya uingizwaji wa saraka ya /tmp/snap.$SNAP_NAME yenye kiungo cha ishara baada ya kuangalia mmiliki, lakini kabla ya kupiga simu kwa mfumo wa kupachika. piga simu ili kufunga saraka ndani yake kwa kifurushi katika umbizo la snap. Ulinzi ulioongezwa ulikuwa wa kubadili jina la saraka /tmp/snap.$SNAP_NAME hadi saraka nyingine katika /tmp yenye jina nasibu ikiwa ipo na haimilikiwi na mzizi.

Wakati wa kutumia /tmp/snap.$SNAP_NAME operesheni ya kubadilisha jina la saraka, watafiti walichukua fursa ya ukweli kwamba snap-confine pia huunda saraka ya /tmp/snap.rootfs_XXXXXX kwa mzizi wa yaliyomo kwenye kifurushi cha snap. Sehemu ya "XXXXXX" ya jina imechaguliwa nasibu na mkdtemp(), lakini kifurushi kinachoitwa "rootfs_XXXXXX" kinaweza kuthibitishwa katika kitendakazi cha sc_instance_name_validate (yaani, wazo ni kwamba $SNAP_NAME itawekwa kuwa "rootfs_XXXXXX" na kisha operesheni ya kubadilisha jina. itasababisha kubatilisha saraka ya /tmp/snap.rootfs_XXXXXX na mchoro wa mzizi).

Ili kufikia matumizi ya wakati mmoja ya /tmp/snap.rootfs_XXXXXX na kubadilisha jina /tmp/snap.$SNAP_NAME, matukio mawili ya snap-confine yalizinduliwa. Mara tu tukio la kwanza lilipoundwa /tmp/snap.rootfs_XXXXXX, mchakato ungezuia na tukio la pili lingeanza na jina la kifurushi rootfs_XXXXXX, na kusababisha saraka ya muda ya tukio la pili /tmp/snap.$SNAP_NAME kuwa saraka ya mizizi /tmp/snap .rootfs_XXXXXX ya kwanza. Mara tu baada ya kubadilisha jina kukamilika, tukio la pili lilianguka, na /tmp/snap.rootfs_XXXXXX ilibadilishwa na upotoshaji wa hali ya mbio, kama wakati wa kutumia athari ya Februari. Baada ya uingizwaji, kufuli ya utekelezaji iliondolewa kutoka kwa tukio la kwanza na washambuliaji wakapata udhibiti kamili wa saraka ya mizizi ya snap.

Hatua ya mwisho ilikuwa kuunda symlink /tmp/snap.rootfs_XXXXXX/tmp, ambayo ilitumiwa na kazi ya sc_bootstrap_mount_namespace() kufunga saraka halisi inayoweza kuandikwa /tmp kwa saraka yoyote katika mfumo wa faili, tangu mount() simu. hufuata ulinganifu kabla ya kupachika. Uwekaji kama huo umezuiwa na vizuizi vya AppArmor, lakini ili kukwepa kizuizi hiki, utumiaji ulitumia udhaifu mbili kisaidizi katika multipathd.

Chanzo: opennet.ru

Kuongeza maoni