Google Chrome: Den nye rasen av nettleser

Chrome-utviklingsteamet fokuserte på tre ting; stabilitet, hastighet og sikkerhet. Chrome er stabilt og raskt, men hvordan vet vi om det er sikkert?

-------------------------------------------------- ---------------------------------------

Det kan være vanskelig å avgjøre om noe er sikkert. Heldigvis har programvare fordelen med å teste regimer som Pwn2Own-konkurransen. Hvis programvaren har noen svakheter, vil de høyt kvalifiserte deltakerne finne dem.

Det tok lesing om årets konkurranse for å overbevise meg om at Chrome er sikkert, og at jeg trengte å bytte. Jeg begynte også å lure på hva som skiller Chrome når det kommer til sikkerhet. Etter litt graving møtte jeg Ian Fette fra Google Chrome-teamet. Han ga den nødvendige innsikten:

TechRepublic : Det har blitt nevnt flere ganger at sikkerhet var en topp prioritet når du utformet Chrome. Kunne du liste de tre største sikkerhetsproblemene til utviklingsteamet?

Fette : Når vi bygger Google Chrome, ønsket vi å designe nettleseren med dyptgående sikkerhet. Vi vet at det ikke er en eneste sølvkule som løser alle sikkerhetsproblemer, så vi ønsket å utvikle sikkerhetsfunksjonalitet på alle nivåer i applikasjonen. Tre områder der vi investerte mye tid var:
  • Advarsel brukere når de fikk tilgang til et utrygt nettsted.
  • Arbeid for å hindre at ikke-klarert kode ikke forlater nettleserens sandboks-gjengivelse.
  • Forsikre deg om at brukerne alltid har den nyeste og mest oppdaterte versjonen av nettleseren på en så rask tid som mulig.
TechRepublic : Disse bekymringene er fornuftige; kunne du kort forklare hva utviklingsteamet kom til for å overvinne hver av bekymringene? Fette : For å advare brukere om at de kan få tilgang til et phishing-nettsted eller et nettsted som inneholder skadelig programvare, kunne vi bruke Safe Browsing-teknologien vår, som allerede driver lignende funksjonalitet i Google Søk, så vel som i Firefox og Safari. Sikker surfing advarer brukere gjennom en mellomliggende side om at nettstedet de skal besøke kanskje ikke er trygt.

For å forhindre at ikke betrodd kode forlater renderer-prosessen implementerte vi det som er kjent som en "sandkasse" rundt rendereren. Dette ekstra sikkerhetsnivået gjør det vanskeligere for en angriper å utnytte kode på datamaskinen din, fordi selv om de finner en sårbarhet i rendereren, sitter de fortsatt fast i sandkassen.

Til slutt, for å sikre at brukerne alltid er oppdatert med den siste versjonen av nettleseren, inkludert å ha de nyeste sikkerhetsoppdateringene, utviklet vi et automatisert system som oppdaterer nettleseren i bakgrunnen uten manuell inngripen.

For å oppfylle målene deres bestemte Chrome-utviklingsteamet seg for å bruke det som kalles flerprosessarkitektur.

Multi-prosess arkitektur

Ved design deler arkitektur med flere prosesser nettleserapplikasjonen inn i komponentprosesser. På denne måten hvis en mislykkes, krasjer ikke hele nettleseren. Chrome er delt inn i følgende prosesser:

  • Nettleser : Denne prosessen administrerer faner, vinduer og "krom" i nettleseren. Denne prosessen har også grensesnitt mot harddisken, nettverket, brukerinndata og skjerm.
  • Innleverer : Denne prosessen er ansvarlig for å vise websider ved hjelp av HTML, JavaScript, CSS og bilder. Inngivere styres av programvare som kalles WebKit-rendering-motoren.
  • Plug-ins : Ved design opprettes det en prosess for hver plug-in eller utvidelse som er i bruk.

Nå, til noen spørsmål om flerprosessarkitektur:

