- Du er nødt til å deaktivere Java

[ATWindsor]

Kan du nevne noen komplekse SW-produkter (OS, browsere, kontorstøtte, osv.) der det ikke til stadighet oppdages sikkerhetshull?

 

Prøver du å si at java er like sikkert som alle andre komplekse SW-produkt, om ikke, hva er egentlig poenget ditt? Å plukke på semantikk?

 

AtW

[nipsen]

"sikkerhetsselskapet AlienVault Labs, til nyhetsbyrået Reuters."

 

By the way - AlienVault er en liten blogg med dommedagsfanatikere. Som er mest interesserte i å promotere Internet Explorer, Council of Foreign Relations, og selvsagt drive propaganda mot dagens trussel mot Amerikansk hegemoni (og ja, de tror at alt som ikke er laget i USA er en hemmelig konspirasjon for å få has på Amerikanerne).

 

Det som er tilfelle er at du må godkjenne alle kontroller i java som gjør automatiske endringer. Du kan for eksempel ikke kjøre programmer som "tar over" PCen automatisk gjennom en reklameboks. Kontroller og program som er satt opp skikkelig er det ikke noen problem med.

 

Derimot er "problemet" at "en vanlig bruker" med Internet Explorer har muligheten til å klikke "ok" et par ganger, og så permanent godkjenne alle unntak når en bruker java. Og hvis du klikker i vei på "Shåpp Mindreårige Bruder Fra Polen Her!" linkene da, så er det en sjanse for at du havner på en side som inneholder kontroller som kan aksessere filene dine, bruke kamera, lagre og overskrive maler, skrive i filler hosts-filen, osv. Dette har imidlertid ikke med Java "sikkerheten" å gjøre. Men heller med hvor forsvarlig det er å gi retarderte småunger dynamitt å leke med. Eller noe i den duren.

 

Som kjent er jo internett grusomt farlig, og alt det der..

[Gjest Slettet+8713]

Tror nok at denne trojaneren, slikt de tidligere trojanerne, krever visse typer mennesker for å klare å infisere en maskin...

[_dundun_]

Dere får tro hva dere vil.

 

Det har vært hull i både Flash og Java som tillot overtakelse av maskiner uten noen form for interaksjon fra brukerens side. Disse har blitt spredt via legitime sider som har blitt overtatt av kriminelle uten at det har vært merkbart for brukere (kode lagt til men ingen defacing).

[TigerJack]

Og Bank-ID har som vanlig ingenting å si om saken.... Leverandøren av BankID har vel aldri uttalt seg ang. Javas stadige sikkerhetsbrister, og heller ikke denne gangen. De kjører på med sin reklame om at BankID har "høyest sikkerhet".

 

Jeg har et spørsmål. Jeg ønsker å avinstallere hele dritten fra webleseren. Jeg får kun mulighet til å deaktivere. Men jeg vil altså avinstallere hele plugin. Er dette mulig?

[Gjest Slettet+8713]

Dere får tro hva dere vil.

 

Det har vært hull i både Flash og Java som tillot overtakelse av maskiner uten noen form for interaksjon fra brukerens side. Disse har blitt spredt via legitime sider som har blitt overtatt av kriminelle uten at det har vært merkbart for brukere (kode lagt til men ingen defacing).

Er lenge siden man kunne bli infisert uten hjelp fra brukeren. Man må fremdeles på en webside som sender deg videre til en ny side før installasjon av trojaneren. Om denne trojaneren klarer å bryte UAC vet jeg ikke....

[sinnaelgen]

Nå vet ikke hvor mye man har respekt for andre sin bruke av java og innlogging .

Her virker det som respekten er borte

 

i nettbanken til DNB har man 3 muligheter.

innlogging med Java der personnummer , passord og kode fra kodebrikken skal skrives

 

men kan også velge å logge inn uten java , men da må man ha en selvvalgt kode fra før .

den eneste måten å få lagt den inn er når man er innloget.

 

og så er det noen få som faktisk kan bruke bank id via mobilen

 

 

