[HWSW]

Tegnap biztonsági figyelmeztetést adott ki a Microsoft, amelyben egy távoli kódfuttatásra lehetõséget adó sebezhetõséget ismertetett, illetve közzétett egy programot, amellyel csökkenthetõ a kockázat.
http://www.hwsw.hu/hirek/45124/microsoft-dll-webdav-biztonsag-serulekenyseg.html

[KisSzikra]

Hm. Szóval programok telepítésekor vagy futtatásakor egy távoli DLL-t hív meg a program? A wintûzfalnak ezt nemkéne jelezni?

[lordrolee]

Szerintem errõl szó sincs.
Akkor van gebasz, ha van egy alkalmazásod amivel egy távoli fájlt nyitsz meg és ugyanazon a helyen az állomány könyvtárában van egy ugyanolyan nevû DLL file, amit az alkalmazás használ akkor az fut le és nem az ami a windowssystem32-ben vagy az adott alkalmazás könyvtárában (pl program filesalkalmazás). És ha már egy távoli állományt nyitsz meg, ahhoz azért férhetsz hozzá, mert a tûzfaladban már beállítottál egy kivételt az adott távoli erõforráshoz.

Sok szoftver gyanítom azért nem használ abszolút útvonalat a DLL-ekhez, mert a fontosabb lokációk mint pl a %SystemRoot%system32 vagy a program filescommon files... benne van alapból a PATH környezeti változóban, így az ezekben a könyvtárakban lévõ DLL-ek és futtatható állományok bárhonnan elérhetõek.

Ha hülyeséget írtam, akkor majd egy szaki kijavítja, de kb ezt így képzelem el.

[Ytse]

@lordrolee: Jól írod, errõl van szó. Kiegészítettem egy kicsit az anyagot hogy ne legyen félreérthetõ.

[Root_Kiskacsa]

Eltartott egy darabig, amíg megértettem a probléma lényegét. (Mondjuk még mindig nem vagyok teljesen biztos benne.) Egy exploithoz az alábbi feltételeknek kell teljesülnie:
- Az alkalmazásban ne legyen definiálva a DLL-ek keresési útja. Ilyenkor alapértelmezés szerint a PATH-ban, System32-ben és más helyeken keresi a DLL-t az app, VÉGÜL az aktuális elérési útvonalon. (Ez még fontos lesz.)
- Az alkalmazás egy távoli fájl megnyitásakor tegye is át az aktuális elérési útvonalat a távoli fájl útvonalára.
- A távoli fájl mellett legyen egy preparált DLL.
- A távoli fájl megnyitását követõen próbálja meg az alkalmazás betölteni a DLL-t.

Mivel alapértelemzés szerint nem az aktuális mappában kezdi meg a kutakodást a Windows, így általános DLL-ekkel, mint pl. a ComDlg32.DLL (ami a fájlmegnyitás, mentés, stb. dialógusablakokat kezeli), nem mûködik a dolog, csak alkalmazás specifikusokkal. Ez a hiba annyira nehezen kiaknázható, és annyi mindennek kell összejönnie, hogy kíváncsi vagyok, vajon mely programok lesznek érintettek. És azok mennyire veszélyeztettek, hogy távoli fájlt akarnak majd vele megnyitni. Mert pl. ha az MSPaint érintett, akkor is ritka az olyan ember, akinél MSPainthez vannak társítva a képek.

[Balaimali]

A sebezhetõség az sebezhetõség, javítani kell!

[sony88]

Én annyival egészitenem ki Root Kiskacsa tökéletes megfogalmazását , csak a tüzfalhoz hogy teljes legyen a kép hogy a Win tüzfala ( XP ) akkor szol ha már a vak is látja hogy a hálozatot keresi valami ( WarCraft )
az újabb Winek ( Vista , 7 ) a már elöbb észreveszi viszont csak akkor ha nem alapértelmezett porthoz van hozzárendelve a profil...de többet ér 3.ik féltöl származó tüzfal azzal ki lehet szürni...(vagy nem megjegyeztetni vele h ki meg hol megy ki - ez pl: MSN rohat érdekes mert már egy személy hivásánál 6x megkérdezi hogy mehet vagy nem?)
Különben tökéletesen igazad van Root Kiskacsa ehhez az a legjobb kivitelezhetöség ha a te gépeden tudom mi van , mit használsz és direkt hozzád igazitom az explolitot ( ha jól irtam )

[Root_Kiskacsa]

Kicsit továbbgondolva a dolgot, annyit korrigálok, hogy a második feltételnek nem feltétlenül kell teljesülnie. Azaz az alkalmazásnak nem feltétlenül kell machinálnia az útvonallal, mert ha társítás alapján nyitnak ki egy fájlt és így nyílik meg a sérülékeny alkalmazás, akkor az aktuális útvonal eleve a távoli fájlon lesz.

[sony88]

Mindent összevetve akkoris nehéz kijátszani , aki kicsit is ért a géphez már nemfeltétlen ugrik be (?)
a nagymama meg MSN nemhiszem hogy RapidShareezik meg MegaUplodozik szoval aki meg töltöget az nézzen szét mit használ

[debaj]

Mondjuk aki tőtöget agyba-főbe, az nem feltétlenül "ért a géphez", sőt.

[sony88]

Jó ez igaz...szoval a letöltö menedzserek nem olyan fileokat töltenek a torrentozok meg megintcsak szoval arra akartam kijukadni hogy olyan progamokkal lehet elvileg eljátszani amik ismertek és szükségük van hálózatra , nem a frissitésre gondoltam...az online filmezéshez meg nem dll töltünk be ugyebár...

