A Microsoft nem fektet ugyanakkora energiát a Windows 7 és a Windows 8 biztonságába

Microsoft, Windows

Marion Marschalek és Moti Joseph fenti előadása a TROOPERS14 ITsec konferencián hangzott el. A két szakember több mint 900 Windows library átvizsgálása után arra jutott, hogy a Microsoft nem fektet ugyanakkora energiát a Windows 7 és a Windows 8 biztonságossá tételébe. A vizsgálat során arra jutottak, hogy a Microsoft bizonyos biztonsági függvényeket beletesz a Windows 8-ba, de ugyanakkor nem teszi bele a Windows 7-be. Hogy mi ennek az oka? Moti Joseph szerint a pénz. A szakember szerint a Microsoft nem akar fejlesztési időt áldozni egy régebbi rendszerre és inkább az újabb rendszer felé tereli a felhasználókat.

A két szakember kifejlesztett egy DiffRay nevű eszközt, amellyel könnyen elvégezhették az összehasonlító munkát.

További részletek itt.

( saxus | 2014. 06. 11., sze – 22:17 )

"Majdnem" meglepődtem.

Viszont, ha már itt tartunk, fektethetne egy kevéske energiát az MS abba, hogy Windows 8-on helyrepofozzák az OpenGL (és ahogy a netet olvasom, a régi DirectX) támogatást is.

A régi gépemre próbaképp feltúrtam egy W8.1-et, a alapvetően marhagyors (főleg a géphez képest), az új teljes képernyős start menü desktopon már picit furcsább (eddig WS2012r2 alatt használtam valamennyit), de hosszú távon akár még jó is lehetne. Viszont OpenGL az rajta valami gyötrelmesen lassú volt. (Így nem nehéz a Valve-nak gyorsabbnak lennie Linuxon). Két dolgot próbáltam ki, egyik a Super Hexagon (minimalista játék, kb. 15 FPS), másik a Half-Life 1, ami meg talán 1-2 FPS-sel ment. Igen, az a HL1, aminek a WON-os változata anno egy P200MMX-en 48Mb ram mellett egy Voodoo3 2000-rel kicsikart magából 20-35 FPS-t.

Szóval a rendes gépemen egyhamar nem fogok váltani így W8-ra, ha ennyire elkezdi leszarni a visszafelé kompatibilitást a Microsoft.

A gép egyébként egy kb. 7 éves Athlon X2 3800+ (2x2Ghz), 4G ram, HD4850/1G (az még szerintem a mai középkategória alját is lehagyja) meg valami kőkorszaki 40G-s IDE vinyó lett a rendszervinyó. (Szerintem van vagy 12 éves).

<irony>Fizetett Microsoftos bérkommentünket olvashatták</irony>

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"Mert az alap driverről kb az XP óta tudni lehet, hogy alkalmatlan szinte bármire."

W7-en anno felrakta a rendes ATI-t, igaz nem a legutolsót, hanem a legutolsó aláírtat. (Az akkor talán 2-3 hónappal volt lemaradva.)

Itt alapból valami MS Basic drivert rakott fel, viszont egy icipici noszogatásra talált rendes AMD drivert is. (Kb. update driver, keressen automatán, köszi.) Próbaképp kipróbáltam az AMD oldaláról letöltöttet is, azzal is ugyanez az eredmény. Plusz, más is panaszkodott interneten, hogy W8 alatt bajok vannak.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( mynheer_gabor | 2014. 06. 11., sze – 22:28 )

>>A két szakember több mint 900 Windows library átvizsgálása után arra jutott

Kamu. Hogy vizsgálták volna át, amikor nem is openszósz. Oh wait.
_____________________________
Powered by 1,3,7-trimetilxantin

( artifex | 2014. 06. 11., sze – 22:46 )

Mennyire használható (legális?) eredményt ad IDA Pro listák alapján összehasonlítani ezt? Csak a DiffRay leírása alapján gondolom, hogy ez a menet.

MS érthető, át akarja terelni az embereket a W8 irányába, ha már nem igazán megy máshogy.

"Belépés díjtalan, kilépés bizonytalan."
"Vajon mit várok a sorstól, ha hányok az édestől, és izzadok a sóstól."

( KisTasi | 2014. 06. 12., cs – 00:58 )

Most komolyan, volt olyan ember, akinek ez nem volt teljesen nyilvánvaló?

--
Lenovo ThinkPad T410

Az biztos, hogy egy hibát sok helyen reprodukálni, kijavítani, a javítást tesztelni és kiadni borzasztóan nagy költség. Na de ezt fizetik ám nekik! Rengeteg cég tejel folyamatosan a supportért, az OEM/dobozos vevők is egyszer kifizették előre a több évnyi javítást.

Éppen ezért, hogy ilyen gond ne legyen, a Win9 valószínűleg rolling release lesz Manjaro alapokon. :)

( freeoli v | 2014. 06. 12., cs – 07:44 )

Tereljenek testrészeket a testnyílásaik felé. Fizetek és letojnak? Köteleznek, hogy váltsak az újjabbra pénzért? Elvárják, hogy mindenkit oktassak ki erre a csempés parasztvakító guira? Bőr az van vastagon.

Már megint ezek a csempék. Miről beszélsz? Én nem is látom a csempéket, mivel semmihez nincs rá szükség. 2 kattintás, hogy a desktopra bootoljon (sőt a 8.1 update 1 magától is úgy indul) és onnantól nem látod a csempéket, csak ha látni akarod és előhozod. Se leállitáshoz se semmi máshoz nem kell a mindennapi használat alatt.

Azok mantrázzák ezt a hülyeséget akik még életükben nem láttak 8.1-et.

A másik "kérdés" eleve hülyeség. Javitja a bugokat w7-ben, de nyilván fejlettebb a biztonsági rendszere a w8-nak, mivel egy újabb termék és nyilván ezeket a fejlesztéseket nem implementálja a w7-ben, ahogy régebbi linux kernelek sem kapnak meg új biztonsági feature-öket, hanem csak a hibákat javitják. Nem tudom mi ezen a meglepő.