Men hvordan påvirker det innloggingen til Altinn som også kan gjøres med bankid ?

for min del er det enste mulighet til korrigert selvangivelsen elektronisk

 

 

[_dundun_]

Er lenge siden man kunne bli infisert uten hjelp fra brukeren. Man må fremdeles på en webside som sender deg videre til en ny side før installasjon av trojaneren. Om denne trojaneren klarer å bryte UAC vet jeg ikke....

 

Om noen tar kontroll over en nettavis og slenger inn en iframe på 0*0 piksler er første krav oppfylt. Siden java allerede er installert og kjører med gode rettigheter tipper jeg UAC ikke er noe hinder.

 

Det er ingen grunn til panikk, men det er dumt å være altfor avslappet også.

Endret 11. januar 2013 av kvasbo

[TheKims]

Nå vet ikke hvor mye man har respekt for andre sin bruke av java og innlogging .

Her virker det som respekten er borte

 

i nettbanken til DNB har man 3 muligheter.

innlogging med Java der personnummer , passord og kode fra kodebrikken skal skrives

 

men kan også velge å logge inn uten java , men da må man ha en selvvalgt kode fra før .

den eneste måten å få lagt den inn er når man er innloget.

 

og så er det noen få som faktisk kan bruke bank id via mobilen

 

 

Men hvordan påvirker det innloggingen til Altinn som også kan gjøres med bankid ?

for min del er det enste mulighet til korrigert selvangivelsen elektronisk

elgen er et husdyr- noen som vet hvorfor ? Hvorfor?

Endret 11. januar 2013 av Kim Spartacus

[Gjest Slettet+8713]

Om noen tar kontroll over en nettavis og slenger inn en iframe på 0*0 piksler er første krav oppfylt. Siden java allerede er installert og kjører med gode rettigheter tipper jeg UAC ikke er noe hinder.

 

Det er ingen grunn til panikk, men det er dumt å være altfor avslappet også.

 

Problemet jeg ser nå, er de tusener av personer med minimale kunnskaper om datamaskinen sin nå skal deaktivere Java. Gud hjelpe meg for et kaos det skal bli hvis de bare sletter alt som de tror er Java. Kanskje noen antivirusløsninger går fløyten også, men det er vel mindre viktig....

[sinnaelgen]

elgen er et husdyr- noen som vet hvorfor ? Hvorfor?

 

Å. du ner at alle som ikke klarer seg uten Java er noen tosker ?

eller så forstår jeg ikke hva du vil frem til

[elf_man]

Om noen tar kontroll over en nettavis og slenger inn en iframe på 0*0 piksler er første krav oppfylt. Siden java allerede er installert og kjører med gode rettigheter tipper jeg UAC ikke er noe hinder.

 

Det er ingen grunn til panikk, men det er dumt å være altfor avslappet også.

 

Det blir jo litt som å si at hvis en tyv klarer å deaktivere alarmen til huset ditt, så kan han stjele fra deg med mindre du er hjemme. Er det en problemstilling som holder folk våkne om nettene? Det er komplett umulig å sikre seg helt.

[_dundun_]

Det blir jo litt som å si at hvis en tyv klarer å deaktivere alarmen til huset ditt, så kan han stjele fra deg med mindre du er hjemme. Er det en problemstilling som holder folk våkne om nettene? Det er komplett umulig å sikre seg helt.

 

Mer som at noen plutselig kunne bruke ringeklokka di til å slå av alarmen din og låse opp døra di uten at du merka noe. Da hadde jeg vurdert å deaktivere ringeklokka for sikkerhets skyld.

[Abigor]

Hvorfor MÅ nettbanker bruke java? Det er to tekstbokser det skal sendes noen tegn fra. Verdens enkleste oppgave. Verdens mest kompliserte løsning.

[Frobe]

Etter å ha lest denne nyheten har jeg brent dataen min, fylt opp med hermetikk, hermelin og hermegåser og selv er jeg barikadert i bomberommet.Fra spøk til alvor; hvor alvorlig er nå dette? Enkelt og greit; får jeg virus gjennom DB, VG og Facebook? Nettbanken er jeg inne på 5 ganger i året.

 

