security

2007
23
feb

RunAs


Az Internet Explorer 7 megjelenése számomra csupán azt jelentette, hogy egyel bővült azon böngészők száma, mellyel kénytelen vagyok tesztelni, ha webfejlesztek. Az IE6-ot azonban rendszeresen használtam, bár ennek nem is voltam teljes mértékben tudatában.

Windows használata esetén igyekszem a felhasználásból eredő kockázatokat a minimális szinten tartani ezért jellemzően korlátozott, sőt erősen korlátozott felhasználói fiokot használok. Ez azzal a kényelmetlenséggel jár, hogy gyakorta vagyok kénytelen a runas parancsot alkalmazni. És itt jön a képbe az IE6, hisz aki hozzám hasonlóan jár el az nagyon jól tudja, hogy gyakorta van szükség a filerendszer vagy adott esetben a Vezérlőpult elérésére a saját felhasználóménál “erősebb” jogosultságokkal. Ezzel nincs gond addig amíg az adott funkció egy runas /user: paranccsal elérhető. Az appwiz.cpl-t futtatva a runas-el például gond nélkül tudok telepítgetni és eltávolítani vagy az mmc konzolt indítva elérek egy rakás funkciót amire szükségem lehet. Van azonban, hogy a Vezérlőpult egészét szeretném erősebb jogosultágokkal elérni, ilyenkor jön jól hogy az IE6-ot futtatom a megfelelő felhasználóval, majd egy helyi címre navigálva (pl.: c:\) már elérhető a fastruktúrából a Vezérlőpult. Volt ez így egészen az IE7-re való frissítésig, mikoris megtapasztaltam, hogy mikor egy helyi címre navigálok az IE7 feldob egy explorer (értsd Windows Intéző) ablakot, de azt a bejelentkezett felhasználó jogosultágaival, tehát adtam a szarnak egy nagy pofont.

Az alapprobléma ugyanis az, hogy az explorer.exe nem indítható el a runas segítségével. Hittem ezt addig amíg el nem olvastam Aaron Margosis a témával foglalkozó, majd három éves bejegyzését: RunAs with Explorer. A dolog ugyanis egy registry érték átbillentésével megoldható, egészen pontosan a

HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Advanced\\SeparateProcess

értékét kell 1-re változtatni az érintett felhasználó (pl.: administrator) profiljában és az explorer.exe már indíthatóvá is válik a másik felhasználó nevében. Aaron Margosis ezen túl további megoldásokat is kínál a fent linkelt címen. Remélem, hogy nem csak nekem volt ez új :D

2007
11
feb

Illegal LF-CR combination in HTTP header


A címben szereplő hibaüzenet okozott egy kis fejtörést ma reggel. A történet ugyanis arról szólt, hogy a DMZ-ben lévő webszerver HTTPS portjára kellett beforgatni csomagokat a tűzfal (CheckPoint) magadott portjáról. Rutin feladatnak tűnt mégsem működött. A böngésző a következő hibaüzenetet dobta:

The connection to servername:portnumber was interrupted while the page was loading.

Engedélyeztem a tűzfalon, hogy ugyanazon a porton forgassa be a csomagokat a webszervernek ahol a HTTPS figyel. Ezt követően a kapcsolat gond nélkül felépült. Tévesen azt feltételeztem, hogy a HTTPS és a címfordítás között keresendő a hiba. Elkezdtem turkálni a logot a SmartView Trackerrel és akkor bukkantam rá a hibaüzenetre:

A kapcsolatot a CheckPoint elfogadta majd eldobta:

message_info: Illegal LF-CR combination in HTTP header

hibaüzenettel. A Googleben történő rövid keresgélést követően ráakadtam a megoldásra. A SmartDefense-nek van egy "General HTTP worm catcher" modulja és ez volt a felelős a galibáért. Kikapcsoltam a modult és a hiba elhárult. Legyen a protokoll HTTPS, legyen ott címfordítás, nem számít. A kapcsolat most már működik. Minden esetre akkor is érdekes, hogy ha a címfordítást kihagyjuk a képletből akkor a "General HTTP worm catcher" bekapcsolt állapotában is működik a rendszer. A tűzfalon átutazó csomagokhoz maga a CheckPoint piszkál hozzá, majd ezt követően kiszűri azokat. Ha minden igaz, akkor már javítást is adtak ki erre a hibára.

Nem ez volt az első eset, amikor a SmartDefense megviccelt. Mikor ismeretessé vált a Windows Metafile file-ok sebezhetősége akkor is jelent meg egy SmartDefense modul amely meglehetősen érdekes dolgokat művelt. Leszaggatta a LAN-ról azokat a klienseket, akik egy olyan hálózati megosztáshoz próbáltak hozzáférni amely – teljesen ártatlan – TIFF állományokat is tartalmazott. Ejjj, mégiscsak az iptables a kedvencem :D