Soron kívül javítja a Microsoft az MS14-068 biztonsági figyelmeztetőben leírt biztonsági sebezhetőséget

Microsoft, Windows

A Microsoft MSRC csapata ma bejelentette, hogy 2014. november 18-án soron kívül javítja az MS14-068 biztonsági figyelmeztetőben leírt kritikus biztonsági sebezhetőséget.

A Windows Kerberos Key Distribution Center-ében egy privilégiumszint-emelésre lehetőséget adó sebezhetőség található. A sebezhetőséget sikeresen kihasználó, privilégium nélküli tartományi (domain) felhasználó tartományi rendszergazda (domain administrator) jogokhoz juthat. A támadó az emelt privilégiumszint birtokában képes kompromittálni a tartomány összes számítógépét, beleértve a tartományvezérlőket is (domain controller). A támadónak érvényes tartományi jogokkal kell rendelkeznie a sebezhetőség kihasználásához. A biztonsági figyelmeztető kiadásakor a Microsoftnak tudomása volt egy célzott, korlátozott támadásról, ami ezt a sebezhetőséget próbálja kihasználni.

További részletek itt. Az MSRC bejelentése itt olvasható.

( trey | 2014. 11. 18., k – 19:45 )

Még nem értem a legutóbbi patchkedd végére, de már kezdhetem is újra. Beleértve a könyörgésekkel, hogy "légyszi, legyen már valahol 10 perc, hogy újraindíthassam"... Igen fasza.

--
trey @ gépház

Az újraindítás, frissítés az azt jelenti, hogy addig nem termel az aki használja. Ez nagyon sokba is kerülhet, itt nem Gizike órabéréről van szó, hanem mondjuk egy szoftverfejlesztő 60-100e forintos napidíjjal, akkor mennyibe kerül egy minden program becsuk, újraindítás, frissítés, minden elindít, a fejlesztő újra felveszi a fonalat. Ez nagyjából fél-egy óra.

Marhaság. Szerver esetén ahol a leállás pénzbe kerül, ott alap a klaszter és a cluster aware patching, azaz nincs szolgáltatás leállás.
Kliens esetén, akinek egy órán át tart a restart és a "fonal felvétele" ott valami nagyon el van rontva. A nagyon magas óradijú fejlesztő nyilván SSD-vel dolgozik, ahol programok becsukásával újra elinditásával sincs 2 perc egy restart. A fonal felvtéle emberfüggő, de ha ebből jön ki a maradék 58 percnyi leállás, akkor remélem kávézni és pisilni sem megy ki az illető egy hónapban egyszer sem, mert különben nagy a baj...

"Marhaság. Szerver esetén ahol a leállás pénzbe kerül, ott alap a klaszter és a cluster aware patching, azaz nincs szolgáltatás leállás."

Egy tökéletes világban. Milliárdos forgalmakat bonyolító - EU-s projekteken dolgozó, AUDI beszállító stb. - cégekről tudok, ahol egy darab szerverrel oldanak meg mindent (levelezés, fájlmegosztás, termelésirányítás stb.). Nem is hajlandóak nagyon költeni többre, a felhőt élből elvetik (paranoia).

Számukra az informatika egy szükséges rossz, amire csak akkor hajlandóak költeni, ha már szó szerint rongyokban lóg. Van, amelyik nem engedi meg a távoli elérést (paranoia, de annyira, hogy a szolgáltatócég embereit is lenyomoztatja). Náluk az dívik, hogy személyesen kell kiautózni, átvilágítás után bemenni, majd ott felügyelet alatt dolgozni.

Értem amit mondasz, de az élet másról (is) szól, mint az MSFT által elképzelt, steril laborokban bemutatott dolgokról, illetve mintacégeknél, óriásvállalatoknál kiépített, sok csillió dollárba kerülő rendszerekről.

Próbálj meg KKV-kat üzemeltetni Magyarországon és rájössz, hogy a 7-8 éves vasak még zsír újnak számítanak, a Windows 2003 Server még a "jó az, megy, minek új" kategória és még hosszasan sorolhatnám.

Ezeknél a cégeknél a megoldásszállító, vagy támogatást nyújtó partner évente teszi le az asztalra a fejlesztési javaslatait (mert a feladatkörébe ez is beletartozik) és évente söprik le az asztalról azzal, hogy majd máskor.

--
trey @ gépház

