Nem örül a Microsoft Tavis Ormandy 0day közlésének, SA-t adott ki a sebezhetőséggel kapcsolatban

 ( trey | 2010. június 11., péntek - 12:57 )

Tavis Ormandy, a Google biztonsági csoportjának tagja tegnap egy, a Microsoft Windows Help and Support Center szolgáltatását érintő sebezhetőségéről számolt be a full-disclosure levelezési listán. A Microsoft nem örül annak, hogy Ormandy ilyeténformán hozta nyilvánosságra a sebezhetőséget. A redmondi vállalat a "felelős közlés" fontosságára hívja fel a figyelmet.

Ormandy a Windows XP-t és Windows Server 2003-at érintő sebezhetőséget - amely a hcp:// URI-k elégtelen ellenőrzéséből fakadóan távoli kódfuttatást tehet lehetővé az áldozat rendszerén - június 5-én jelentette be a Microsoft-nak.

A Microsoft Security Response Center (MSRC) blogon, Mike Reavey, az MSRC igazgatója ír Ormandy közléséről. A sebezhetőség közben SA is született.

Reavey szerint azzal, hogy a sebezhetőség részleteit és a kihasználás lehetséges módjait közzétette a Google mérnöke anélkül, hogy elegendő időt hagyott volna nekik a megfelelő javítás kidolgozására, jelentősen megnövelte az esélyét a széleskörű támadás elindulásának és kockázatnak tette ki az ügyfeleket.

Reavey kiáll a "felelős közlés" mellett (és ezzel egyben a full disclosure ellen) és továbbra is arra kéri a biztonsági szakembereket, hogy velük együtt dolgozzanak a problémák felelős bejelentésén. Szerinte így lehet biztosítani, hogy a biztonság növekedjen, miközben az ügyfelekre irányuló kockázat a minimális szinten tartható.

A blogbejegyzés itt olvasható.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

A végén még kénytelenek lesznek fizetni 2000 dollárt a közvetlen riportolásért.

jah, mások fizetnek, ha valaki hibát talál, lsd. nemrégi cikk, amire célzol [ala' google], és van.. akik leanyázzák az embert, hogy mégis mi az, hogy talál egy hibát, és ad egy "rövid" határidőt annak javítására...

A legjobb az lenne ha nem lenne benne ennyi kapitális hiba, akkor nem lenne gond ha be kéne ezeket jelenteni.

részemről +1 Ormandy-nak

Nem hinném, hogy a hibák létezésével lenne gond, ilyen minden szoftverfejlesztés során megesik. Inkább az, hogy ha a srác nem közli nyílt listán, akkor valószínű még nagyon sokáig nem javítják, esetleg fél-egy év múlva titokban. Attól pedig hogy ő nem közli, de egy rosszindulatú hacker rátalál, akkor sokkal rosszabb a helyzet, mint így.
--
"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

mondjuk ha más hasonló esetekben nem ültek volna hónapokig/évekig egy-egy ilyenen, akkor még megérteném a nyafogást.


szerintem.

Jaja. Az utóbbi időszakban a gugliék kétszer is szippantottak amiatt, mert a ms a közvetlen bejelentésekre gyakorlatilag nem reagált, csak a későbbi publikációkra. Lehet h így most a gugli is szemléletet váltott, és úgy kezeli a "nyafogós gyereket", ahogy láthatóan működik.

házon belül biztosan szólt előbb Tavis, mert ott nemrég éppen lecserélték az OSt:)

Nem örül? IJB.
--
Fight / For The Freedom / Fighting With Steel

+1

-------------------------
Trust is a weakness...

Mi van félnek, hogy a végén majd nem tudják azt mondani:
"A Windows biztonságosabb, mert kevesebb hibát kellett javítani"

Tegnap nekem volt egy pár frissítés, ma akartam kipróbálbi az xp m alatt a dolgot, a system informationt mondjuk meg is jeleníti, de nekem nem fut le az utánna lévő java script, lehet tegnap ki is javították? A Tavis általi "megoldást" copy paste eltem commandline alá de nem fut le.. :( Az ember egy évbe egyszer átbootol Linux alól XP-re hogy szórakozzon egy kicsit és akkor még ezt is elveszik tőle...

ui: verziószám megegyezik az övével, tehát tényleg nem értem

Szerintem ilyen esetekre kellene egy általánosan elfogadott időtartamot hagyni (mondjuk 45 nap)
Amit 45 nap alatt nem javítanak, az meg kikerül. Ezzel megoldódna az, hogy a gyártó évekig ül egy ismert biztonsági hibán, csak azért, mert még nem használják ki azt aktívan internet-szerte.

45 nap? Legyen mondjuk 4 nap és még az is sok.

42

14


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Inkább legyen 41, és kerüljön ki a 42. napon. :)
Ha 42 nap a türelmi idő, akkor a 43. napon kerülne ki, ami már túl van a világmindenségen, meg mindenen.