Egy hiba javítása egy fejlettebb eljárással fejlesztés vagy hibajavítás? Az eredeti tervtől biztonsági okból eltérni és újratervezni, mert hibás volt, fejlesztés vagy hibajavítás? Ha már nagyon beharangozva annyira közös a kódbázisuk része* tényleg csak a pénz az oka, hogy nem helyezik át?

" mert hibás volt"

Mutasd már meg ezt a kijelentést a prezentációban vagy bárhol. Simán lehet, hogy ezen fgv hivása előtt már ellenőrizve volt az a bizonyos érték amit az új fgv. szintén ellenőriz, igy NEM volt biztonsági hiba eredetileg sem, viszont jövőbeli (másik hivás ami viszont elfelejti majd ellenőrizni) hibát elkerülhet. Vagy egyszerűen át van irva az egész (már a korábbi hivások is) a w8-ban, ezért MUSZÁJ volt az ellernőzést itt megtenni. Nem olyan egyszerű ez, mint gondolod, hogy látsz két fgv hivást, az egyik többet ellenőriz, akkor ami nem ezt a fgv. hivást használja az a rendszer lyukas. Sokkal bonyolultabb ez.

"Ha már nagyon beharangozva annyira közös a kódbázisuk része*"

Nem látom a csillag magyarázatát. Ki harangozott be ilyet, főleg biztonsági szempontból? Szerintem senki. Egyetlen dolgot állitott a ms, hogy a win8-ban növelték a biztonságot, átirtak sokmindent biztonságosabbra. Pont ezt bizonyitotta be az elemzés is.

Igaz, a 8.1-ben már vissza lehet állni egy nem csempe indítóra. Taps. Ez már alapot ad arra, hogy ne 7-et vegyek.

Nem akarok egy új rendszer venni azért mert el akarják nekem adni.

Nem akarok egy új rendszerre sok embert átoktatni mert valaki úgy döntöttöt, hogy az jó lesz nekik.

Viszont akarom az összes frissítést mert kifizettem a termék árát. Ne a hibákkal akarjanak terelni, hanem az új és fontos, jó funkciókkal.

"Nem akarok egy új rendszer venni azért mert el akarják nekem adni."

Javaslok neked egy őrült meglepőt: ne vegyél!

"Nem akarok egy új rendszerre sok embert átoktatni mert valaki úgy döntöttöt, hogy az jó lesz nekik."

Én már átállitottam sokszáz gépet w8.1-re, az oktatás annyiból állt, hogy elmondtam a leggyorsabb kikapcsolás a jobbklatty a start gombnál van. Te mit szeretnél oktatni egy 8.1-en amin a csempét nem is látja a user?

"Viszont akarom az összes frissítést mert kifizettem a termék árát."

Meg is kapod az összes frissitést. Melyik frissitést nem kaptad meg?

"Ne a hibákkal akarjanak terelni, hanem az új és fontos, jó funkciókkal."

Nem a hibákkal terelnek, de kereshetnél egy statisztikát a különböző windows verziók hibáinak számáról és meg fogsz lepődni, de egyre kevesebb van bennük ahogy jönnek az újabb verziók, igy aki a legbiztonságosabb rendszert akarja használni, annak a legfrissebbet kell használja.

Nem az XP-ről van szó (az lenne a 2.4). Viszont guess what: a 2006-os 2.6.18-hoz még mindig van provider, aki biztonsági javításokat backportol (gyk.: RHEL5) - ez nagyjából egy Vista. A 2009-es 2.6.32-höz szintén (gyk.: RHEL6) - ez nagyjából egy Windows 7.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Oke, hogy autista vagy, es nem tudod ertelmezni a hasonlatot, csak szo szerint (2.4 vs XP, mintha szamitana barmit is, akkor 2.6, tokmindegy), de most nem security patch-ek backportolasarol van szo (=Windows Update) hanem UJ ficsorokrol.

Aki szerint az a realis, sot, elvarhato, hogy az osszes uj ficsort bele kell pakolni az aktualis, de ezen kivul az elozo n release-be is, annak fingja sincs arrol, hogy a szoftverfejlesztes hogyan (nem) mukodik. Ez nem penzrol szol, hanem jozan eszrol - ha belepakolnak az uj ficsoroket a regi release-be is, akkor egyaltalan mi ertelme lenne az uj release-nek? Az egesz egy logikai bukfenc.

De egyebkent breaking news: a Vista meg kevesbe biztonsagos. Sot, az XP meg kevesbe. De a 98 meg annal is kevesbe. Szenzacio.

HA, kapcsolódik hozzá biztonsági hiba. És AKKOR javitaniuk is kell w7-ben is. De nem erről van szó. Arról van szó, hogy auditálták a w8-ban ezeket a fgv-eket és javitottak rajtuk, új feature-öket vezettek be stb-stb, amiket nyilván nem implementálnak a régebbi rendszerekben. Ha biztonsági hibát találnak, azt javitják a régi rendszereken is, lásd patch keddek több windows verziót érintő, ugyanazon hibák javitását.

Azért ez a "nem kényszerít" hatalmas csúsztatás ám tekintve hogy a világ vezető kereskedelmi oprendszeréről beszélünk! Nem kényszerítenek, csak próbálják folyamatosan formálni a piacot, amely meg már direkt kényszerítő erő.

Lásd pl. az UEFI-s digitálisan aláírt secure boot-ot (ugye Win8 only). Meg hogy nagyon sok gyártóval úgy lepaktálnak, hogy újonan megjelenő vasra direkt nem adnak ki pl. Win 7 drivert. Most futottam bele egy notebookkal, nem akartam hinni a szememnek. Egyszerűen direkt gáncsolja a gyártó a Win7 felhasználásának lehetőségét, és rajtuk keresztül az MS.

Ja persze. 2.4 azt szeretem a legjobban b ni.

Már regés régen nem fejlesztett* és nem támogatott* rendszerről beszélsz. A 7-est árulják? Igen. Pénzért? Igen. Csempe van rajta? Nem. Sokaknak ez kell? Igen.