Jeg fikk et virus/trojaner via Java i 2012 etter å ha surfet på Teknisk Ukeblad (www.tu.no), heldigvis oppdaget antivirusen dette og jeg fikk fjernet det.

http://www.tu.no/it/2012/08/30/tu.no-ble-angrepet

 

Bruker man PayPal eller VISA-kort til å betale på nettet kan pengene forsvinne hvis man har en trojaner. Noen vil sikkert også mislike hvis man mister kontrollen på personlig mailkonto/Facebook eller bilder som ligger på maskinen. Det finnes også noen utpressingsvirus som krypterer/ødelegger filene på harddisken, ikke kjekt hvis man har glemt backup...

Endret 12. januar 2013 av Frobe

[mrs.robinson]

Kanskje på tide å få den helvetes BankID-pisset vekk fra java, i hvert fall tilby en html5-løsning for oss oppdaterte.

 

 

Er det ikke et litt for stort hylekor nå?

Java kan settes til å kun brukes på godkjente sider. Feks nettbank, etc.

Du kan jo også bruke tredjepartsløsninger som no-script for å øke den generelle sikkerheten.

 

Det er vel ikke slik at BankID er kompromittert. Bristen som er påvist er i Java. BankID virker fortsatt. Hva med å kjøre en vm med Java kun for BankID?

 

Det er da mange måter å løse dette på uten å hverken bli religiøs eller hysterisk.

[efikkan]

Det er tydelig at artikkelforfatter ikke har forstått saken her og bare serverer mediehysteriet videre.

 

Java er et programmeringsspråk som kan brukes til alt fra å håndtere nettstatistikk til store sikkerhetssystemer for nettbanker. Det inkluderer en rekke funksjoner som gjør det meget enkelt og attraktivt for løsninger på Internett.

Java er riktignok et programmeringsspråk, men det er ikke programmeringsspråket saken handler om i det hele tatt. Det dreier seg om Oracles Java Runtime Enviorment, som tillater kjøring av Java-programvare. Samme hvor sterkt jeg misliker(hater) programmeringsspråket Java så omhandler ikke denne saken sårbarheter i selve programmeringsspråket.

 

– Java er et eneste stort rot. Det er ikke sikkert, du er nødt til å deaktivere det, sier Jaime Blasco, tekniker hos sikkerhetsselskapet AlienVault Labs, til nyhetsbyrået Reuters.

Det er sant nok at Java-biblioteker er et ekstremt stort rot som ingen har oversikt over, men utsagnet er likevel ikke korrekt.

 

Brukerne er i fare uansett hvilket operativsystem de bruker, om det så er Windows, Mac eller Linux.

Brukere på alle maskiner som kjører Java Runtime Environment kan bli rammet ja, men alvorlighetsgraden varierer svært mye!

I utgangspunktet skal Java applets kun leve i user space, men det er visse ting dere må være klar over:

Windows: brukerprivilegier er ikke ordentlig implementert på kjernenivå så det er mulig å eskalere privilegier og gjøre mer skade, installere rootkits, keylogging osv.

OS X: siden OS X er basert på BSD er user space i utgangspunktet godt isolert, men Apple har gjort en gedigen designtabbe som gjør at brukerpassord lett kan dekrypteres(!), og dermed kan eskalere privilegier.

Linux: så lenge det ikke er en separat bug i Linux vil en applet aldri klare å bevege seg utenfor user space, men de fleste distribusjoner bruker ekstra sandboxing gjennom løsninger som selinux og apparmor som ytterligere begrenser eventuelt skadeomfang. Applets vil ikke være i stand til å installere eventuelle rootkits eller keyloggers.

 

Uavhengig av operativsystem så er det én enkel løsning på hele problemet; kun kjøre Java Runtime Environment, Flash og annen dritt i virtualbox.

 

Man må vel ha Java for å kjøre Minecraft også? Pokker!

Så lenge du har lastet ned Minecraft sin applet og kjører den lokalt og har JRE deaktivert i alle nettleser så er det ingen problemer

 