Hany programot fejlesztettel eletedben? Volt mar olyan, hogy egy kollegaval 2,5 napig debuggoltunk egy szoftverben egy alrendszert, gyakorlatilag sorros sorra at kellett nezni. Es egyedi rendszer leven nem kellett tobbezer masik rendszerrel valo egyuttmukodest tesztelni, csak a sajat rendszerunk integritasat. 4 nap az kurvara keves tud lenni egy nagyobb projekt eseten. Nem mindenhol divat osszebaszni valamit.

----------------
Lvl86 Troll

Viszont ott nem ketten vannak rá...
--
Discover It - Have a lot of fun!

Igen, ez pontosan így működik. Ha egy ember egy gödröt egy óra alatt ás ki, akkor ha ráengedünk ugyanerre a feladatra 3600 jómunkásembert, nyilván egy másodperc alatt készen lesz az a gödör.

jó lenne eltávolodni a végletektől. sehol nem állította, hogy lineáris az összefüggés.


szerintem.

Nemhogy nem lineáris, de egy pont után már erősen kontraproduktív plusz erőforrásokat a feladatra fordítani.

nyilván nem lehet a végtelenségig növelni az emberek számát, de azért nem 2 a vége. meg amivel jöttek, hogy a többi alrendszerrel összetesztelni, arra pont jó a sereg kollega, aki mind szépen megnézi a sajátjával. de kötekedj még, kérlek!


szerintem.

de kötekedj még, kérlek!
Mondd csak, van rajtad sapka?

+1 nekem is ez a benyomásom, ahogy elkezd egyre több ember dolgozni ugyanazon a programozási feladaton úgy kezd egyre több gáz előjönni. Csak nagyon jól particionálható (=kivételesen jól megtervezett) feladatoknál működik jól a többemberes fejlesztés. Hogy több ember _debuggolja_ ugyanazt a kódot az elég nehéz ügy, legfeljebb "a több szem többet lát" elv segít (nyilván 2-3 emberig működik jól ez is), de szisztematikusan felosztani a debuggolási feladatot a legritkább esetben lehet.
---
Internet Memetikai Tanszék

Ezt mar a 60-as evekben eszrevettek, nem uj dolog:
Fred Brooks: The Mythical Man-Month
http://en.wikipedia.org/wiki/The_Mythical_Man-Month

Itt o mar leirta: ha n embert dolgozik egy csapatban, n^2-tel aranyos a lehetseges kommunikacio szama. Azaz ha van egy mar kesesben levo projekt, azzal, hogy uj embereket teszel hozza, meg rosszabb lesz a dolog (az uj embert be kell tanitani stb.)

Azert *neha* vannak kiveteles esetek, pl. amikor eleve nagyon kevesen vannak egy projekten es az addigi csapattal eleve lehetetlen lenne megcsinalni idore a feladatot, mert tul sok. Persze ilyenkor ki kell szamolni, hogy a jelenlegi csapat kesese es koltsege hogyan aranylik az uj csapathoz.

De amugy igen, ilyenekkel tisztaban kellene lennie minden sw projekt vezetonek, csak azok meg ahogy latom, sokszor sehol nem tanultak ilyet, helyette nagyon jol elo tudjak adni a fonokseg erdekeit, ami idonkent muszakilag nem igazan indokolt :)

----------------
Lvl86 Troll