A felhasználók nagy része a munkahelyén találkozik elsősorban a rendszerrel akik 20 év alatt megtanulták és elsajátították az akkor kitalált fő felületi elemekre épülő ui-t. Csak azért elvárni az egész világtól, hogy 5-100 éves korig tanuljon meg kezelni egy új ui-t csak azért mert az üzleti stratégia az értőkijelzők irányába és a mindenre egy felületet irányba mozdult el a pici-puha cégnél, az bunkóság. Vagyis a megb*ás.

Most miert faj ennyire a hasad? Nagyjabol a 8 consumer preview ota vannak ra segedprogramok, hogy a sokat emlegetett csempeid eltuntesd. Egyebkent mar csak az a kerdes, hogy mi koze a csempeknek a security-related API-k backportolasahoz?

De meg egyszer, a fent irtak univerzalisan ervenyesek, akar fizetsz erte, akar nem. Nem mintha barki pisztolyt tartana a fejedhoz, hogy neked Windows-t KELL venned (ahogy elnezlek, a "vasarlas" eddig is a Windows 7 Loader telepitesebol allt), szoval nagyjabol semmi ertelme annak, hogy itt frocskolod magadbol a hulyeseget.

Ha te ugyanazt a szart akarod hasznalni 200 evig, akkor hasznald ugyanazt a szart 200 evig, ne az ujat pocskondiazd, meg ne cirkuszolj, hogy ugyanaz a szar meg mindig ugyanaz a szar, es nem jon mar hozza fejlesztes. Ha neked a regi szar kell, akkor orulj a regi szarnak, ne az uj massagan puffogj, mint a sertett ovodas. Senkinek nem lesznek almatlan ejszakai, ha te 7-esen maradsz.

A harmadik féltől származó alkalmazások telepítésére nyomósabb indok kell.

A csempe dolog igenis nem tetszik, lefordítom.

Veszel egy autót, de a gyártó úgy dönt, hogy nem bal hanem jobb kormányos autót gyárt mert szerinte az jobban illik az értékesítési stratégiájába, függetlenül attól hogy te bal kormányosat vezettél húsz évig. Igaz, hogy van négy kereke, kormánya, lehet vele közlekedni, de minden máshol van és valahogy ettől az egész egy szar lesz és már nem is érdekel, hogy mi van a motorháztető alatt.

Hiába te fizetsz, azt kell tenned amit ő mond, na ez a bajom.

( siposa v | 2014. 06. 12., cs – 10:51 )

Ha jól értem, itt nem azt a problémát fedezték fel, hogy a Microsoft nem portolja vissza Win7-re a Win8-ban kifejlesztett biztonsági technológiákat (ez nem is volna általánosan elvárható), hanem hogy a felfedezett potenciális biztonsági hibákat több esetben csak a 8-asban javították akkor is, ha az javítható lett volna a 7-esben, mivel már ott is létezett a megfelelő API.

Például: az előadás slide-járól a 44 és 45-ös oldalakon látható, hogy az SspiCopyAuthIdentity függvényen belül a 8-asnál többször is használják az RtlULongAdd függvényt (overflow mentes összeadás), míg a 7-esben csak a sima "add" parancsok szerepelnek.

Ha ez igaz, ezzel az összehasonlító módszerrel kiválóan lehet lehetséges támadási pontokat keresni a két rendszer összehasonlításával.

(Ha benéztem valamit, elnézést kérek, kérem, korrigáljatok)

"az SspiCopyAuthIdentity függvényen belül a 8-asnál többször is használják az RtlULongAdd függvényt (overflow mentes összeadás), míg a 7-esben csak a sima "add" parancsok szerepelnek."

Igen, ilyentől lehet biztonságosabb a w8. De ki állitja, hogy ez egy létező bizonsági hiba javitása ami mindkét rendszert érintette, de csak a 8-asban javitották? Lehet, hogy ez egy fejlesztés volt a w8-ban, amivel lezártak egy potenciális(!) gyengeséget.

Valószinűleg nem arról van szó, hogy csak kicseréled a két fgv. hivást és máris ki van javitva a - feltételezett - hiba, hanem inkább arról, hogy ezt a részt alaposan auditáliták a w8-ban és fejlesztettek rajta.

"Ha ez igaz, ezzel az összehasonlító módszerrel kiválóan lehet lehetséges támadási pontokat keresni a két rendszer összehasonlításával."

Ez szerintem igy van. És, ha sikerül a w7-ben ez alapján hibát találni és azt nem javitják, akkor jogos a hőbörgés. De erről egyelőre szó sincs, ez az előadás egyetlen dolgot igazolt, mégpedig, hogy a w8 valóban biztonságosabb mint a w7.

A prezentáció nem beszél "létező bizonsági hibákról" ("If we get one zero-day from this project, it's worth it"), de a lehetőség igenis benne van, erről szól az egész. Ha egy rutinban kicserélgetik a "művelet" utasításokat "biztonságosMűvelet" hívásra, akkor arra valószínűleg jó okuk van a fejlesztőknek, főleg, hogy egy authentikációval kapcsolatos dll-ről beszélünk.

Ha ezzel "lezártak egy potenciális(!) gyengeséget", akkor az én Win7-emben benne maradt ez a potenciális hiba, sok másikkal egyetemben, és csak idő kérdése, hogy valaki kihasználja őket. Sőt, mivel a különbség keresése automatizálható (amúgy valszeg régen az), gyakorlatilag célpontot csinálnak a Win7-ekből a saját fejlesztőik. Lehet, hogy nem szándékosan, de az eredmény szempontjából mindegy.

A "hőbörgés" szerintem így teljesen jogos, pontosan arról van szó, mint a mit jelen cikk címe állít.

Örülök neki, hogy a Win8 biztonságosabb mint a 7-es, de pl. országos méretű cégeknél rengeteg Win7-van, sokan nem olyan régen álltak át XP-ről, biztos őket is megnyugtatja, hogy a 8-as mennyivel jobb, főleg ha összeszámolják, mi pénzt költenek évente licencekre.