Értem, tehát a cluster aware patching nem működik, bármi baj megtörténhet és amúgy sincs rá pénz, ellenben az reális nyafogás (amiről ugye ez a thread szól) hogy szegény überdrága órabérű fejlesztő órákat veszit azzal, hogy restartolni kell havonta egy patch miatt. Az ilyen ritka esetben, mint a mostani (ami fejlesztői gépet nem is érinti, csak a DC-ket) pedig 2x kell ezt az elképesztő kiesést elszenvednie.
Értem...

A valóság pedig az, hogy aki a "Windows 2003 Server még a "jó az, megy, minek új"" annak épp rohadtmindegy, hogy havonta 1x, 2x vagy 10x kell restartolni egy szervert, hátmég a kliens gépeket. Erre mondtam, hogy akinek ez valóban számit, az röhögve megoldja. Nem reális probléma, csak a szokásos esztelen picsogás.

Hacsak ki nem jött valami olyan Windows Update, ami miatt kék, fekete stb. halál nem volt és nem hívták vissza....

A nyáron kettő ilyen is volt.

Lazán kapcsolódik:

Szartam is ettől a KDC frissítéstől, hogy mennyire tesztelték ki. A patch kedd csomagból állítólag az utolsó pillanatban kivették.

Az hogy a KDC meg nem működik, elég kritikus a domain szempontjából. Ha pedig nem megy a domain, akkor nincs Exchange, nincs vCenter, nincs backup és nincs gyakorlatilag semmi, a címtárra épül.

--
trey @ gépház

"Ha pedig nem megy a domain, akkor nincs Exchange, nincs vCenter, nincs backup és nincs gyakorlatilag semmi, a címtárra épül. "

Nyilván ezért van "szar, elavult" klaszter a DC-ken, ha az egyik épp restartol, addig a másik viszi tovább az egészet. Csak ismételni tudom magam, ahol a DC 2-3 perces kiesése problémát okoz, ott nem egy DC van. Ahogy nem egy fileszerver, nem egy exchange szerver, nem egy proxy szerver stb-stb. Ez errefelé evidencia.
(persze nem igazi klaszter, nem kell neki közös storage, szimplán elosztott-redundáns rendszer)

Nem erről beszéltem. Hanem arról, hogy a frissítés szar, felteszed mindegyik DC-re és két nap múlva kiderül, hogy újrakiadják, mert el van szabva (lásd: schannel update).

Ez ellen a cluster nem véd. Egyébként a több DC esetén semmiféle cluster nem kell. Egy DC rebootolása nem okoz kiesést, de nem is erre céloztam.

--
trey @ gépház

"Újrakiadják, akkor már 3x kell abban a hónapban restartolni. És?"

Ha két DC-d van, akkor semmi. Ha 4 tucat ügyfeled van, akkor már gond, ha ennél több, akkor még nagyobb.

Ki kéne nézni az egy szem vállalat rendszergazdája vagyok fotelből egy tágabb világra.

--
trey @ gépház

Ez a nem reális probléma (szerinted) a rideg magyar valóság az ország jelentős részén. Örülök, hogy neked minden a segged alá van tolva. Könnyű úgy beszélni, ha a munkád elvégzéséhez minden rendelkezésre áll.

Nem értem, hogy miért véded ezt az elavult megoldást. Lazán kapcsolódik: bámulatos, hogy hol tart már a tudomány

És most gyere azzal, hogy szerinted nem lenne jó, ha Windowsokat is úgy lehetne patchelni, hogy nem kéne őket rebootolni...

--
trey @ gépház

Vagy egy tucat szervert üzemeltetek, jópár cégnek, egyiknél sem okoz problémát. Ahol probléma lenne, ott klaszter van, az összes többin, meg kibirják éjszaka az 5 percnyi leállást havonta 1x, e hónapban 2x.

Bár te magad linkelted, lehet nem értetted, ez csak a DC-ket érinti kritikusan, még a member servereket sem. DC-ből meg ugye minimum 2 van, ahol 1 van, ott meg édesmindegy, hogy újra kell inditani valamit éjszaka.

"Nem értem, hogy miért véded ezt az elavult megoldást. "

Nem védem, természetesen jobb lenne, ha nem kellene, de irreális hülyeség azon pörögni, hogy a drága programozó mennyi idejét elveszi a havi 1 restart. (ha esetleg megnéznéd, hogy miről is szól a thread, mert úgy tűnik eddig még nem tetted meg)

Ja a tucat szerverben van 3 debian is, ejj, azokat is restartolni kell, úgy tűnik nem mindenhova jutott még el a "tudomány" :)