TechRepublic : Hvis jeg forstår riktig, var Google den første som brukte flerprosessarkitektur for nettlesere. Hvordan er Googles implementering forskjellig fra andre nettleserapplikasjoner? Fette : Google tok en ny tilnærming ved å dele opp nettleseren i forskjellige komponenter - nettleseren, gjengivelsen og plug-ins. Da vi lanserte, var vi den eneste store nettleseren med denne tilnærmingen, noe som ga oss en rekke fordeler.

Hvis for eksempel et plugin-program krasjer, forblir siden du ser synlig og forblir lydhør, det er bare den delen av siden som blir gjengitt av plugin-modulen som blir til et "trist" ikon.

Retningslinjene vi har angitt for gjengivelsesprosesser forhindrer ondsinnet kode som kjører i gjengiveren, enten å lese eller skrive fra brukerens filsystem (desktop etc), register og mer. Denne policyen er strengere enn andre nettlesere som sendes i dag, og gjelder også Windows XP, som fortsatt har betydelig markedsandel.

TechRepublic : Jeg husker at jeg ble overrasket over antallet prosesser Chrome kan ha åpnet. Er det en grense for antall nettsteder som kan være åpne samtidig? I så fall hva som skjer etter at grensen er nådd? Fette : Vi begrenser antall prosesser vi vil lage, ikke antallet nettsteder du kan åpne. Vi gjør dette for å oppnå optimal ytelse avveininger, i stor grad basert på mengden minne på systemet ditt (hvis du har mer minne, vil vi begrense antallet prosesser til et høyere antall).

Når du har nådd grensen for antall prosesser, vil nye faner som du åpner dele en gjengivelsesprosess med andre faner. Så hvis du har 20 vinduer åpne med 20 faner hver, for totalt 400 faner, er det mulig at hver gjengivelsesprosess støtter 10 faner hver, i motsetning til å overbelaste datamaskinen din med 400 forskjellige Chrome-prosesser.

Sandkasse i Chrome

Foruten stabilitet gir flere prosessarkitekturer en annen fordel. Ved design er ikke individuelle prosesser avhengige av hverandre og kan isoleres i det Google kaller Chrome sandkasser. Følgende analogi skrevet av Esalkin på Sandboxie-forumet er en fin måte å forklare sandkasseapplikasjoner til de som ikke er kjent med dem:

"Tenk på PCen din som et stykke papir. Hvert program du kjører skriver på papiret. Når du kjører nettleseren din, skriver det på papiret om hvert nettsted du har besøkt. Og all skadelig programvare du støter på vil vanligvis prøve å skrive seg selv inn på avisen.

Tradisjonelt personvern og anti-malware programvare prøver å finne og slette alle skrifter de tror du ikke vil ha på papiret. Det meste av tiden får de det til. Men først må produsentene av disse løsningene lære løsningen hva de skal se etter på papiret og hvordan de kan slettes trygt.

På den annen side fungerer en sandkasse som et gjennomsiktighetslag som er plassert over papiret. Programmer skriver på transparenslaget, og for dem ser det ut som den virkelige papiren. Når du sletter sandkassen, er det som å fjerne gjennomsiktighetslaget, det virkelige papiret er uendret. "

Eksperter, som Charlie Miller, ser bruken av sandkasser som grunnen til at Chrome ikke har blitt utnyttet:

"De har den sandkassemodellen som det er vanskelig å komme seg ut av. Med Chrome er det en kombinasjon av ting, du kan ikke utføre på haugen, OS-beskyttelsen i Windows og sandkassen."

Hvordan Chrome sandkasse fungerer

Husker du gjengivelsene som jeg nevnte tidligere? De er sandkasseprosessene i Chrome. Fordi de er i sandkasser, er de eneste ressursene som gjengivere (faner på websiden) kan bruke CPU-sykluser og minne. Eksempler på hva gjengivere ikke kan gjøre, ville være å skrive til disk eller vise sitt eget vindu. Disse oppgavene styres av nettleserprosessen.