"Ha egy rutinban kicserélgetik a "művelet" utasításokat "biztonságosMűvelet" hívásra, akkor arra valószínűleg jó okuk van a fejlesztőknek, főleg, hogy egy authentikációval kapcsolatos dll-ről beszélünk."

Nem biztos, hogy az az okuk amire te gondolsz

"Ha ezzel "lezártak egy potenciális(!) gyengeséget", akkor az én Win7-emben benne maradt ez a potenciális hiba"

Lásd link, irtam példát, hogy ez mennyire nincs igy. Potenciális gyengeség pl. az, hogy nem ellenőriz a fgv egy változót, mert úgy állapodtak meg, hogy az azt hivó kódok már ellenörzik. Ha ellenörzik w7 alatt, akkor semmivel nem biztonságosabb lecserélni a fgv-t arra amelyik már ellenőrzi, egyetlen hatása, hogy lassul a kód, mert 2x ellenörzi ugyanazt. Lehet, hogy w8-ban megváltoztatták ezt a megállapodást és kiszedték a hivó fgv-ekből az ellenörzést és mindent a hivott fgv. ellenőriz. Ettől a te w7-ed semmilyen "potenciális" hibát nem tartalmaz, amit majd később fognak kihasználni. Egyszerűen áttervezték a működést a w8-ban. És, ha igy van - hiszen ez csak feltételezés - akkor azért tették, mert igy egy későbbi hiváskor nem kell figyelni rá, hogy a hivó ellenörizzen, tehát egy potenciális, később belerakható hibát előz meg. De a w7 ettől továbbra sem lesz sebezhetőbb.

" gyakorlatilag célpontot csinálnak a Win7-ekből a saját fejlesztőik."

Annyira mint akármelyik linuxos kernel szintű biztonsági fejlesztés, amit szintén nem portolnak régi kernelekbe. Csak ott még egyszerűbb észrevenni-kihasználni, mivel forrás szinten megvan mi történik.

" biztos őket is megnyugtatja, hogy a 8-as mennyivel jobb"

Biztonságtechnikában kompetens embereknek semmilyen meglepetést nem nyújthatott ez a nagy "felfedezés", mivel nyilvánvaló. (és mint már többször rámutattam, a linux is igy működik: biztonsági hibákat javitanak minden támogatott verzióban, biztonságnövelési fejlesztést szinte soha nem raknak visszamenőleg a termékekbe)

"nem ellenőriz a fgv egy változót, mert úgy állapodtak meg, hogy az azt hivó kódok már ellenörzik. Ha ellenörzik w7 alatt, akkor semmivel nem biztonságosabb lecserélni a fgv-t arra amelyik már ellenőrzi, egyetlen hatása, hogy lassul a kód, mert 2x ellenörzi ugyanazt. Lehet, hogy w8-ban megváltoztatták ezt a megállapodást és kiszedték a hivó fgv-ekből az ellenörzést és mindent a hivott fgv. ellenőriz."

Ezt alá is tudod támasztani valamivel, vagy csak elmélkedés?

Mert ugye azt állítod, hogy a MS innen oda pakolgat bizonyos ellenőrzéséket. Mi oka lehet erre?
Az egyik lehetőség az, hogy felfedezték, hogy az adott fv-t nem csak olyan fv hívja (vagy hívhatja) meg, ami implementálja a szükséges ellenőrzéseket. Ez esetben ennek a lépésnek biztonsági oka van, vagyis egy potenciális rést foltoznak be, és ezt be kellene foltozniuk minden támogatott rendszerben.
A másik lehetőség pedig azt, hogy "for fun" összevissza pakolgatnak ellenőrzéseket innen-oda, pl. mert annyira unatkoznak. Ezt azért nem tartom túl valószínűnek...

Idézném lentebbről magamat: "De hát hajrá, ha neked van igazad, akkor nagyon hamar w8-at nem érintő, korábbi, támogatott windowsokat viszont erősen érintő hibajavitások, CVE-k (mert a gonosz ms úgysem javit semmit ugye) százai fognak megjelenni. Kiváncsian várom."

Egyébként bele is irtam, nyilván csak elmélkedés, egy lehetséges példa a helyzetre.

"Az egyik lehetőség az, hogy felfedezték, hogy az adott fv-t nem csak olyan fv hívja (vagy hívhatja) meg, ami implementálja a szükséges ellenőrzéseket. Ez esetben ennek a lépésnek biztonsági oka van, vagyis egy potenciális rést foltoznak be, és ezt be kellene foltozniuk minden támogatott rendszerben."

Ezt meg pont a fenti példában bizonyitottam, hogy nem igy van. Attól még, hogy ezt a fgv-t a fenti konvenciót nem betartó kód is meghivhatja elméletben (de ellenőrizték, hogy nem hivja és ez nem publikus api, hogy tudtukon kivül hivja) attól még ezt nem kell abban a windows-ban befoltozni, ahol biztosan nem hivja hibásan egyetlen hivó sem, hiszen nem okoz rést, az ellenörzés máshol, de el van végezve.

"Idézném lentebbről magamat: "De hát hajrá, ha neked van igazad, akkor nagyon hamar w8-at nem érintő, korábbi, támogatott windowsokat viszont erősen érintő hibajavitások, CVE-k (mert a gonosz ms úgysem javit semmit ugye) százai fognak megjelenni. Kiváncsian várom."

Egyébként bele is irtam, nyilván csak elmélkedés, egy lehetséges példa a helyzetre."

OK, csak egy dolog egy _potenciális_ biztonsági rés, egy másik pedig egy létező és kihasználható. És ha ez utóbbi ki is bukik, akkor a MS felteszi a kezét és azt mondja: látod mennyivel biztonságosabb az új rendszerünk? És itt nem olyasmiről van szó, hogy X sw-be betesszünk még új funkcionalitást, hanem a már létező komponenseket tákolgatják, pl. az add helyett RtlULongAdd függvényt használnak, ami overflow mentes.

És mivel a win7 még mainstream support fázisban, van, ezért az új, biztonságosabb lib-eket illendő lenne oda is beépíteni. Az extended support már más kérdés, ott mondhatná a MS hogy csak ismert biztonsági réseket frissítünk, de a win7 _még_ nem az. És még egyszer: ugyanazon a DLL ugyanazon függvényéről van szó.