Éjszaka akkor dolgozok, ha megfizetik (szintén rideg magyar valóság).

"Bár te magad linkelted, lehet nem értetted, ez csak a DC-ket érinti kritikusan, még a member servereket sem."

Pontosan értettem.

"C-ből meg ugye minimum 2 van, ahol 1 van, ott meg édesmindegy, hogy újra kell inditani valamit éjszaka."

Goto eleje.

"Nem védem, természetesen jobb lenne, ha nem kellene, de irreális hülyeség azon pörögni, hogy a drága programozó mennyi idejét elveszi a havi 1 restart. (ha esetleg megnéznéd, hogy miről is szól a thread, mert úgy tűnik eddig még nem tetted meg)"

Én ilyenről nem beszéltem, annak mondd, akivel ezen flameltél. Énvelem arról beszéltél, hogy ahol kritikus munka van, ott cluster van. Én meg erre mondtam, hogy a mesében.

"Ja a tucat szerverben van 3 debian is, ejj, azokat is restartolni kell, úgy tűnik nem mindenhova jutott még el a "tudomány" :)"

Nem üzemeltetek Debian szervert, nem érint. Természetesen ott is szívesen látnám, hogy a reboot nélküli kernelpatchelést (amit lassan évek óta használok Ubuntu-n). Én nem nevezem ezt irreális hülyeségnek. És mivel a magam bőrén érzem, hogy ez milyen jó, nem gyártok mindenféle elméleteket a régi, szar megoldás mellett.

(Egyébkén, ha már flame irányba vitted el az egészet... Mondjuk ritka is az olyan Debian szerver, amit ha megtörnek egy hibával, akkor az egész domaint (értsd DC-k, szerverek, kliensek) újra kell húzni, mert gyakorlatilag az egész vállalat 0wnolva van.)

--
trey @ gépház

""C-ből meg ugye minimum 2 van, ahol 1 van, ott meg édesmindegy, hogy újra kell inditani valamit éjszaka."

Goto eleje."

Nincs hova visszamenni. Ha te egyetlen árva, ksplice-os ubuntu-ra bizod az általad üzemeltett rendszerek kritikus szolgáltatásait (azaz, azokat amiknek egy 3 perces leállás komoly kiesést okoz) ahhoz nem nagyon van mit hozzáfűzni. Ja de: goto eleje.

" Én nem nevezem ezt irreális hülyeségnek."

Mint ahogy senki nem is nevezte az online kernel patchet irreális hülyeségnek, de nyugodtan ferdits még.

"Mondjuk ritka is az olyan Debian szerver, amit ha megtörnek egy hibával, akkor az egész domaint (értsd DC-k, szerverek, kliensek) újra kell húzni, mert gyakorlatilag az egész vállalat 0wnolva van.)"

Tényleg, amikor root jogot szerezve viszik a shadow file-t, az összes accountot, jelszót, akkor tényleg felesleges volna bármit is újrahúzni azon a rendszeren és azokon a rendszereken amiket authentikált :)

Össze-vissza csapongsz. Nem Ubuntu-s Ksplice-ra bíznom / bíznám, hanem azt mondtam, hogy azon kitesztelve érzem, hogy milyen jó. Az Oracle/SUSE ezt fizetős, supportált szolgáltatásban nyomja. Azt mondtam, hogy ezt látnám szívesen mindenhol.

"Mint ahogy senki nem is nevezte az online kernel patchet irreális hülyeségnek, de nyugodtan ferditsd még."

Tehát abban megegyezhetünk, hogy ez egy must have funkció lenne Windowson is és a reboot egy rákfene, amitől jó lenne megszabadulni, cluster ide vagy oda?

"Tényleg, amikor root joggal viszik a shadow file-t, az összes accountot, jelszót, akkor tényleg felesleges volna bármit is újrahúzni azon a rendszeren :)"

Egy gép vs. domain. Biztos értetted?

--
trey @ gépház

"Tehát abban megegyezhetünk, hogy ez egy must have funkció lenne Windowson is és a reboot egy rákfene"

Nem. Goto http://hup.hu/cikkek/20141118/soron_kivul_javitja_a_microsoft_az_ms14-0…

"Egy gép vs. domain. Biztos értetted?"

Biztos érted, hogy mi van olyankor amikor viszik a központi cimtárat futtató linuxos gép adatbázisát (pl. openldap)? Ugyanaz mint amikor a DC-t viszik, ill. az AD adatbázisát. Minden user, minden computer account jelszava kompromittálva.