For å oppnå dette bruker Google Chrome sikkerhetsmodellen Windows basert på tilgangstegn. Et tilgangstoken består av informasjon om prosesseieren og privilegiene prosessen har. Etter å ha lest tilgangstoken, vet operativsystemet hvilke ressurser den aktuelle prosessen eller sandkassen har tilgang til. Her er Googles forklaring:

"Før vi starter gjengivelsesprosessen, endrer vi tokenet for å fjerne alle privilegier og deaktivere alle grupper. Vi konverterer deretter tokenet til et begrenset token. Et begrenset token er som et normalt token, men tilgangskontrollene utføres to ganger, første gang med den normale informasjonen på token, og den andre ved hjelp av en sekundær liste over grupper.

Begge tilgangskontrollene må lykkes for ressursene som skal gis til prosessen. Google Chrome angir den sekundære listen over grupper som bare skal inneholde ett element, NULL-brukeren. Siden denne brukeren aldri får tillatelser til noen objekter, mislykkes alle tilgangskontroller som utføres med tilgangstokenet til gjengivelsesprosessen, noe som gjør denne prosessen ubrukelig for en angriper. "

Hvordan dette hjelper

Bruk av sandkasser forhindrer en angriper i å utnytte nettleseren. Ondsinnet kode kan kjøres ved sandkasseprosessen, men skadelig programvare vil ikke kunne lese eller endre filer på datamaskinen. Jeg vendte meg igjen til Ian Fette for å få hjelp til å forstå detaljene.

TechRepublic : Kan du gi noen eksempler fra hva våre datamaskiner blir beskyttet mot ved å bruke Chrome-sandkasser? Fette : Som mange andre nettlesere opprettholder vi en liste over sikkerhetsproblemer som vi har løst. Mange av de oppførte sårbarhetene blir dempet av sandkassen. For eksempel hadde vi et helt talloverflyt i JavaScript-motoren vår, som ikke var for sandkassen, ville tillater en angriper å kjøre vilkårlig kode på datamaskinen din.

På grunn av sandkassen var eksponeringen på grunn av dette sikkerhetsproblemet mye mindre. En angriper ville for eksempel ikke ha kunnet installere skadelig programvare som vil vedvare på datamaskinen din etter at fanen var lukket.

TechRepublic : En kollega ville at jeg skulle spørre om plugins og utvidelser er sandkasset? Fette : utvidelser i Google Chrome er sandboksede, fordi de fungerer akkurat som vanlige nettsteder og er skrevet ved å bruke standard webspråk som HTML, JavaScript og CSS.

Plug-ins er ikke sandkasse akkurat nå, men vi jobber med å bringe dem inn i sandkassen. Den siste kunngjøringen vår om integrering av Adobe Flash i Google Chrome er et stort skritt mot å hjelpe oss med å betjene Flash i sandkassen.

TechRepublic : Med hensyn til Chrome-kasser, har jeg lest at de fungerer annerledes når jeg bruker operativsystemer som er nyere enn Windows XP. Kunne du utdypet det? Er det en fordel å bruke de nyere operativsystemene? Fette : I Vista og senere blir ekstra funksjoner introdusert for å låse ned en prosess, nemlig "integritetsnivåer." Chrome bruker lav integritet på toppen av de normale begrensningene som er brukt av Chrome sandkasse på både XP og Vista.

Selv om dette teoretisk gjør Vista sandboxing-mulighetene sterkere, er vi ikke klar over noen praktiske angrep mot Chrome der dette ville gjort en meningsfull forskjell. Imidlertid gir det et nytt lag med forsvar, og derfor bruker vi integritetsnivåene på Windows-versjoner der de er tilgjengelige, som en forsvar på dybden.

Siste tanker

Jeg er ingen ekspert når det gjelder design av nettlesere, men Charlie Miller er det. Hvis han ikke kan utnytte Chrome, betyr det noe. Jeg har nå en bedre ide om hvorfor han ikke kan takke Googles Ian Fette. Jeg vil også takke Eitan Bencuya fra Google Communications, for at han koblet meg til Ian.

© Copyright 2021 | pepebotifarra.com