"Attól még, hogy ezt a fgv-t a fenti konvenciót nem betartó kód is meghivhatja elméletben (de ellenőrizték, hogy nem hivja és ez nem publikus api, hogy tudtukon kivül hivja) attól még ezt nem kell abban a windows-ban befoltozni, ahol biztosan nem hivja hibásan egyetlen hivó sem, hiszen nem okoz rést, az ellenörzés máshol, de el van végezve."

Tehát akkor az a válaszod, hogy unatkoznak és nem tudnak mit kezdeni a munkaidejükkel, ezért "for fun" pakolgatják innen oda az ellenőrzéseket?

"Tehát akkor az a válaszod, hogy unatkoznak és nem tudnak mit kezdeni a munkaidejükkel, ezért "for fun" pakolgatják innen oda az ellenőrzéseket?"

Nem, továbbra is azt mondom, hogy ez lehet bármi, akár refactoring is. Semmit nem változtat a biztonságon, de könnyebben karbantartható lesz tőle a kód, vagy egyszerűbb vagy akármi.

Ha tévedek és neked van igazad, akkor majd látjuk az elképesztő mennyiségű, csak w7-et érintő hibát. Meglátjuk.

A példád teljesen jó, logikus feltételezés. A gond csak az, hogy bizonyíték nincs rá semmi, míg az "to-safe" híváscserékre van. Igazából nem tartom életszerűnek, hogy Win7-ben még körül volt programozva egy rutin, Win8-ban meg már belül kellett ugyanazt megoldani, de ez meg az én feltételezésem. Remélhetőleg majd jön valami értelmes reakció az illetékesektől, hol az igazság.

Örülök, hogy felhoztad a linuxot, mert pont azon gondolkoztam, hasonlóan zavarna, ha a még támogatott RHEL5/6-ba nem kerülnének bele a visszaportolható, biztonságot erősítő változások RHEL7-ből. Nagyon remélem, hogy erre nem lesz példa.

Ugyanakkor a régi kernelekre hivatkozásod sántít, mivel tudtommal csak a legfrissebb és a "longterm" verziókat tartják karban, nem az összes régit. Szóval ha egy longtermbe, pl. a 2.6.32-be nem kerül be egy olyan változás, ami a 3.x-ben bukott ki, de gond nélkül visszaportolható, akkor igazad van, az ugyanolyan gáz. De a 3.14.x-y közötti változatok között semmit sem kell visszaportolni (a kernelfejlesztőnek, egyes disztribúciók kernelei más téma).

Gőzöm sincs, mekkora meglepetést okozott a "biztonságtechnikában kompetens embereknek" ez a prezentáció, de érdekelne a véleményük, az egész témával kapcsolatban. Ha valamelyikük erre jár, leírhatná.

"A gond csak az, hogy bizonyíték nincs rá semmi, míg az "to-safe" híváscserékre van."

Amely "bizonyiték" a megtörténésen kivül semmi mást nem bizonyit. De hát hajrá, ha neked van igazad, akkor nagyon hamar w8-at nem érintő, korábbi, támogatott windowsokat viszont erősen érintő hibajavitások, CVE-k (mert a gonosz ms úgysem javit semmit ugye) százai fognak megjelenni. Kiváncsian várom.

"Örülök, hogy felhoztad a linuxot, mert pont azon gondolkoztam, hasonlóan zavarna, ha a még támogatott RHEL5/6-ba nem kerülnének bele a visszaportolható, biztonságot erősítő változások RHEL7-ből."

RHEL-t nem követem, de még debian-ba se kerül bele szinte semmi ami nem konkrét hibajavitás. De biztos vagyok benne, hogy RHEL-be se kerül semmi ilyen, csak te mást értesz bug-on, és bug-ot nem okozó, de elméletben bug-ot okozható eljárás vagy éppen egy teljesen új védelmi technika között, mint én. De én konkrét példát is hoztam, hogy mikor nem okoz semmilyen biztonsági kockázatot, ha akár egy rossz gyakorlat áttervezését nem portolják vissza, csak a legújabb termékükben módositják.

Szó sincs konkrét bug-okról, végig csak azok potenciális lehetőségéről beszéltünk ebben a szálban is, és a prezentáció is erről szól.

Azon az állásponton vagyok (és ha jól látom, a modern IT security is erről akar szólni), hogy a hibák puszta lehetőségét is minimalizálni kell, védelmeket kell beépíteni a szoftver megfelelő pontjaira. A prezentáció arra hívta fel a figyelmet, hogy Win7 esetén könnyen lehet, ez nem történik meg minden esetben. Ha valóban így van, akkor ez probléma.

Mint programozó azzal is tisztában vagyok, hogy erről könnyű beszélni, sokkal nehezebb viszont folyamatosan tartani ezt a fajta, felhasználónak elsőre "láthatatlan" minőséget, mikor egymás után jönnek a határidők.

Erre is csak azt tudom mondani, hogy én bizok benne, hogy a w7 esetén is elvégezték a szükséges ellenörzést amikor a w8-ban valamit átirtak vagy találtak valamit. Amit pedig nem vezettek oda vissza, azt nem lustaságból tették, hanem mert nem okoz kihasználható hibát. Ha neked van igazad, akkor a topic-ban szereplő elemzés után százával fognak megjelenni w7-re a felfedezett hibák száma, amik a w8-at nem érintik. Szerintem nem fognak. Meglátjuk.

Nem ellenőrzésekről van szó, hanem pl. egy túlcsordulás lehetőségét tartalmazó add utasítást kicseréltek egy olyan függvényre, ami biztosan nem teszi lehetővé a túlcsordulást. És ez attól függetlenül teszi biztonságosabbá az adott fv-t (valamit a dll-t és az OS-t), hogy találnak-e benne valaha olyan kihasználható hibát, amit ezen túlcsordulásos összeadással tudnak kihasználni.