Hát ha nem, nem. Nekem mindegy, hogy te ragaszkodsz ahhoz, hogy a Windows folytonos rebootja az milyen jó dolog. Esetleg majd ha Redmondban is meginnoválják ezt a funkciót (egy 10 év múlva), akkor majd elolvasom az éppen aktuális propagandát, hogy ez miért hiperjó.

--
trey @ gépház

" te ragaszkodsz ahhoz, hogy a Windows folytonos rebootja az milyen jó dolog."

Lassan abbahagyhatnád már, hogy komplett hazugságokat állitasz be úgy, mintha irtam volna. Senki nem irt ilyet, hogy ez jó dolog. Csak jópár példával alátámasztottam, hogy nem akkora probléma, mint egyesek előadják, marginális kérdés normálisan üzemeltetett rendszerek esetén.

Ha majd lesz ilyen a windows-ban, az remek lesz. Csak attól még ott, ahol számit, ugyanúgy klaszter lesz, ahol meg nem számit, ott akkor se fog számitani. Majd megsimogatják a fejedet, hogy nem 3 percig állt a szolgáltatás, hanem csak 30 mp-ig, bár senki észre se vette egyiket se. Ezt kéne felfogni.

Mert az azure-ban a problémát az újrainditások okozták vagy a cluster-ek? Vagy csak megint egy teljes marhaságra tereled a témát, aminek semmi köze a thread-hez, ha már teljesen benézted a komplett hálózat kompromittálódását is.
(nyilván, ksplice-al, nem történt volna hiba az azure-ban, tudjuk...)

Nem dolgoztál még IBM, Oracle,fejlesztőeszközökkel, alkalmazásszerverekkel. Ezek indulása még ssd-vel is iszonyat lassú, hiszen ssd-ről is csak be kell tölteni a memóriába azt a 2-4 GB-ot amik ezek foglalnak, el kell indítani az adatbázisokat. Nem beszélve ha van úgy 15-20 projecten kell dolgozni ezek fordítási ideje sem 2 perc. Nem azt mondom, hogy ez így jól van, de ha ezzel kell dolgozni, mert a vezetőknek eladták, hogy milyen jó lesz. Most láttam saját szememmel valami Oracle csoda fejlesztőeszköz(JDeveloper 12c SOA csoda) 8GB RAM-al szaggatott, kérdeztem a beszállítót mennyi kell neki, azt mondta 12GB-al már normálisan megy, de így is 15 perc volt mire elindult, üresen egyetlen project nélkül. A cég már megvette, mert eladták a fejeseknek, hogy ezzel gyorsabb lesz a fejlesztés, ők meg bevették.

Engem egy CentOS 6.6 is megkér egy hónapban ~2x hogy indítsam újra, és nem csak kernel frissítés után (gondolom itt a ksplice és társaira gondoltál). Pl. frissül egy mysql, ami épp fut is. Nyilván ha újraindítom a mysqld-t akkor tulajdonképpen megoldottam a dolgot, de még csak azt sem közli a frissítési folyamat, hogy milyen alternatíváim vannak restart helyett. Nyilván windowson kicsit más a helyzet, de teljesen érthető, hogy ha futó szolgáltatást updatelnek akkor valamit újra kell indítani, akkor meg már egyszerűbb magát a windowst.

Nem, nem és nem! Ez egy elképesztően nagy problémákat okozó hiba, ami nélkül nem is lehet üzemeltetni szervert. Sőt, klienst se, mert elképesztő mértékű pénzpazarlás amig újraindul a gép havonta 1x-2x. Az néhány százmillió windows (és linux) szerver amit mégis újra kell inditani, az csak délibáb, a vesztébe rohanó és kihaló technológia emléke!

Mindenki aki mást mond az vagy hülye vagy microsoft propagandista. Vagy még rosszabb!!!négy!

A "teljesen érthető"-ről annyit, hogy a hanyag Microsoft programozókból 2003-ban már Bill Gates-nek is elege lett. Az idevágó anekdota szerint Redmondban a körmére néztek a programozóknak, hogy egy-egy frissítés után valóban kell-e reboot vagy csak lustaságból (mert ez volt az egyszerűbb) azt hívta meg a programozó a patch telepítésének végén. Állítólag keményen indokolni kellett, hogy egy patch miért igényel reboot-ot.

