A Snapd-ban biztonsági rést azonosítottak amelyet már a (CVE-2019 7304-), amely lehetővé teszi egy nem privilegizált felhasználó számára, hogy rendszergazdai jogosultságokat szerezzen (root) a rendszeren.
Azok számára, akik nem ismerik a Snapd programot, elmondhatjuk, hogy ez egy eszköztár az önálló csomagok snap formátumú kezeléséhez. A rendszerek sebezhetőségének teszteléséhez a kihasználás két prototípusát tették közzé.
- Az első, amely lehetővé teszi a támadó számára, hogy új felhasználót hozzon létre a rendszerben.
- A második lehetővé teszi a támadó számára, hogy bármilyen típusú azonnali csomagot telepítsen a rendszerre, és futtassa a kódot rootként (úgy, hogy a csomagot "devmode" módban telepíti, a csomag telepítésekor root jogosultságokkal meghívott illesztőprogram-melléklettel).
Mik ezek a kihasználások?
Az első lehetőség kiaknázására létrehozott kihasználás korábban kihagyja a beléptető ellenőrzéseket a helyi snapd szolgáltatás korlátozott API funkciójának használatához.
Ez lekérdezi a rendszert egy felhasználónévről és egy nyilvános SSH-kulcsról egy megadott e-mail címről, majd létrehoz egy helyi felhasználót ezen érték alapján.
Ennek a verziónak a sikeres kihasználásához kimenő internetkapcsolatra és a localhoston keresztül elérhető SSH szolgáltatásra van szükség.
A második kiaknázás létrejött kihasználni a második pontot, rámutatott, az előző leírt eltéréssel ellentétben, nem igényli az SSH szolgáltatás futtatását.
is az internetkapcsolat nélküli Ubuntu újabb verzióin fog működni, ellenállóvá téve a változásokkal és korlátozott környezetekben hatékony.
Ez a kihasználás Hatékonynak kell lennie olyan nem Ubuntu rendszereken is, amelyek telepítettek snapd-ot, de nem kompatibilisek az API-val a Linux shell szintaxisa miatt.
Előfordulhat, hogy egyes régebbi Ubuntu rendszerekben (például a 16.04-es verzióban) nincsenek telepítve a letöltéshez szükséges snapd-összetevők.
Ebben az esetben az exploit ezen verziója elindíthatja a függőségek telepítésére. A telepítés során a snapd frissíthető nem sebezhető verzióra.
Ha többet szeretne tudni ezekről, további részleteket kaphat A következő linken.
Miből áll ez a megállapított hiba?
A biztonsági rés oka van hogy nincs megfelelő ellenőrzés a snapd-ban egy külső socket cím feldolgozásakor a Unix-foglalatok hozzáférési jogainak értékelése során.
Ha az API-nak küldött kérelmeket Unix foglalaton keresztül dolgozza fel, ellenőrzik a csatlakozáshoz társított felhasználó UID-jét, és ennek alapján hozzák meg a hozzáférési döntést.
A felhasználó karakterláncot csatolhat «; uid = 0; » a fájlnévre a foglalattal (például hozzon létre egy "/ tmp / sock; uid = 0;" socketet), és ez a karakterlánc az ügyfél socket címének részeként kerül feldolgozásra.
A snapd paramétereinek elemzésekor a felhasználói azonosítót ciklikus keresés hozzárendeli a maszk segítségével "; Uid =" azon a vonalon, amely tartalmazza a fájl nevét is a foglalattal (például a kliens socket létrehozásakor "/ tmp / sock; uid = 0;" ez a sor "pid = 5275; uid formában van" = 1000; socket = / run / snapd.socket; / tmp / sock; uid = 0; «).
Ezért, ha van lánc "; Uid = 0;" a socket nevében az azonosítót onnan fogják hozzárendelni, és nem a tényleges UID-vel rendelkező reguláris paraméterből.
Egy helyi támadó használhatja ezt a hibát a /run/snapd.socket socket eléréséhez a snapd privilegizált API-hoz és rendszergazdai jogosultságok megszerzéséhez (a korábbi biztonsági rések a v2 / create-user és / v2 / snaps API-kat használják).
Milyen verziókat érint és létezik-e már megoldás?
A probléma megnyilvánul snapd verziókban 2.28 és 2.37 között, és az összes támogatott Ubuntu ágat érinti (14.04-től 18.10-ig), valamint az említett verziók bármelyikéből származó disztribúciókban.
A probléma a Fedora és a Debian disztribúciókat is érinti, amelyben a snapd-ot a szokásos adattárakból kínálják.
A biztonsági rést a snapd 2.37.1 kiadásban javították, valamint az Ubuntu és a Debian terjesztések csomagfrissítései.