Szóval itt 3 lehetőség van:
1. unatkoznak, ezért "for fun" kendácsolnak
2. tetszőleges (nem 1 vagy 3) okból ugyanazon dll ugyanazon függvényéből két élő ágat akarnak karban tartani a következő 6 évben
3. a win8-at igyekeznek biztonságosabbá tenni, mint a win7-et.

Szerinted a fenti 3 lehetőségből itt miről lehet szó?
De ha van alternatív magyarázatod erre, akkor kérlek azt oszd meg velünk.

4. Win8 -at igyekeznek biztonságosabbá tenni, mint a win8 volt 1-2 hónappal korábban. Az, hogy még ezt backportolják is win7 -re, az olyan extra effort lenne, ami nem látom miért volna elvárható. Ahogy te is írtad, nem konkrétan kihasználható sebezhetőségről van szó, hanem az architektúra javításáról.

más szavakkal: az egyik támogatott rendszerüket kevésbé sebezhetővé tenni, a másik támogatott rendszerüket pedig nem.

Mert ha csak latest shiny windows 8.x.y verzióba (ha jól tudom 8.1 update 1) kerül bele még a kiadás előtt, akkor még lehet azt mondani, hogy folyamatosan fejlesztenek és ebből jönnek ki a következő verziók.
De ha windows 8.0.0-tól 8.x.y verzóig minden win8-ba bekerül, akkor jogosan merül fel a kérdés, hogy a win7 vajon miért kevésbé támogatott rendszer, mint a hasonló támogatási fázisban levő win 8.0.0...

( uid_16313 | 2014. 06. 12., cs – 21:44 )

A felfedezés nem meglepő. Tervezett elévülés?
Persze, hogy a pénz az oka. Mi más lenne?
Az összes Windows-nak a pénz az oka, és azon felül is mindennek. A világot a pénz mozgatja. Hatalmas felfedezés...

--
robyboy

"Gondolkozni nehéz, ezért legtöbben ítélnek." - Márai Sándor

( naszta v | 2014. 06. 12., cs – 22:02 )

Közben lassan a CRT-t is újraírják csendben C++-ban.

So, as part of this great refactoring of the CRT, we have done an enormous amount of work to simplify and improve the quality of the code, so that it is easier to add features and fix bugs in the future. We have converted most of the CRT sources to compile as C++, enabling us to replace many ugly C idioms with simpler and more advanced C++ constructs. The publicly callable functions are still declared as C functions, of course (extern "C" in C++), so they can still be called from C. But internally we now take full advantage of the C++ language and its many useful features.

--
http://naszta.hu

( lajos22 | 2014. 06. 12., cs – 22:49 )

Windows és a biztonság egy mondaton belül? Na ne röhögtessetek már...

--
Fontos! Ha berágok, nem feltétlen személyed ellen szól...
openSUSE 13.1 x86_64

( GerzSonka | 2014. 06. 13., p – 07:49 )

Engem igazából az érdekelne, hogy az Intelnek sikerült-e már olyan drivert összeraknia, amivel a notebook-os váltható grafikus rendszer nem szarja össze magát telepítés után... Akkor esetleg megyek Windows 8.1-re. Esetleg.
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods 

Get dropbox account now!

( handler | 2014. 06. 14., szo – 12:02 )

Pedig a secure boot & trusted computing (2.0) sokkal megbizhatobba teszi a felhasznalot. Ezutan csak az futhat rajta, amit megengednek (de ez is csak atmeneti "engedely", mert visszavonhato marad), es a felhasznalo azt lathatja belole, amit megengednek.
Nem lesz tobbe ilyen kodvisszafejtes es osszehasonlitas sem, mert nem lesz megengedve a futtatasa. Kerem tavozzanak, nincs itt semmi latnivalo.

A korlatlan hatalommal persze nem fognak visszaelni. Soha ilyenre nem volt meg pelda a tortenelemben.

https://www.bsi.bund.de/DE/Presse/Pressemitteilungen/Presse2013/Windows…
http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html

A fogalmatlanság netovábbja. Azt engedélyezel a trusted boot-ban amit csak akarsz. (vagy kikapcsolod az egészet, ha nem tetszik)
Gyk: csinálsz egy saját certificate-et, azt felrakod a bios-ba és onnantól a saját magad által aláirt kódok is futhatnak, vagy akár csak azok és kiveheted mondjuk a microsoft certificate-jét is.

A tpm-es FUD-ot tipikusan azok a nagyon tájékozott géniuszok nyomják akik a chemtrail-t és többi agymenést.

Kikapcsolni sajnos nem tudod az uj firmware-t, ha nem tetszik:
The Compatibility Support Module (CSM) is a component of the UEFI firmware that provides legacy BIOS compatibility byemulating a BIOS environment, allowing legacy operating systems and some option ROMs that do not support UEFI to still be used.[43]

http://www.intel.com/content/dam/doc/reference-guide/efi-compatibility-…

x86 platformon a kovetelmeny ennyi a secure boot kikapcsolasara, vagyis a custom mode opciora:

a) It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK.
b) If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system will be operating in Setup Mode with Secure Boot turned off.
b) The firmware setup shall indicate if Secure Boot is turned on, and if it is operated in Standard or Custom Mode. The firmware setup must provide an option to return from Custom to Standard Mode which restores the factory defaults.

Azt, hogy ezeket hogy kell es lehet elerni, az viszont nincs specifikalva. Lehet akar egyedi billentyuzetkombinacio kizarolag megfeleloen idozitve.

ARM rendszereken nem lehet kikapcsolni a secure boot-ot (w8 ready kovetelmeny):

"MANDATORY: Enable/Disable Secure Boot. On non-ARM systems, it is required to implement the ability to disable Secure Boot via firmware setup. A physically present user must be allowed to disable Secure Boot via firmware setup without possession of PKpriv.

Disabling Secure MUST NOT be possible on ARM systems."

Forras:
http://download.microsoft.com/download/A/D/F/ADF5BEDE-C0FB-4CC0-A3E1-B3…