A Sw projekt vezetok tapasztalatom szerint altalaban progrmaozokbol lesznek, persze mindenfele vezetoi keszseg nelkul, nem nezenk utana effele projektmenedzsment dolgoknak, pedig fontos lenne. :(

"altalaban progrmaozokbol lesznek,"

Nem mindenhol... Igazabol egyik megoldas se teljesen jo, kulon szakma.

----------------
Lvl86 Troll

"de szisztematikusan felosztani a debuggolási feladatot a legritkább esetben lehet."

+1. Nalunk is a tobb szem tobbet lat elv miatt debuggolunk neha 2-n.

----------------
Lvl86 Troll

Kritikus besorolású hiba javítására a legtöbb helyen max 5 nap van, mire a végfelhasználóhoz ki kell kerülnie. Ebbe belatartozik a tesztelés is - jó esetben regression test settel. Láttam már olyat, hogy valaki karácsonykor vasárnap bement, mert ilyen jellegű hibát talált egy igen fontos megrendelő.
--
"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

Es erre a rendszerre is annyi minden epitkezik, mint a Windowsra?

----------------
Lvl86 Troll

Telekommunikációs forgalomirányításról volt szó. Kicsit más, de azért elég fontos, hogy ha hiba van, az ki legyen javítva.
--
"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

Ha még sok ilyen történik, aláássa a "megbízható és elfogadott módszertannal" készülő biztonsággal kapcsolatos statisztikáikat...

...

Igazabol rohejesnek tartom, hogy mindenki a -tobbnyire- marketingesek altal osszehordott hulyesegek alapjan probalja lemerni egy rendszer abszolut es relativ biztonsagat, ahelyett, hogy inakbb venne a faradtsagot, es utananezne, hogy melyik rendszer mit vallal.

Innen kezdve az egesz csak flamebaitre es hangulatkeltesre jo. Nameg sirni/orulni, hogy megint bantjak/istenitik mindenkinek a sajat kedvenc rendszeret.

Nalam:
abszolut biztonsag = az elmeleti maximalis biztonsaghoz viszonyitva mennyire biztonsagos valami.
relativ biztonsag = abszolut biztonsag / a hibak kihasznalasanak aranya.

----------------
Lvl86 Troll

Csak azt kene eszrevenned, hogy a penzekrol donto, a megrendeleseket fizikailag alairo, a munkat helyettunk kivalszto "fonokseg" ezekre a baromi hulye szlogenekre ugrik, es ez alapjan dont. Es se idejuk, se kedvuk, se igenyuk arra, hogy egy hozzaerto esetleg elmagyarazza nekik a valosagot. No sokunknak ez csipi a szemet.

Másrészt pedig ha alapos elemzést akar valaki csinálni, akkor nagyon hamar kiderül, hogy nem lehet egy univerzális metrikát csinálni erre, mert sok ellentmondó súlyozási megfontolás lehet és rengeteg gyakorlatilag nem mérhető, legfeljebb csak becsülhető metrika van. Ha pedig elfogadjuk, hogy nincs 1db mindenttudó, mindenki által elfogadott fő metrika, akkor azt is el kell fogadnunk, hogy nem lehet egy egyértelmű sorrendet felállítani a termékek között.
---
Internet Memetikai Tanszék

Saxi, nyugodj meg és vedd észre, hogy a posztom csak az Ms által hirdetett statisztikákról szól (tudod, amelyekben csak az a hiba amelyet az MS is beismert és javított).

...

Nyugodt vagyok en. Attol meg sokszor marketing celra beallitott, muszakilag irrelevans szamok, onmagukban idonkent viszonlag keveset mondanak.

Egyebkent megertem a beismert es javitott, nem beismert es javitott, nem beismert es nem javitott szortirozas lenyeget. Megjegyzem, gyakorlatilag a legtobb fejleszto igy mukodik. Az eroforrasok alapvetoen vegesek masreszt az teny, hogy hibatlan program nincs. (Azt most hagyjuk, hogy ez osszefugg a fejlesztesi modszerek es a fejlesztok kepessegenek szorzataval) Viszont egy ekkora termeknel megertem, hogy uzleti szempontbol indokolt az, hogy priorizaljak a hibakat es elorebb vegyek azokat, amik tobb embert erintenek/biztonsagi res es aktivan kihasznaljak, stb. Masreszt altalaban a hiba kijavitasanak lehetoseget is meg kell vizsgalni (nem okoz-e olyan mellekhatast, ami miatt inkabb tobb kart okoz a javitas, mintha hagynak) vagy hogy megeri-e egyaltalan vele foglalkozni (termekciklus hamarosan lejar es ugy is keveseket erint, pl.). Nameg felderiteni egy hibat neha szinten nem keves ido. Meg utana betesztelni.

De erre szoktak egy nagyon szep diagrammot mutatni szoftvertechnologia eloadasokon (kinek hogy hivjak), amin rajta van a hibak szama (csokkeno grafikon fuggveny) es a hibak javitasanak koltsege (novekvo fuggveny). Javitast meg altalaban a ket fuggveny metszeteig fogjak csinalni a cegek.

----------------
Lvl86 Troll

"nem okoz-e olyan mellekhatast, ami miatt inkabb tobb kart okoz a javitas, mintha hagynak"
Azert vegyuk eszre, hogy security hibarol beszelunk. Ilyenkor azert jobb helyeken a "hagyjuk" fel sem merulhet, megoldast kell adni ra. Akar a kerdeses funkcio tiltasa aran is.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Ha elkezdenék letiltogatni a funkciókat, másnap néhány millió dühös felhasználó verné az asztalt, hogy nem megy a szoftvere, és a cég vezetése meg már vehetné is a kabátját, kalapját.

Ez a hiba merteketol is fugg, egyebkent meg jo marketinggel mindent el lehet adni. De egyebkent nem azt mondtam, hogy a funkciotiltas uberalles megoldas, hanem azt, hogy a legvegso esetben akar azt is meg lehet lepni, ha a hiba merteke azt indokolja. Nyilvan en is tudom, hogy ez mivel jar user oldalrol (bar persze itt kerdes, hogy milyen szeles korben hasznalt funkciorol van szo, jelen esetben a Help & Support - barmily hihetetlen - nem egy szeleskoruen hasznalt funkcio, egy kezemen megszamolom, hany usert lattam hasznalni), azonban a security bug menten keletkezo anyagi kar miatti perek miatt ugyanugy veheti a ceg vezetese a kalap-kabatjat.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Gondolom az h a "szakértőink rajta vannak az ügyön" egy fél év után már kezd kicsit kínossá válni egy-két kritikus minősítésű problémánál. Pláne h így akkor egy pár újabb görbe is felkerül a diagramra, ami a presztízsveszteséget ábrázolja.

Akárhogy is csűrjük-csavarjuk, egyre inkább úgy tűnik, hogy sokak szerint nehezen védhető a ms reakciója a korábbi néhány hibával kapcsolatban.