Google Chrome eneste overlevende efter hackerkonkurrence

... og det er open source.

Det er meget imponerende!
Det kan dog diskuteres om den er sikker, da den sender mange oplysninger til Google selv. Evt. kan man prøve Iron.

Anser dog også Firefox som sikker, specielt hvis man installerer NoScript eller AdBlock (der kommer enorme mængder malware fra reklamer), og som altid er den største sikkerhed at have hjernen med. Ingen browser kan beskytte en mod malware .exe-filer man har hentet.

Den tid, det tog at hacke Browserne er ikke umiddelbart relevant da hackerne havde forberedt sig.

Problemet er også, at hvis den telefon eller bærbare computer som kører Google Chrome, ikke er interessant for hackerne går de efter de andre, mere interessante produkter.

Sidste gang var det mest interessante produkt man kunne vinde, en Sony Vaio hvis det ikke var forrige gang.

Hvis alle produkterne man så kunne vinde, var præcis de samme så ville hackerne gå efter hvad der er nemmest at hacke selvfølgelig.

Note:
Selvom Google Chrome måske er svær at hacke, er den ikke 100% sikker, læs eventuelt:
http://www.trusteer.com/files/Google_Chrome_3.0_Beta_Math.random_vulnera...

En tastefejl, ikke? pwn to own.

Det mest opsigtsvækkende angreb [...] var i stand til at omgå [...] Data Execution Prevention [...] samt Address Space Layer Randomization

Lad mig som operativsystemsdesigner lige forklare hvorfor dette resultat (ikke) er opsigtsvækkende:

De sidste 10 år har DEP/ASLR og lignende teknikker fået en helt uproportional omtale og er blevet solgt som de vises sten i kampen mod mal-ware.

Chipproducenter så DEP som en vector der kunne forcere opgraderinger til en ny generation af chips og OS producenter så ASLR som en magisk fernis der lukkede alle sikkerhedshuller.

Langt de fleste af "forsknings"-resultaterne der dokumenterede disse påstande, er helt uden værdi.

Enten fordi de stammer fra operativsystemer uden brugere eller angrebs-profiler, f.eks OpenBSD.

Eller fordi det er syntetiske resultater fra brute-force angreb på til formålet konstruerede setups, der intet har med virkeligheden at gøre. (Det vi kalder "phd-ware")

De kritiske røster, både i OS og sikkerhedsbranchen, har hele tiden påpeget, at ingen af metoderne er i nærheden af at være vandtætte, men blot inkrementalt gør det en smule sværere at udnytte programfejl.

Nu ligger liget på bordet: DEP og ASLR var bare lapper, ikke engang særligt gode lapper.

"There is no silver bullet..."

Poul-Henning

Kom nu frisk.
Der har været rigeligt med sikkerheds huller til chrome.
Så link da i det mindste til et der har været relevant for er stabilt release og ikke bare en beta.
Betaen bliver kun brugt af relativt få brugere og opdateret ret ofte. Pointen med beta er jo netop at fange fejl og sikkerheds huller.
Desuden er chrome stabil i v4 nu om dage.

Hvis man vil se beskrivelse af et par huller i den stabile udgave (som nu er lukket)
Se eventuelt patch 4.1.249.1036 http://googlechromereleases.blogspot.com/2010/03/stable-channel-update.html

Jeg har dog endnu ikke set nogen reelle exploites til chrome.
En af grundene til at de ofte når at lukke hullerne før der kommer exploits tror jeg er at google betaler hackere for at rapportere de huller. 500$ for et normalt hul (typisk dem der gør noget slemt som cross site scripting men ikke kommer ud af sandkassen) og 1337$ for de alvorlige huller.

DEP og ASLR var bare lapper, ikke engang særligt gode lapper.

Ja.

Jeg eksperimenterede med det for nogle år siden.

På en række 32-bits maskiner blev Stack Pointeren randomiseret over 23 bits (8MB), og på en 64-bits maskine over 32 bits (4GB).

Jeg havde:
1) en applikation med et klassisk buffer overflow (evt. kun ganske få bytes i bufferen).
2) 126kB (17 bits) plads til environment variable.

Dvs. på et 32-bits system krævedes i gennemsnit 2^(23-17) = 64 forsøg for at få et shell prompt.

På et 64-bits system krævedes i gennemsnit 2^(32-17) = 2^15 = 32k forsøg for at få et shell prompt.

Så hvis den slags brute-force forsøg er mulige og ikke bliver stoppet hurtigt nok, så hjælper ASLR ikke.

Der er siden kommet andre lapper på markedet, f.eks. har gcc en option -fstack-protector, så et buffer overflow "kun" giver et SIGILL.

En anden mulighed er at sætte No-Execute Bit i BIOSen (og - i hvert fald i princippet - at afvikle den binære via valgrind).

[*] Google 'Smashing The Stack For Fun And Profit'.

PS. pwned læser jeg som 'owned with a stick'.

Den her rapport er ret interessant læsning:

http://www-users.rwth-aachen.de/Tilo.Mueller/ASLRpaper.pdf

Der er siden kommet andre lapper på markedet, f.eks. har gcc en option -fstack-protector, så et buffer overflow "kun" giver et SIGILL.

Dette kaldes en stack canary eller stack cookie, og kan også (givet de rette omstændigheder) omgåes med kodeeksekvering som resultat. En stack cookie lægger sig mellem en funktions lokale variable og returadressen, men man kan altså stadig overskrive de lokale variable...derunder funktions pointere og andet godt, og hvis man har mulighed for at udnytte en format streng, så kan man overskrive hukommelse meget mere målrettet.

Pak nu lige fest-hattene sammen, og sluk cigaren. Chrome er slet ikke blevet forsøgt cracket på den første dag.

det bliver spændende i morgen :)

her er en artikel fra sidste år:
http://blogs.zdnet.com/security/?p=2941

hvor Charlie Miller siger at chrome er svær at exploit pga. dens sandbox'en.

(off topic: han har godt nok ikke meget til overs for Mac sikkerhed )

Tænk - det er det måske en grund til...

/Peter

Tænk - det er det måske en grund til...

Måske for at skabe overskrifter som ovenstående?

eller måske man går efter det som man ved/forventer er let og hurtigt at hacke.

hvis du skulle stjæle en guldbarre i hhv. en papkasse omvilket af en våd berlinger, eller fra en boks med 10" armeret stål, hvilken ville du så først forsøge at bryde ind i, hvis du måtte beholde indholdet ?

Vi kan jo alle spekulere vildt om hvorfor de ikke er gået efter Chrome i dag. Skulle det ske at pwn2own afsluttes uden at Chrome får ridser i lakken, jamen så er der grund til at skrive artikler. Men indtil da er det ret beset ikke andet end trolling.

Fra Computerworld artiklen: "If history is any indication, vendors will push out patches for the exploited vulnerabilities fairly quickly. In 2008, for example, Apple took just three weeks to patch the Safari bug that Miller used to win $10,000 at his inaugural Pwn2Own."

Apple er godt nok ikke særligt imponerende sikkerhedsmæssigt. Jeg skriver dette fra en Mac, som jeg iøvrigt er rimelig glad for (*), men jeg bliver mere og mere fristet til at installere noget andet på den.

Hvis Firefox bliver udsat for den slags fejl, vil der typisk være en fornuftig fix meget, meget hurtigere.

(*): Hardwaren er ikke pengene værd, men OS'et er IMHO en bedre oplevelse end så meget andet.

Note:
Selvom Google Chrome måske er svær at hacke, er den ikke 100% sikker, læs eventuelt:
http://www.trusteer.com/files/Googl...

Antyder du, at dette sikkerhedshul fra version 3.0 beta ikke er blevet lappet i version 4.1 når det er fuldt ud dokumenteret og offentligt tilgængeligt?

Ja, der er exploits til Chrome. Ingen tvivl. De er bare meget svære at udnytte og finde i forhold til andre browsere - og når du endelig kommer forbi skal du også lige slås med Windows, som også er godt beskyttet.

Jeg har dog endnu ikke set nogen reelle exploites til chrome.
En af grundene til at de ofte når at lukke hullerne før der kommer exploits tror jeg er at google betaler hackere for at rapportere de huller. 500$ for et normalt hul (typisk dem der gør noget slemt som cross site scripting men ikke kommer ud af sandkassen) og 1337$ for de alvorlige huller.

Netop. Der er måske huller, men Google gør mere end man sædvanligt ser for at få dem rettet.

Jeg skal i øvrigt rette mig selv: Det er selvfølgelig ikke rigtigt at Chrome aldrig er blevet hacket. Det jeg mente var, at det aldrig var blevet hacket i konkurrancesammenhænge hvor hackerne evt. har begrænset tid. Det er simpelthen alt for besværligt og svært i forhold til at hacke den Macbook eller IE-maskine der står ved siden af.

Og held og lykke når Chrome OS kommer på markedet. Selv hvis du faktisk får hacket den vil den bare ominstallere sig selv næste gang brugeren genstarter eller der kommer en opdatering fra Google.

Chrome er så ikke Open Source.

Learn your facts :)

Chrome er så ikke Open Source.

Learn your facts :)

http://en.wikipedia.org/wiki/Chromium_(web_browser)

Oh, really?

RED: Irriterende linker er irriterende. Kære Version2: Der kan GODT være parantes i URL's! >.<

Efter "wiki/" skal der stå "Chromium_(web_browser)"

Ja sorry.... Ville bare se om man kunne escape'e paranteserne... Var et forsøg på en lappeløsning på ovenstående problem... Så meld hellere indlægget end giv det minusser - hvis jeg selv kunne fjerne det havde jeg gjort det :)

Mener at have læst et sted (sandsynligvis på newz.dk) at en grund til at chrome ikke blev hacket var at ingen forsøgte. Grunden til dette var efter sigende blandt andet at chromes sandkasseteknologi gør det svært faktisk at udnytte sikkerhedshullerne.