"As you can see from the above, the holder of the platform key is essentially the owner of the platform. However, simply knowing the platform key (the private part) isn’t enough because in order to change the platform you have to be able to execute binaries and the platform will only execute binaries signed by a key either in KEK or db. If you take control of your platform by installing a platform key, you need to ensure that this key (or another you control) is also added to either KEK or db so you can sign binaries with it and have them execute."

http://blog.hansenpartnership.com/the-meaning-of-all-the-uefi-keys/

Ha valamire lehetoseget teremtenek, ott maga a lehetoseg a terv (ide jon a szokasos mantra: nem kell felni, csak kulonleges esetekben hasznaljuk majd). Es ha lehetoseg van visszaelesre, azzal kovetkezetesen, mindig vissza is fognak elni.

Milyen kovetkezmenyekkel is jar, ha visszavonjak a kulcsot? Egy joghatassal jaro ugymenetben ez miert is lenne elfogadhato?

Errol beszelek, es arrol, hogy ezen elvek lepesenkenti feladasava es / vagy megfosztasava (egeszen mas erdekervenyesitesi lehetosegei vannak egy felhasznalonak, mint mas szereploknek), vezet majd az elso hozzaszolashoz. Elvegre az, hogy mikor, mit, milyen inputtal es outputtal futtatsz az csak metaadat, nem lehet kifogasod ellene, ha osszegyujtik. Gondolj arra, mennyi esetleges torvenysertest lehet igy megelozni, vagy kesobb elemezni!

http://www.bmi.bund.de/SharedDocs/Downloads/DE/Themen/OED_Verwaltung/In…

Nem mindegy, hogy te dontod el, hogy miben / kiben bizol, vagy masok dontik el helyetted, ide ertve azt is, hogy benned megbiznak-e (nem).

A tcg measured boot otletes, ahogyan az intel txt es sgx, arm trustzone, talan meg a te erdekeidben isfelhasznalhato. Az uefi nem igazan erre celoz.

Mondjuk arra kivancsi lennek, mennyire hatekony az alabbi vagy ehhez hasonlo "featurek" kivedesere: Julian Bangert, Sergey Bratus, Rebecca Shapiro, and Sean W. Smith: The Page-Fault Weird Machine: Lessons in Instruction-less Computation
https://github.com/jbangert/trapcc

Ha mar a biztonsag lenne a cel, es nem a (veg)felhasznalo leigazasa, egy tiszta laprol inditott megoldas talan hatekonyabb lenne, pl.: Clean-slate design of Resilient, Adaptive, Secure Hosts kereteben a CHERI & Capsicum.

ARM-ot nem tudom, de az device kategória, eddig is csak hack-el lehetett más rendszereket rárakni mint amit a gyártó rárakott.

x86-on pedig kikapcsolható, te is azt idézed, meg látom is a saját rendszereimen, nem kötelező használni.

"Ha valamire lehetoseget teremtenek, ott maga a lehetoseg a terv"

Igen, lehetőséget teremtettek rá, hogy csak aláirt alkalmazás futhasson, olyan kulccsal amit te határozhatsz meg és még ki is kapcsolható a rendszer. Ez tényleg szörnyű. TPM csippek mikor is jöttek be? Talán 3 éve? Akkor is nyomtátok a FUD-ot ezerrel, meg se értve a működését, persze nem lett igazatok. Most a secure boot lett fekete bárány, amit szintén nem értetek, pár év múlva majd kerestek mást amit lehet FUD-olni.

A "device" kategoria miert kivetel? Ennyi erovel az x86 is hack, ha a gyarton kivul mas fejlesztett drivert valamelyik hw komponenshez. Ma mar az arm is standardizalt sbsa neven. Miert pont az x86 lesz a jovo es nem az arm vagy valami mas?

Epp ezaz, hogy kotelezo hasznalni az uj rendszert, a CSM csak emulacioval letezik mar, ha mar minden a helyen van, a secure boot kikapcsolas is visszavonhato (mi a garancia ra, hogy nincs eleve benne a kesleltetett kikapcsolas?), aztan lesz csodalkozas, hogy a sajat penzbol vasarolt es fenntartott gepen az fut, amit a magassagos cegek / hatosagok telepitenek vagy megengednek.

ARM-on (win8ready) kotelezo a secure boot, es nem kapsz hozza kulcsot, hogy azt futtass rajta, amit te szeretnel. Ne legyen mar termeszetes, hogy egy "altalanos celu" eszkoz specialis eszkozre lesz butitva, mert csak mas altal engedelyezett (=alairt) alkalmazas futhat rajta. Nem termeszetes, akkor sem ha fud-nak szamit.

Elmeletben es talan a gyakorlatban is meglenne a helye a tpm es hasonlo technologiak hasznalatanak, de egyben tul nagy kockazatot is jelent ha visszaelnek vele, es az erdekervenyesitesben jeleskedo szereploknek tul nagy lesz mindig a kisertes. Addig orulj, mig nincs igazam, es nem valosul meg, akkor mar valoszinuleg keso lesz puffogni, vagy barmit lepni.

+1

Arról meg nem beszélve, hogy a szoftverek biztonsági szempontból úgy szarok ahogy vannak. Mindegy mekkora cégről beszélünk, durva, kódfuttatást lehetővé tevő hibákat találnak nap mint nap. Piacvezető termékekben. És így akarnak kizárólagos jogot a termék felett?

Arpó lépésenként veszik el a jogainkat. Engem az is zavar hogy nem kikapcsolhatók funkciók, pl. az android-os tablet szaromon miért nem tudom letiltani a facebook meg hasonló szarokat? Miért más mondja meg hogy hogyan használhatom? Meg milyen infókat küldhet rólam? Hol van itt a szabadság ami megillet? Miért nem lehet ezt beszabályozni állami szinten? Beugathatnának a gyártóknak, hogy vagy a személyiségi jogok figyelembe vételével csinálják, vagy nem forgalmazhatnak, azt kész.

Az nem jó kifogás hogy ha nem akarjuk ne használjuk. Az ipar erre megy, aki nem él a technológiákkal lemarad jobb esetben, rosszabb esetben a megélhetése lesz veszélyben.

