Názory k článku
V prohlížeči Edge je závažná chyba, záplata byla odložena
-
hacker (neregistrovaný)
Bližší informace nebyly zveřejněny? https://bugs.chromium.org/p/project-zero/issues/detail?id=1011
-
Ondra Satai NekolaZlatý podporovatelAno, to je problem. MS by s tim mel neco delat a zlepsit svou rychlost.
-
koudy (neregistrovaný)
Chrome je děravější než Edge.... [citation needed] ?
Pokud mají 3 měsíce na opravu závažné chyby, tak je to dostatečná doba...
Pokud o chybě vědí, velice pravděpodobně ji už někdo využívá, proto je dobré chybu opravit co nejdříve, ať o ni širší veřejnost ví, nebo ne.
Navíc se dá, pokud o chybě víte, občas nějakým způsobem obejít/work around. (mluvím obecně ke zveřejňování chyb v SW)Chrome opravy závažných problémů vydává, řekl bych, o něco rychleji.
-
Ad Chrome je děravější než Edge.... [citation needed] ? - správný dotaz. Rok 2016, Chrome 172 vulnerabilities, Edge 135 vulnerabilities, Internet Explorer 129 vulnerabilities. Q.E.D.
http://www.cvedetails.com/top-50-products.php?year=2016Ad Pokud mají 3 měsíce na opravu závažné chyby, tak je to dostatečná doba - psal jsem Problém je spíš v tom že ke zveřejnění problému došlo před uvolněním záplaty. Tomu se dá předejít odložením zveřejnění chyby nebo urychlením vydání patche. Nevím jak MS interně bezpečnostní problémy řeší, ale 3 měsíce mi osobně také připadají jako dost času.
Ad Chrome opravy závažných problémů vydává, řekl bych, o něco rychleji - nemám data, abych to mohl objektivně posoudit. Máte je vy?
-
portyr (neregistrovaný)
Žádná hypotéza. S větším rozšířením se odhalí více bezpečnostních chyb, protože se na aplikaci soustředí více živlů, protože mohou postihnout více zařízení. Na tom není nic k diskuzi :-)
Další nepochopení věci pramení z dokazování děravosti počtem nalezených bezpečnostních chyb. Když chyby nikdo nehledá, nehlásí a neopravuje, neznamená to, že je produkt málo děravý. No a takové situaci je blízko Edge.
-
Dává větší smysl děravost měřit počtem dní, kdy je děravý produkt bez záplaty, ale chápu, že taková metrika není k výtvorům MS zrovna lichotivá.
A tady máš nějaké povídání
http://sensorstechforum.com/which-is-the-most-secure-browser-for-2016-firefox-chrome-internet-explorer-safari-2/https://tiptopsecurity.com/what-is-the-most-secure-web-browser/
-
Ja v tom problem nevidim. To, ze Google o chybe vedel a nezverejnil ju totiz nedava ziadnu garanciu toho, ze o tej chybe nevedel aj niekto iny a aktivne ju nezneuzival na utoky. To, ze sa neprislo na aktivne zneuzivanie chyby neznamena, ze sa tak nedialo (napr. sa to nemuselo diat v dost velkom meritku a/alebo dost dlho).
A security through obscurity nie je prave najlepsi pristup, ak sa to tyka veci trivialne exploitovatelnej na dialku.
Takto aspon potencialne obete vedia, ze maju moznost sa bud IE/Edge vyhnut, alebo ak je to nemozne (co zrejme vdaka pouzivaniu jadra Trident na renderovanie dlazdic a vsemozneho bordelu tahaneho online hore dole po windowse nemozne bude), maju ocakavat problemy a dotycne endpointy lepsie zabezpecit.
O tom, ze Microsoft poziadal o odklad kvoli tomu, ze chceli problem riesit systematicky sa bavit odmietam, zvlast ak pri kazdom druhom update je napisane, ze opravuje chyby ktore vznikli po aplikacii ineho updatu.
-
MasoxCZ (neregistrovaný)
To, že odložili velebalík aktualizací plyne z "lehce" schizofrenního přístupu uživatelů, kteří nadávají jak v situaci kdy MS oznámil že postupně přejde na rolling update (a bude jim sw měnit pod rukama), tak v situaci kdy rolling update ještě nemá a aktualizuje v dávkách, kdy je důsledkem downtime. Až na to, že při aktualizacích v dávkách je větší šance, že se něco pojebe a v lepším případě se bude rollbackovat, v horším se pár uživatelům mašina změní v cihlu. A je to blbě jak v případě, že cihel udělají stovku z půl miliardy, tak v případě že si řeknou že i ta stovka je moc a pozdrží to do otestování opravy. Jenomže ať to udělají jak chtějí, vždycky to remcalům nebude dost dobře.
-
Petr M (neregistrovaný)
Jenomže jsou dva druhy update:
1) Změna funkcionality, vylepšení atd. To si můžou klidně naplánovat 1x za rok a nic se neděje.
2) Oprava chyby. Tam to uživatel nepostřehne, ale je důležitý třeba memory leak nebo chybu vedoucí ke vzdálené eskalaci práv fixnout pokud možno hned.Oni to nejenom sloučili, ale sloučili to do jednoho blobu. A když ten blob rozbije DHCP, tak s jeho vyhozením přijdeš i o opravy 10 jiných 0-day (už tak distribuovaným s několikatýdenním zpožděním).
Mě třeba vyhovuje Fedora. Velký update (nová verze) 2x ročně s tím, že jsou podporovaný dvě verze paralelně a pokud je oprava nebo nová verze čehokoliv, tak si ji můžu kdykoliv stáhnout. A jako bonus - jde to i bez rebootu, pokud to není update jádra... A navíc jsou tam zahrnuty i aktualizace , možnost držet u nějakýho balíčku stejnou verzi (třeba u kompilátoru),...
Že to zvládne OSS zadarmo a nezvládne to předražený komerční produkt, to je přece ostuda.
-
Filip JirsákStříbrný podporovatelProblém je, že tohle hezké ostré rozdělení updatů je jenom hezká teorie. Praxe je bohužel jiná, často změna funkcionality nebo vylepšení také opraví nějakou chybu, nebo se naopak s opravou chyby i změní nějaká funkce nebo přidá drobné vylepšení.
To sloučení do jednoho blobu dává smysl, pak stačí otestovat ten jeden blob. Když to rozdělíte na deset malých částí, musíte jednak definovat závislosti (např. update 3 závisí na updatu 1), jednak by se měly otestovat všechny možné kombinace těch částí.
Mně osobně naopak připadá špatné a neudržitelné „backportování oprav“ v tzv. stabilních distribucích, protože to akorát znamená, že někdo, kdo nějakému kódu nemusí moc dobře rozumět, vyrábí verzi programu, která nikde jinde není a otestuje ji nanejvýš QA dané distribuce.
-
To sloučení do jednoho blobu dává smysl, pak stačí otestovat ten jeden blob. Když to rozdělíte na deset malých částí, musíte jednak definovat závislosti (např. update 3 závisí na updatu 1), jednak by se měly otestovat všechny možné kombinace těch částí.
Jenze ten jeden blob neopravuje jednu vec, ale celou radu. A kazda z tech veci by mela byt zaplatovatelna zcela nezavisle na zbytku. Pokud to tak neni, tak je neco spatne a v MS maji jeste horsi bordel, nez jsme doufali.
-
mhepp (neregistrovaný)
Jenže srovnáváš backportování oprav ke stovkám aplikací ood tisíců vývojářů. To je špatně udržitelné. Naproti tomu M$ má opravovat jen svůj produkt. Zde je to naopak velice dobře udržitelné. Samozřejmě, budeš se pohybovat na hraně, zvláště když bude potřeba opravit chybu v návrhu komponenty, ale nezapomeň, že M$ drží kompletní zdrojáky celých Windows a u každé změny ví (by měl vědět) proč ji udělal. Pak můžeš rozlišit opravu a vylepšení.
-
Filip JirsákStříbrný podporovatel
Opravu od vylepšení třeba ještě můžu ve zdrojáku odlišit. Jenže pak se obojí sejde v jedné dll. A oprava v jedné dll je závislá na vylepšení v jiné dll. A teď to udržte, aby všechno se vším fungovalo.
-
Petr M (neregistrovaný)
"Jenže pak se obojí sejde v jedné dll."
Tak normálně pracuju dál. Není problém. Když je to v jiné části zdrojáku, tak se to nepotká a konflikt vyřeší ten, kdo pošle změnu jako poslední. Od toho snad ten verzovací systém je (chápu, v M$ Visual Source Safe je to opravdu neřešitelný :D :D :D ).
"A oprava v jedné dll je závislá na vylepšení v jiné dll"
Tak to je pak chyba ve špatně navrženým/dokumentovaným rozhraní, ne v software. Chyba zapouzdření modulů není generální pardon pro patlaly. Mají to udělat líp, jsou za to placení.
-
Filip JirsákStříbrný podporovatel
Když je to v jiné části zdrojáku, tak se to nepotká a konflikt vyřeší ten, kdo pošle změnu jako poslední. Od toho snad ten verzovací systém je
O to vůbec nejde. Když máte v jedné dll opravu chyby i novou vlastnost, nemůžete distribuovat zvlášť záplatu s opravou chyby a zvlášť záplatu s novou vlastností.Tak to je pak chyba ve špatně navrženým/dokumentovaným rozhraní, ne v software. Chyba zapouzdření modulů není generální pardon pro patlaly. Mají to udělat líp, jsou za to placení.
To je hezké, že jste teoreticky pojmenoval problém. Ale když je potřeba opravit CSS parser, který umožní spustit libovolný kód, těžko můžete prohlásit, že se oprava odkládá, protože je celá aplikace špatně napsaná a je potřeba jí od základů přepsat.Je hezké, že víte, jak byste psal Windows vy, ale tady se řeší jiný problém – Windows už existují, pár uživatelů je používá, byla v nich nalezena chyba, a teď je potřebu tu opravu co nejdřív dostat k uživatelům, pokud možno bez rozbití něčeho jiného.
-
Petr M (neregistrovaný)
<i>Když máte v jedné dll opravu chyby i novou vlastnost, nemůžete distribuovat zvlášť záplatu s opravou chyby a zvlášť záplatu s novou vlastností.</i>
Děláme to běžně. Zákazník má opravu k dispozici hned v den, kdy se najde řešení chyby. V dalším release je zahrnutá automaticky, pokud (snadno dohledatelný) vývojář dodrží proces.
Hint: Jiná větev pro release a jiná pro vývoj a možnost vyrobit ze změn path, který se aplikuje na obě větve. Konflikty se řeší tak, že pro každou změnu je extra branch, merge až po dokončení a kdo dělá merge jako poslední, řeší konflikty.
<i>To je hezké, že jste teoreticky pojmenoval problém...</i>
Vývojář musí vidět problém a pokud ví, že ho nemůže hned fixnout, tak to má reportovat jako bug a po vydání opravy řešit, co s tím dál. Je to jeho práce a bez toho SW hnije.
Nevím, jestli to u M$ nereportují, nebo jestli ty reporty ignorují, aby měli manažeři krásnější grafy z bug trace systému, ale je fakt, že ten hnilobný zápach z Redmondu je cítit až sem. S tím opravfdu nic neudělám.
<i>Je hezké, že víte, jak byste psal Windows vy, ale tady se řeší jiný problém – Windows už existují, pár uživatelů je používá, byla v nich nalezena chyba, a teď je potřebu tu opravu co nejdřív dostat k uživatelům, pokud možno bez rozbití něčeho jiného.</i>
Rychlá distribuce oprav a minimum bugů by měl být u každýho SW (nejenom u Widlí) dlouhodobý cíl a dá se ho dosáhnout jenom tím, že se udržuje pořádek ve zdrojákách. Ostatně, starost o zdrojáky je jedna z mnoha povinností vývojářů a pokud to nedělají, jsou jako pekaři, kteří odmítají míchat těsto.
Btw, nejsou to teorie, 2 roky zpět jsem se certifikoval na agilní řízení SW projektů... A budeš se divit, opravdu to všechno jde, jenom chtít a myslet.
-
Filip JirsákStříbrný podporovatel
Asi bychom si měli ujasnit pojmy. DLL je dynamicky linkovaná knihovna, je to jeden binární soubor. Změny, patche, větve a branche se týkají verzování zdrojových kódů. Z těchto zdrojových kódů pak překladem vznikne ta DLL knihovna. Vy můžete mít ve zdrojácích kolik chcete větví, ale uživatel má ve Windows nainstalovanou jenom jednu verzi té knihovny. Dostává celou zkompilovanou knihovnu, nebudete mu patchovat binárku. Tím pádem mu můžete v updatu dát DLL s opravou chyby, DLL s novou valstností, nebo DLL s opravou chyby a novou vlastností. Pokud mu chcete dát na výběr, musíte mu tedy nabídnout tři různé updaty, které se navzájem vylučují. A měl byste všechny tři otestovat. A pokud budete mít jinou knihovnu, kde budete mít také opravu a novou vlastnost, máte další tři updaty a k testování devět kombinací.
Nemusíte mne přesvědčovat, že to jde, já to vím. Ale Microsoft teď nezačíná na zelené louce ani není v pozici, že by teď mohl dát stopku a několik let psát nový OS, aby vyřešil všechny technologické dluhy. Resp. Microsoft to klidně udělat může a dělá to, jenže vedle toho musí udržovat stávající instalace Windows a poskytovat nové verze. Když máte bezpečnostní díru v aplikaci, kterou používají miliony uživatelů, nemůžete řešit dlouhodobé cíle, ale musíte tu chybu opravit. Dlouhodobé cíle je vhodné řešit také, ale je to něco jiného – a nepoznáte to na jednom updatu.
-
Petr M (neregistrovaný)
Není, pokud je SW dobře navržený. Tzn. modulární. Pak v případě třeba buffer overflow přidám unit test na detekci chyby, zkontroluju, že selhal, opravím modul, zkontroluju, že už jsou unit testy proti rozhraní OK a pošlu Jenkinsovi. Ten provede integraci, zkontroluje, že se to nerozbilo a vyplivne instalačku. Automaticky. A klienti můžou sosat opravu.
Jenomže poslední modulární soft, co jsem od M$ viděl, byl MS-DOS 6.22. Tam bylo jasně rozdělený, co má na starost io.sys, co msdos.sys a co command,com a jasně daný rozhraní přes (tuším) INT33 na BIOS.
Teď nejspíš oprava HTML parseru prohlížeče pravděpodobně znamená automaticky rebuild jádra a přetestování Solitaire a Notepadu... A to se pak člověk nesmí divit ničemu.
-
Filip JirsákStříbrný podporovatel
Přesněji řečeno „dělají to už dvacet let“. Zda to funguje je otázka. Za těch dvacet let se také „trochu“ změnilo to, jak se software vyvíjí, a také to, jaký software a kolik ho v těch distribucích je.
-
j (neregistrovaný)
Tak to jiste jirsak, vyviji se 10x rychlejs, a v distribucich toho je 100x vic. Jen ty (naprosto holy) widle se patchujou s kazdou dalsi verzi hur a hur.
Pritom soudruzi v M$ prisli s takovym krasnym napadem ... ze kazdyho 1/4 roku ty widle proste preinstalujou ... vratej nastaveni do defaultu ...aplikace smazou, a presto jim to nefunguje. Kdepak asi udelali chybu ...
-
Ak urobite z pocitaca tehlu opravou bezpecnostnej diery vo webovom prehliadaci je nieco s vasim pristupom k architekture software-u fundamentalne zle bez ohladu na to, aky velky balik bezpecnostnych zaplat je.
Z mojej skusenosti s gigantickymi korporaciami so skamenelymi strukturami si dovolim predpokladat, ze v Microsofte su technicki neschopni realizovat paralelnu dodavku bezpecnostnych zaplat ASAP a funkcnych upgradov. Mame rolling updaty tiez a tiez toho nie sme schopni. Problem je extremne siroky a pokryva ako developerov, ktori nie su schopni (alebo ochotni) zamysliet sa nad dosledkami svojej zmeny cez spravcov repozitarov, ktori nie su schopni udrzat genealogicky strom krizovych integracii pod kontrolou a ak by existovalo viac paralelnych vetiev, ktore by vsetky koncili v produkcii, nikto by v skutocnosti netusil, co v masteri je az po management, ktory to ma cele na haku a vobec situaciu nechape.
V skratke. Ak by niekto tu vec patchol vcera a dnes by vysla prioritna zaplata, je zhruba tak nulova istota ze ten patch este pobezi so zmenami, ktore su planovane na vydanie buduci tyzden. Problemy by mohli byt od zlyhavajucich testov cez nemoznost to s tou zmenou skompilovat a nemoznost to zintegrovat az po to, ze by developer, co to opravil, medzitym odisiel na dovolenku a zmena by sa zabudla do mastera dodatocne zintegrovat.
-
j (neregistrovaný)
Zajimavy ze tuxi distra s tim zadnej problem nemaj ... asi existujou v jinym vesmiru.
Ono se to totiz dela tak, ze se o nejaky verzi (ta funcionalita) prohlasi ze je stable a supported. A prave vuci ni se vydavaj patche - vyhradne bezpecnostni a zadny jiny. Tech verzi samo muze byt i nekolik. A prevazne maji nejakej termin, kdy se do nich uz patche vydavat nebudou (rok, dva, tri ...).
Dokonce je to tak, ze prave tvurce distribuce zajistuje portaci bezpecnostnich patchu do verzi ktery podporuje on.
Tudiz pochopitelne pokud mam mezi uzivatelema 10 podporovanych verzi, musim vydat 10 variant patche, pro kazdou verzi extra. Divny co?
-
Linuxove distra su trocha ina kava z toho hladiska, ze sa na ne nevztahuje standardny korporatny development process. Dokonca som toho nazoru, ze korporacia je bezzuba pri akomkolvek pokuse aspon trocha napodobnit tak masivne distribuovany a na komponentoch zalozeny vyvojovy model.
Kazdy developer kazdeho komponentu si zvacsa vedie svoj upstream a z toho upstreamu potom autor distribucie vysklada a otestuje nejaky set verzii komponentov. Ak sa najde bug *obvykle* je tomuto maintainerovi zaslany a ten ho fixne v masteri. Ak ma distribucia to stastie, ze pouziva prave najnovsiu verziu kniznice, ma vystarano, pretoze staci prebrat aktualnu verziu a ak sa ziadna dalsia funkcionalita nepridala, veci su viac-menej safe. Ak to stastie nema, bud musi patch backportnut na staru verziu, alebo ak to nejde, vyvinut si vlastny. Samozrejme nie je vylucene, ze niektora distribucia patch vo vlastnej rezii vyvinie a zasle ho autorovi komponentu na zaclenenie.
Klucova vec ktoru korporacie nie su schopne (ani ochotne) podchytit je to, ze tento na komponentoch postaveny vyvojovy proces je maximalne dezorganizovany. Neexistuje ziaden formalny high level managment a je prakticky nemozne si vyziadat nejaku vlastnost v nejakom komponente. Aby toto cele vobec nejako fungovalo, existuju nejake elementarne pravidla pouzitelnosti a prezitia, ktore musia vsetci dodrziavat (viac alebo menej). V korporacii je toto prevedene na nizsi stredny management, ktory je v tomto typicky uplne bezzuby. Nazorove prudy typu agile tejto bezzubosti nahravaju este viac.
-
Petr M (neregistrovaný)
Často je to proto, že chybí nastavení interních procesů. Třeba tyhle pravidla pro GIT:
1) K zákazníkovi jde master větev.
2) Do master větve smí udělat merge jenom QA na základě zelených testů, a to jenom z větve stage
3) Do větve stage smí udělat merge vedoucí teamu, který odzkouší základní funkcionalitu.
4) Vývoj probíhá ve větvi devel, merge do stage se provede před testováním release (feature freeze).
5) Chyba (v testech) se opravuje ve stage, merge se provede i do devel.
6) 0-day se opravuje v master, merge i do stage a devel.
7) Každá změna probíhá tak, že se pro ni udělá vlastní branch, který se pak sloučí s příslušným branchem.
8) Každý merge probíhá tak, že si pracovník stáhne cílovou větev, udělá merge u sebe, zkontroluje, že nic nerozbil a pak teprve provede push.
9) Po odeslání dat nejde domů, dokud neprojdou unit testy na CI serveru
10) za dodržení pravidel zodpovídá příslušný pracovník; motivací budiž pohyblivá složka platu.Pak je to samozřejmě i o kvalitě testování, pokrytí testy, svéprávnosti zaměstnanců,... Ale počítám, že když má někdo systém na konkrétním NTB za řekněme $1000, od každýho se prodalo min. 50k ks a za kus dostal řekněme $10, tak utržili $500 000 a koupě jednoho kusu na testování i se zapojením a elektrikou je jenom plivnutí. A pokud jde o test automatický (nasaditelný na různý HW), tak jeho cena není ani na úrovni toho železa...
-
Filip JirsákStříbrný podporovatel
Že je vykreslovací jádro webového prohlížeče součástí desktopového operačního systému je pochopitelné. A v tomto případě jsou na tom Windows lépe, než linuxové distribuce – tam jsou desktopová prostředí také závislá na vykreslovacím jádru webového prohlížeče, akorát že si každý framework s sebou nese svou vlastní neaktualizovanou verzi, takže pak máte v systému několik různých zastaralých WebKitů se známými bezpečnostními dírami.
Na Windows je problém spíš v tom, že není pořádně oddělený systém a GUI (server už snad jde spustit v headless režimu, ale na desktopu to nějak není vidět). -
Petr M (neregistrovaný)
Počkej, on někdo nutil M$, aby Widlous update sešrtooval do jednoho balíku a když se jim ho 6x nepovede zbuildit, tak byl komplet jejich SW půl roku bez záplat? A oni servery, ze kterých se update stahuje, mimo konkrétní den v měsíci vypínají, že není možný tam kopnout mimořádku?
-
nobody (neregistrovaný)
dalsi dukaz pro 2 zavazne problemy s Windows:
1. vydavani aktualizaci jako "sada/pack" je naprosta hovadina co neumozni vydat samostatny patch dokud nebude pripraveno vse pro zahrnuti do packu...
2. microsoft neni schopny za 3 mesice opravit chybu a prska kdyz je na to poukazano at jiz zverejnenim chyby, v 3mesice dopredu stanovenej terminu, nebo jakkoliv jinak...
-
MasoxCZ (neregistrovaný)
Dovolím si jen poopravit terminologii. Oni to opraveno dávno mají, "jen" se "tak trochu" nedaří distribuce.
Výsledek je prakticky tentýž, jen z jiných příčin a k nápravě potřebuje provést jiné kroky.
BTW se to "krásně" projevilo na W10 Mobile na Lumii 950XL, kterou jsem měl půl roku, a celkově mi perfektně vyhovovala. Jenže nakonec mě jedna jediná věc donutila ji vrátit. Co to bylo?
Taková festovně otravná drobnoat, která ten telefon naprosto diskvalifikovala z pracovního použití: nikdy jsem nevěděl, co mi ráno fungovat bude, co ne, a jak dlouho bude trvat, než to fungovat znova začne.
Třeba úplně na začátku dva měsíce nešlo používat wifi, protože neudrželo spojení. Pak dva týdny nešel BT. Pak 10 dní GPSka a určovalo to polohu jen podle sítí. Jindy to během hovoru rebootovalo. Pak zas nefungovala 2G síť a měl jaem jen wifi / 3G / LTE. Což v ČR je dost průser.
A úplně nejhorší bylo, že už opravené chyby se několikrát vracely.
V půlce září mě přestalo bavit i jen kontrolovat, jestli už je opraveno chybné psaní kapitálek s diakritikou v UWP aplikacích (tzn. nahodíš CapsLock a česká písmena na číslicích se psala pořád jako malá). Týkalo se to i desktopu. Dost smutné, vzhledem k tomu ze v desktop módu to funguje nějakých 30(?) let.
ČLÁNKY DO MAILU