Når man bruker nettbankenes løsning for pålogging med kodebrikke + eget passord så starter en java-boks, men hvodan er det med de andre metodene for pålogging som sms-kode tilsendt?

Gå over til BankID på mobil, og boikott alle banker som ikke har det! DNB og Skandiabanken vet jeg har det i hvert fall. Bytt bank i dag!

GSM er lett å avlytte og avskjære for de som befinner seg i nærheten. Jeg har store vansker for å se hvordan en kode mottatt på SMS kan bidra til å øke sikkerheten kontra en kodebrikke/token.

 

Men problemet med Java har ingenting med BankID å gjøre heller. Problemeet har vært at tilfeldige sider kan hijacke maskinen din. BankID er irrelevant. Grunnen til at folk klager over BankID er at det er det eneste programmet de fleste bruker i nettleseren som benytter seg av Java.

Du er inne på noe Geir, problemene og svakhetene med BankID er egentlig separat fra JRE sine problemer. Men problemet med at folk har JRE aktivert for banken sin er ikke at de skal bli svindlet på banken sine sider, men at de skal ved et uhell kjøre en applet fra en tilfeldig annen side de streifer forbi.

 

 

bare godkjenn java hos websider du stoler på da...

Trenger jo java til mange helt essensielle programmer/applikasjoner.

Enkelte nettlesere gir ikke advarsler ved kjøring av applets. I tillegg trykker mange ukritisk godkjenn, hvis det f.eks. er et tillegg på Facebook som de fikk fra en venn. Men med all problematikken med Java applets så foreslår jeg bare å kutte de helt ut, for jeg ser ingen grunn til at vi trenger de, vi kan løse alt vi trenger med alternative metoder. Dermed kan vi gjøre det idiotsikkert!

 

-----

 

Men JRE har en annen kjempesvakhet som skyldes en designtabbe av utviklere som ikke forstår sikkerhet: selv-signering av Java applets. Hensikten med signaturer er å kunne verifisere at appleten er fra den utgiveren som står oppgitt og at appleten er uendret. Men hele poenget forsvinner når der ikke er noen innebygd mekanisme for å verifisere signaturer, så dette må brukeren manuelt gjøre når de møter en applet som utgir seg for å være fra "Facebook Inc.", "Google", "Fokus Bank" osv. Hvem som helst kan lage sine egne signaturer med det navnet de selv måtte ønske, og siden det ikke finnes noen oversikt over gyldige signaturer så er det umulig for brukeren å vite hva som er ekte selv om brukeren kan grave frem signaturen (som er godt gjemt).

 

-----

 

Angående BankID:

Som nevnt er problemene med BankID egentlig ikke knyttet til JRE, men jeg vil gjøre noen poenger:

- Hva skal vi med en applet for BankID? Før BankID hadde norske banker akkurat samme funksjonalitet gjennom HTTPS med SSL. Den eneste "hensikten" jeg kan se ved å velge Java applet er å få kontroll på sikkerheten, siden noen eldre nettlesere (*host* IE #kremt*) støtter bare utrygge varianter av SSL. Problemer er bare at valget av applets introduserer en hel ny rekke av mulige sikkerhetshull, og at nå både nettleseren og JRE må være fri for sikkerhetshull. Pga. problemet over med selvsignering kan du også risikere at noen gir deg en falsk BankID-applet, i motsetning til HTTPS der sertifikatmyndigheter vil forsikre deg om at du er på riktig side og at du ikke sender sensitiv informasjon til gale hender.

- Sikkerheten til kodebrikken/token kan i seg selv stilles store spørsmål ved. Da BankID fremdeles var ferskt kom det påstander om at kodebrikkene var knekt(skal se om jeg finner kilden). Siden jeg vet om tilfeller der folk med uhell har brukt feil kodebrikke og fremdeles blitt autorisert, så sier det meg at algoritmen inne i brikkene ikke kan være så veldig avansert. Hele sikkerheten står og feller på at brukeren skal få en kode fra brikken som skal være umulig å forutsi for en tredjepart. Jeg vet at algoritmen har ingen tilknytning til pin-koden på kodebrikken, siden banken aldri får vite pin-koden du setter på brikken. Kodebrikken blir heller aldri synkronisert med tidsserver, så klokken internt må bli ganske feil over mange år. Siden det fremdeles er ingen problemer å logge inn sier det meg at svært mange koder vil være gyldige til enhver tid. Og siden disse brikkene er billige og masseproduserte, så har mest sannsynlig svært mange brukere identiske brikker. En bedre måte å løse dette på vil være slik som GPG fungerer. Da kunne bankene kvittet seg med de private nøklene og kun beholdt nøklene for verifisering, så et eventuelt datainnbrudd hos banken ville ikke gitt tilgang til andres kodebrikker. Problemet med dette er kostnaden av å konfigurere slike brikker manuelt.

[MrLee]

Jepp, den tar seg av alle nettlesere i en vending, artikkelen burde vel bli oppdatert til å få med seg denne fremgangsmåten.

 

I chrome er det vel bare å deaktivere java via "About:plugins"?

 

Fine med den metoden er at hvis du er inne på nettbanken og prøver å logge deg inn, så får du melding om at java ikke er aktiv, med link rett til about:plugins som åpner i en ny fane. Enable java via den, så laster bankid direkte.

 

Så er det bare å slå av java igjen via about:plugins fanen igjen når man er ferdig i nettbanken.

 

Eller er det sikkerhestsproblemer ved å la nettleseren håndtere om java er på eller ei?

 

Se bort ifra bruk av andre browsere, Det skjer bare ikke på min maskin

[Frobe]

Er det ikke et litt for stort hylekor nå?

Java kan settes til å kun brukes på godkjente sider. Feks nettbank, etc.

Du kan jo også bruke tredjepartsløsninger som no-script for å øke den generelle sikkerheten.

 

Det er vel ikke slik at BankID er kompromittert. Bristen som er påvist er i Java. BankID virker fortsatt. Hva med å kjøre en vm med Java kun for BankID?

 

Det er da mange måter å løse dette på uten å hverken bli religiøs eller hysterisk.

 

Tror du alle mødrene og besteforeldrene klarer å løse dette på en trygg måte? De har problemer nok å avgjøre om de skal svare ja eller nei på spørsmål om å oppgradere Java.

[_dundun_]

Kodebrikken blir heller aldri synkronisert med tidsserver, så klokken internt må bli ganske feil over mange år. Siden det fremdeles er ingen problemer å logge inn sier det meg at svært mange koder vil være gyldige til enhver tid. Og siden disse brikkene er billige og masseproduserte, så har mest sannsynlig svært mange brukere identiske brikker.

 

Litt off topic, men jeg tror du tar feil her. Det er ikke mulig å synce brikken med tidsserver, men det er problemfritt å synce tidsserver mot brikken.

 

"Brukeren sender inn kode 12345678, skal vi se, da er brikken hans tydeligvis to timer bak min systemklokke. Det vil si at hans neste kode skal være 87654321, la oss sende ham en 'sorry, feil kode' og se om neste er rett, og om den er det kan vi sette offset for denne brukeren til to timer sånn at neste pålogging går fint med en gang". Eventuelt "heisann, brukeren ligger to koder bak ventet, jaja, vi setter offset!".

 

Med lange nok koder er sikkerhetsrisikoen ved å godta et par koder foran og bak den korrekte ikke et problem.

 

Sånn ville iallfall jeg designet det, og jeg jobber med å designe sånt.

 

Tror du alle mødrene og besteforeldrene klarer å løse dette på en trygg måte? De har problemer nok å avgjøre om de skal svare ja eller nei på spørsmål om å oppgradere Java.

Dette er poenget. Vi her inne får til alle mulige lure hacks og løsninger. Det er irrelevant, problemet er med alle brukerne som ikke får til sånt. Det er de som er de egentlige brukerne, vi er et bittelite mindretall.

Endret 11. januar 2013 av kvasbo