[lordrolee]

@Root_Kiskacsa: "- Az alkalmazásban ne legyen definiálva a DLL-ek keresési útja. Ilyenkor alapértelmezés szerint a PATH-ban, System32-ben és más helyeken keresi a DLL-t az app, VÉGÜL az aktuális elérési útvonalon. (Ez még fontos lesz.)"

Ez sztem pont fordítva van. Ha nincs definiálva a DLL elérési útja, akkor elõször a futtatás könyvtárában nézi meg, majd a PATH-ban. Legalábbis winme-ig biztosan így volt, sõt ha jól rémlik még xp-ben is.
Ha tévednék akkor mea culpa és egyebek.

Szerk: közben rájöttem, hogy én egy alkalmazás futtatására gondoltam és nem egy fájl megnyitására.

Nomeg az ilyen jellegû probléma microsoft-os cuccoknál lehet, hogy nem jön elõ, hanem inkább 3rd party programoknál, ahol a program készítõje nem drótozta be az alkalmazásába az elérési utat..

Szerkesztette: lordrolee 2010. 08. 24. 12:16 -kor

[didyman]

Idézet: sony88 - Dátum: 2010. 08. 24. 13:05

Jó ez igaz...szoval a letöltö menedzserek nem olyan fileokat töltenek a torrentozok meg megintcsak szoval arra akartam kijukadni hogy olyan progamokkal lehet elvileg eljátszani amik ismertek és szükségük van hálózatra , nem a frissitésre gondoltam...az online filmezéshez meg nem dll töltünk be ugyebár...

Höhö! Tudnék mutatni ilyen managerlaptopokat, hogy miket nem találok rajtuk pl. egy cím begépelése közben az előzmények között, de hivatali titkot sért

[kisrobert]

@didyman: hát igen ilyenkor pirulhat az ember, hogy semmit nem látott. De legalább a privát módot használhatnák... ...vagy az elõzmények törlése, vagy valami.

[Root_Kiskacsa]

@lordrolee: Me-ig volt így, lásd a cikk végén is linkelt DLL-ekre vonatkozó irányelvekben:
"Make sure that safe DLL search mode is enabled. This places the user"s current directory later in the search order, increasing the chances that Windows will find a legitimate copy of the DLL before a malicious copy. Safe DLL search mode is enabled by default starting with Windows XP with SP2 and is controlled by the HKLMSystemCurrentControlSetControlSession ManagerSafeDllSearchMode registry value. "

[G.Denes]

Ez a cikk óriási LOL:
felhasználói szempontból:
aki tűzbe teszi a karját, annak érdekes módon össze fog égni a karja.
Következésképp, hogyan lehet védekezni ellene? Ne tedd tűzbe a karodat, ez
ilyen egyszerű. Ne futtass semmit távoli gépről. ENNYI.

(Persze még egyszerűbb ha nem Windowst használsz) Másfelől viszont: " Microsoft", "távoli kódfuttatás", "<b>izraeli</b>", "A Microsoft <b>igyekezett leszögezni</b> hogy a sérülékenység nem a Windowsban van" &gt; "igen
kínos lenne Redmondra nézve"...

Egyáltalán NEM vagyok meglepve, hogy újabb
(csak az idén vagy a 20-30adik "Hibára" derül fény amellyel "véletlenül"
történetesen pont a Windowsok felett kívülről átvehető az irányítás.

Szerkesztette: G.Denes 2010. 08. 24. 16:34 -kor

[cjjosh]

@Root_Kiskacsa: Érdekes, a Dynamic-Link Library Security pont mást ír.

Assuming safe DLL search mode is enabled and the application is not using an alternate search order, the system searches directories in the following order:

1. The directory from which the application loaded.
2. The system directory.
3. The 16-bit system directory.
4. The Windows directory.
5. The current directory.
6. The directories that are listed in the PATH environment variable.

Szóval lordrolee-nak van igaza. A Windows alapból mindig az ALKALMAZÁS könyvtárát nézi elõször, és csak késõbb az aktuális könyvtárat (5. pont).

Szerintem Te keverted a "user"s current directory"-t a "directory from which the application loaded"-dal.

[sarocker]

@G.Denes: Nem lennék meglepve ha a többi modern operációs rendszerben is teljesen hasonlóan mûködne a dolog. Csak ugyebár kinek éri meg a többi hibáját kihasználni, amikor a desktop világban a használati arányuk a béka segge alatt van?

[cjjosh]

A hiba egyébként is a dinamikusan betöltött dll-ekrõl szól szerintem, tehát a late binding-ra vonatkozik.

"Wherever possible, specify a fully qualified path when using the LoadLibrary, LoadLibraryEx, CreateProcess, or ShellExecute functions."

Ha egy dll-t referenciaként adunk meg a projektben, akkor nem hiszem, hogy ebbõl probléma lehet. Kivéve akkor, ha a kérdéses dll-rõl feltételezzük, hogy mondjuk a system, windows directory-ban található, és a támadó a saját dll-jét elõrébb rakja a keresési listának megfelelõen.

Ezt ki is próbálom.

[debaj]

Idézet: G.Denes - Dátum: 2010. 08. 24. 17:31

Ne futtass semmit távoli gépről. ENNYI.

Aztán ez is olyan, hogy néha elég nehéz elkerülni a dolgot.