Eller er det fordi der ikke er nogen der har fået en chrome timeslot i den tilfældige udtrækning af hvornår de forsøger at pwne browser styresystem kombinationerne...

Så kan = måske men google udgav en veltimet opdatering lige før pwn2own så der er ingen af forskerene, der har haft tid til at lave et script der er lige til at sætte igang så man kan levere "pwnage" on que...

Samtidigt fra Ars Tech:
"Neither the iPhone exploit nor the IE8 exploit managed to escape the OS-supplied sandboxes that protect these platforms. Without escaping the sandboxes, the impact that flaws can have is reduced, preventing, for example, writing to hard disk (and hence, preventing installation of malware). Nonetheless, read-only access is still valuable for data theft."

Im shaking in my boots... så den store kur mod dette hack er genstart din telefon eller comp...

Det eneste dette viser er at hvis du giver forskere nok tid så kan de finde huller i alting og udnytte dem. Ergo er lektien her... wait for it... OPDATER DINE LIBS og styresystem konstant hvis du lader noget køre uopdateret i mere end et par måneder så vil der være en sikkerhedsrisiko forbundet ved det.

Men hvorfor opdatere Apple så ikke Safari konstant eller udgiver en opdatering hver 5 minut så man kan være på bleeding edge hele tiden..

Hmm tjoe man kan sige meget men den dag hvor der er faktisk viruser i omløb på et nivau hvor det er nødvendigt at ha antivirus på Mac OS X så kan man faktisk sige at Apple ikke håndtere sikkerheden ordenligt. Indtil den dag så kan man sige at der er mange sikkerheds problemer, men den samlede mængde af sikrings systemer som Mac OS X har er nok til at de fleste er sikre nok til at de ikke med jævne mellemrum oplever at deres maskine er blevet hacket.

Hvis man har brug for mere sikkerhed end det så hyr et It sikkerheds firma til at sikre dit netværk eller gå ind og brug de værktøjer der er nævnt i Apples Common Criteria Guide

https://ssl.apple.com/support/security/commoncriteria/

Hvordan er det nu med stable releases af Unixer og seneste version af libs og apps... damn de lager også bagefter. Men der er der mere kultur for at hvis der er en sikkerhedsrisiko, så opdatere man til unstable versionen af libet og græder over det der gik i stykker bagefter.

Hvis man bruger et mainstream, ikke hærdet OS så er det omvendt.

Ja det giver længere tid hvor man er "eksponeret for risici" men med alle de sikkerheds huller der har været (selv "store" problemer som OpenSSL problemet med renegotiation) så er der stadig ikke nogen real virus trussel
på Mac OS X.

NB! Mac systemer der stadig bruger 10.5 og ikke opdatere deres libs med port har stadig openssl 0.9.7l som har renegotiation hullet. Men åbenlyst er det ikke nemt nok at udnytte til at der er viruser der udnytter dette kataklysmiske sikkerheds problem til at lave et Mac OS X botnet.

Det ændre sig måske men so far holder de skansen.

Kunne være interessant at se hvordan webkit dayli, klarede ærterne men fordi den ikke er stable release så er der nok ikke nogen der vil komme frem og sige den kan de sagtens hacke da de ændringner der laves fra dag til dag i koden vil kunne kaste en svensknøgle i tandhjulene på hacket.

Hmm hvis nu google er gode og sender deres patches til webkit.org så burde webkit dayli være lige så sikker som chrome...

Kald mig fanboi, men med mindre du indtaster dit adm password, der du ikke skulle (pornosite download codec installs eller pirat software installs), så er der idag ikke en udbredt sikkerheds risici på Mac OS X ved almindelig brug hvis du er fuldt opdateret.

Så for at citere Jerry Maguire "SHOW ME THE MONEY!!!" ellers er det her andet end en mulighed for sikkerhedskonsulenter til at promovere sig.

Speaking of sikkerhed hvad skete med den kinesiske forsker der beskrev hvordan man kunne provokere en kolission i sha-1 på 2^58 steps for snart et par år siden... har ledt efter det i et par omgange men finder kun det der blev publiseret dengang det først kom ud.

Oh, really?

Ja!

Som du kan læse (ja, det håber jeg du kan), så er Chromium og Chrome ikke det samme. Chrome bygger på Chromium, men det gør den ikke nødvendigvis til open source iflg. BSD-licensen:
http://en.wikipedia.org/wiki/BSD_license

• Der er i dit link ikke specificeret hvilken udgave af BSD-licensen der er anvendt. Begrebet "Free Software" som der henvises til under linket for BSD-licensen er også noget uldent, idet Free Software er et begreb opfundet af forfatteren til GPL og dele af BSD-licensen (den oprindelige) er ikke kompatibel med GPL.

http://www.examiner.com/x-39728-San-Jose-Technology-Examiner~y2010m3d28-...