Mi az hogy nincs kontrollom a termék felett, csak durva hack árán? Amit ugye nem tud megtenni a nagy átlag. Meg akkor nincs garancia stb stb. Minden apró kiskaput bezárunk, az ultimate rabszolgaságba hajtás a cél, semmi kompromisszum.

Nézzük meg már a cégek ajánlatait! Eleve olyan reklámok vannak, melyek nulla erkölcsi értéket hordoznak. A legújabb marketing eszközökkel való maximális lehúzás az egyetlen cél. Semmi érték, erkölcs, pozitív szemlélet. És a legrosszabb, hogy nagyon jól menő multiknál is. Azt gondolhatnánk naivan, ha már megvan a nagy zsé, akkor majd.. de nem, mert akkor meg a hatalom elvesztése miatti félelem miatt folytatódik tovább még jobban.

Elkurvulás van.

És akkor ezek fényében azt gondolnánk majd, hogy olyan szoftvert csinálnak, ami jó is a nagy népnek.. de persze. Sok pénzért megvehetjük a windows-t is, aztán mit kapsz a pénzedért?- Semmi hasznos utility, egy csupasz cucc az egész hangzatos feature-őkkel. A beágyazott eszközökön meg a gyártó diktál ostorral.

Én azt mondom, hogy ez a tendencia az évek alatt folyamatosan erősödött és erősödik sajnos. Az emberek soha nem látott módon elkényelmesedtek, ehhez az ipar szolgáltatja a drogot, ami a net. Facebook-on lóg mindenki, ettől elfárad, kiég, tenni akarás utána nulla. A csajok csak a like-okat gyűjtik, az a legfontosabb pont az életükben. A lényeg hogy minden nap valami nagyon szép fotót töltsenek fel. Ezzel megint nő az elkurvulás, mert sok kan like-ol sok csajt, közben egyetlen lány szempontjából az jön le, hogy ő szupersztár lett. De nem, csak mivel erre megy a trend, hogy a nőknek nem kellenek a kanok - éppen, mivel egyre nagyobb sztárokká emelik őket a like-ok, ezért nem kellenek a kan-ok, tehát sok csajt kell like-olniuk "hátha bejön" alapon, ez megint tovább gerjesztődik, és az elkurvulás tovább nő :)

Na ezek után hogy képzelnéd hogy normális munkát akarjanak csinálni. Sajnos ez van. Kényelem és elkurvulás.

"Ennyi erovel az x86 is hack, ha a gyarton kivul mas fejlesztett drivert valamelyik hw komponenshez."

Ez azért rohadt messzi van attól amiről te képzelegsz.

"Epp ezaz, hogy kotelezo hasznalni az uj rendszert, a CSM csak emulacioval letezik mar"

Ez továbbra sem igaz, bármikor kikapcsolható a secure boot és bármilyen nem aláirt szoftver futtatható rajta. Pont. A többi a te agymenésed, hogy majd egyszer, meg visszavonják, meg ki tudja mi. Ha majd nem kapcsolható ki (vagy nem lesz szabályozható a kulcs, mert ma szabályozható), akkor majd nem vesznek az emberek olyan alaplapot, gépet, ilyen egyszerű. De mondom a TPM miatt is hiába puffogtatok sokéve, ott sem lett igazatok. Secure boot-al se lesz.

"ARM-on (win8ready) kotelezo a secure boot, es nem kapsz hozza kulcsot, hogy azt futtass rajta, amit te szeretnel."

Ennek semmi köze a w8-hoz, sokéve symbianos telefonomra se tudtam feltenni semmilyen más rendszert, pedig hol volt akkor még secure boot. Egyszerűen ezek device-ok, nem általános célú számitógépek, ezért nem raksz rá másik rendszert. Ahogy az autód fedélzeti számitógépére, ECU-jára sem teszel másik rendszert. PC-re pedig bármikor teszel, mert az PC.

"Ne legyen mar termeszetes, hogy egy "altalanos celu" eszkoz specialis eszkozre lesz butitva, mert csak mas altal engedelyezett (=alairt) alkalmazas futhat rajta."

Nem természetes, mert ez maximum a lázálmod PC-n. Nincs ilyen, csak FUD-olsz.

" Addig orulj, mig nincs igazam, es nem valosul meg, akkor mar valoszinuleg keso lesz puffogni, vagy barmit lepni."

Rendben, te pörögj nyugodtan a témán tovább, gondolom sok éve ezt teszed, a TPM óta, én meg használom tovább boldogan. Nem akarlak én meggyőzni semmiről, csak ne terjessz valótlanságokat.

Az EU versenyszabalyaiban talan meg bizom, de a gyartokban es mas erdekeltekben nem. Valoszinu, hogy csak monopolhelyzet az oka, hogy ott szerepel a kovetelmenyekben (az ismeretlen uton torteno) kikapcsolasi lehetoseg x86 eseten. ARM-on a Microsoft nincs monopol helyzetben ott nem is lehet kikapcsolni. Micsoda veletlen.
http://www.europarl.europa.eu/sides/getAllAnswers.do?reference=E-2012-0…

Kerem rajzoljak meg a hatarvonalat az altalanos celu es az egy celu eszkoz kozott. Altalanos celu eszkoznek szamit-e (2014-ben):
Asztali pc
Notebook
Ultrabook
Tablet
Okostelefon
Okosora
Okosszemuveg
Auto fedelzeti szamitogep
Pacemaker

Az erdekek egyuttalasa (ertelemszeruen rajtad kivul) ebbe az iranyba mutat, igy nem az a kerdes, hogy lesz-e ilyen, hanem hogy mikor.

+1

Külön vicces, hogy amikor jöttek az első hírek a secure bootról, egyből beindult a hőzöngés, és a feature azonnali eltávolításának követelése. Az fel se merült a közösségben, hogy ez esetleg valami hasznos feature, ami nem csak a windowsos felhasználóknak jó. Azért szerencsére pár nagyobb disztró (a fedora biztosan) elkezdte keresni a megoldást, és bár szükség volt némi együttműködésre a gyártókkal, talán még a microsofttal is, de végül megoldották, hogy a linuxosok is használhassák a gépeiket bekapcsolt secure boottal.