Pontosan felismerték, hogy a reboot - főleg abban a mennyiségben, ahogy űzték (és űzik jelenleg is) - káros. A Trustworthy Computing bejelentésének egyik részeként kitértek a patchmenedzsmentre is. Annak idején (10 éve) a Microsoft-közeli Netacademia előadásain F. Marcell is beszélt róla, de aki kíváncsi rá, most is beleolvashat a dokumentumokba:

Microsoft's Software Update Strategy - Download Center

Benne van a szükségtelen reboot-ok minimalizálására való törekvés. A rendszerek reboot-olása problémás. A patch kedd mint olyan sem véletlenül jött létre. A célja az volt, hogy az IT-kről levegye a terhet, és havi egy, tervezhető időben történjen a rendszerek frissítése. Az sem véletlen, hogy kedd, nem hétfő. Azért kedd, mert a hétfők általában problémásak. A patch kedd további célja volt, hogy a frissítések egy reboot-tal megoldhatók legyenek.

Az egy másik kérdés, hogy ez meg biztonsági szempontból faszság, de ez most nem tartozik ide.

Szóval bohóckodhatunk akörül, hogy a rebootok nem is olyan nagy problémák, szajkózhatjuk, csak az a baj, hogy a Microsoft-nál is pontosan tudják, hogy probléma. Erre itt játsszuk a hülyét, hogy nem az.

--
trey @ gépház

FYI: A Microsoftnak 10+ éve van megoldása a hot patchingre. A PaXTeam le is írta 2004-ben itt a hupon a technikai részleteit. A sors iróniája, hogy azóta sincs ez rendesen felhasználva a Windowsnál, miközben akkor még azon ment az eszmecsere, hogy megvalósítható lenne ez Linux esetén is...

2. az MS uj hotpatch mechanizmusa eleg egyszeru asm szinten: minden fuggveny ele beszurnak 5 toltelek byte-ot (0xcc vagy 0x90 amit eddig lattam) ill. maga a fuggveny is egy toltelek 2 byte-os utasitassal kezdodik (mov edi,edi). ezek utan a hotpatch eloszor atirja az 5 byte-ot egy 'jmp uj_fuggveny'-re, ami ugye i386-on pont 5 byte, aztan pedig atirja a dummy 2 byte-ot egy 'jmp short'-ra, ami raugrik az 5 byte-os hosszu jmp-ra. ez igy majdnem SMP-safe es linux ala is siman meg lehetne csinalni.

http://hup.hu/node/7605#comment-33308

( veresh | 2014. 11. 18., k – 21:55 )

Ha Samba3 a "tartományvezérlő", akkor nem kerberos-os hitelesítés történik, tehát nem használható ki a hiba?
Jól értelmezem?

( trey | 2014. 11. 19., sze – 07:49 )

További részleteket közölt az MSRC egyik tagja:

Additional information about CVE-2014-6324

A lényeg:

"CVE-2014-6324 allows remote elevation of privilege in domains running Windows domain controllers. An attacker with the credentials of any domain user can elevate their privileges to that of any other account on the domain (including domain administrator accounts).

The exploit found in-the-wild targeted a vulnerable code path in domain controllers running on Windows Server 2008R2 and below. Microsoft has determined that domain controllers running 2012 and above are vulnerable to a related attack, but it would be significantly more difficult to exploit. Non-domain controllers running all versions of Windows are receiving a “defense in depth” update but are not vulnerable to this issue."

[...]

"The only way a domain compromise can be remediated with a high level of certainty is a complete rebuild of the domain. An attacker with administrative privilege on a domain controller can make a nearly unbounded number of changes to the system that can allow the attacker to persist their access long after the update has been installed. Therefore it is critical to install the update immediately."

--
trey @ gépház

( trey | 2014. 11. 19., sze – 08:06 )

A Microsoft újra kiadta tegnap a kedden kiadott kritikus SChannel frissítést. Azt is újra fel kell telepíteni.

"

V2.0 (November 18, 2014): Bulletin revised to announce the reoffering of the 2992611 update to systems running Windows Server 2008 R2 and Windows Server 2012. The reoffering addresses known issues that a small number of customers experienced with the new TLS cipher suites that were included in the original release. Customers running Windows Server 2008 R2 or Windows Server 2012 who installed the 2992611 update prior to the November 18 reoffering should reapply the update. See Microsoft Knowledge Base Article 2992611 for more information.

"

További részletek itt.

--
trey @ gépház