Venter stort angrep fra mengder av rutere og NAS-enheter

[Harald Brombach (digi.no)]

Over en halv million enheter skal være infisert.

Venter stort angrep fra mengder av rutere og NAS-enheter

[Per Buer]

Det er vel på tide å innrømme at Linux som operativsystem på noe annet enn server og desktop ikke akkurat har vært en strålende suksess med tanke på sikkerhet. Det er neppe siste gang vi ser store mender linux-baserte systemer bli kompromittert.

[G]

Skremmende at produsentene av utstyret ikke er flinkere til å lappe enheter.

[Per Buer]

Skremmende at produsentene av utstyret ikke er flinkere til å lappe enheter.

Det er egentlig en naturlig følge av at systemer som shipper med Linux som OS er fundamentalt rekonfigurerbare. Hvis du ser på mikrokontroller-baserte systemer som har et nedlåst "image" som de booter fra så legger du merke til at sikkerhetsfeilene er bemerkelsesverdig få.

 

Det er egentlig ingen naturlig grunn til at en wifi-ruter skal i det hele tatt ha muligheten til å la en innlogget bruker installere ny programvare på den eller i det hele tatt logge inn på den med et shell.

[bojangles]

Det er vel på tide å innrømme at Linux som operativsystem på noe annet enn server og desktop ikke akkurat har vært en strålende suksess med tanke på sikkerhet. Det er neppe siste gang vi ser store mender linux-baserte systemer bli kompromittert.

 

Dette handler vel ikke on Linux per se? Selv om Linux brukes i bunn i disse så er det jo ikke slik at det er kjernen som er kompromittert. Å ikke endre un/pwd er en brukerfeil mer enn noe annet. Sikkerheten kunne jo vært strammet inn mer om disse ble levert med et image som var totalt låst, men da hadde man mistet mye av brukervennligheten, en kunne ikke valgt annen firmware for å få utvidet funksjonalitet og mange av kjøperne ville nok da snudd ryggen til produktet. 

 

Hvor lenge har tomato og open wrt og disse vært aktive. 20 års tid nå?  

[Gjest Slettet-Pqy3rC]

Note;

VPNFilter har vært fjerna på QNAP enheter siden 2017. Men, om folk aldri oppdaterer utstyret sitt så...

Det er også lagt ut en fix for de som ikke har oppdateringer av selve OS'et (QTS) lenger (dvs. gammel hardware) etc. Les her.

 

Vedr. NAS generelt; VPNFilter gjelder bare om NAS'et er eksponert ut mot internett. Ingen kan nå noe bak en brannvegg el.lign. Routere er litt værre, de er jo nesten alltid eksponert.

Endret 24. mai 2018 av Slettet-Pqy3rC

[Gjest Slettet-Pqy3rC]

Hvor lenge har tomato og open wrt og disse vært aktive. 20 års tid nå?

Tja.. eller bare gå for noe freeBSD kompatibelt utstyr slik at kan bruke pfSense. Aldri til dags dato sett noen som har rokka ved freeBSD's pf (med unntak av haertbleed som gikk via openSSL koden, hvilket ikke egentilig er den av freebsd).

[Per Buer]

 

Det er vel på tide å innrømme at Linux som operativsystem på noe annet enn server og desktop ikke akkurat har vært en strålende suksess med tanke på sikkerhet. Det er neppe siste gang vi ser store mender linux-baserte systemer bli kompromittert.

 

Dette handler vel ikke on Linux per se?

 

Jo. Det gjør det. Linux eller mer spesifikt Unix er ikke egnet for slike oppgaver. Jeg vil at ruteren min skal være en "appliance". Den skal gjøre det den skal gjøre og ingenting annet. Jeg skal ikke kunne installere bitcoin-minere eller tilsvarende på den. Denne fundamentale reconfigurerbarheten til Unix er flott på servere men helt feil på appliances.

Selv om Linux brukes i bunn i disse så er det jo ikke slik at det er kjernen som er kompromittert.

Jeg bruker det folkelige Linux om det jeg sikkert burde kalle GNU/Linux. Altså Linux med userspace.

Hvor lenge har tomato og open wrt og disse vært aktive. 20 års tid nå?

Jeg ser ikke relevansen.

[G]

Har en grei nok gammel router. Men han her droppet nylig støtten for den. Litt trist i grunn:

 

https://github.com/RMerl/asuswrt-merlin/wiki

 

Men kommer nok selv til å bli sittende litt på router-gjerdet, da den gamle routeren har 2018-oppdatering fra "merlin", og det fungerer ganske godt. Men hadde vært greit å hatt en ny router med entusiast-firmware på. Men, nå har det vært så mye sårbarheter og det er nye WiFi-standarder på trappene. Er fint her oppå gjerdet enn så lenge.

Endret 24. mai 2018 av G

[1P4XZQB7]

 

Dette handler vel ikke on Linux per se?

Jo. Det gjør det. Linux eller mer spesifikt Unix er ikke egnet for slike oppgaver.

 

 

La oss bare være enige om å være steilt uenige…

 

( BTW, U*IX er et langt mer generelt begrep som Linux. For jeg antar du mente vise til gruppebetegnelsen U*IX og ikke UNIX® spesifikt? )

Endret 25. mai 2018 av 1P4XZQB7

[Sandormen]

 

 

Dette handler vel ikke on Linux per se?

Jo. Det gjør det. Linux eller mer spesifikt Unix er ikke egnet for slike oppgaver.

 

La oss bare være enige om å være steilt uenige…

At Per Buer mener at rutere ikke skal være konfigurerbare får meg bare til å riste på hodet.

[Per Buer]

La oss bare være enige om å være steilt uenige…

( Btw, U*IX er langt mer generelt begrep som Linux. For jeg antar du mente vise til gruppebetegnelsen U*IX, og ikke UNIX® spesifikt? )

Jeg mener traditionelle POSIX-systemer med tradisjonell Unix-basert eller Unix-klonet kjerne og tradisjonelt System V eller BSD userspace. Alt med egen OS-kjerne og kommandolinje, egentlig. Jeg er forøvrig stor fan av Linux og til tider også kjørt mye FreeBSD. Så OSene er tipp topp - men hvert til sitt bruk.

 

For å klargjøre litt; Unix sitt design er ikke riktig for embedded. Og det var aldri meningen at det skulle kjøre på slike systemer heller. Multics og senere Unix var designet på å kjøre på DEC PDP11 og skulle oppfylle en bestemt rekke krav hvordan ingen er spesielt relevante for en wifi-ruter.

 

En faktor er jo den enorme angrepsoverflaten som disse systemene har. Det er ikke tilfeldig Linux på embedded blir cracket igjen og igjen og igjen. Det samme skjer ikke på MCU-baserte systemer. De gir overhodet ikke den samme friheten og er mindre fleksible å utvikle på - men det betaler seg mange ganger over ved at systemene kan stå overvis uten oppdateringer uten at noen greier å misbruke dem.

 

Men hva med Unix-designet er det som gjør at du mener at det er egnet for embedded? Nå skal jeg muligens bruke de neste to årene på å forsøke å bevise denne tesen så jeg hadde faktisk satt pris på å høre hva det er som gjør Linux (evt. Unix) så utrolig godt egnet til et system som rent funksjonelt ikke trenger brukere eller prosesser.

[Per Buer]

At Per Buer mener at rutere ikke skal være konfigurerbare får meg bare til å riste på hodet.

Du fikk åpenbart ikke med deg poenget. Så la meg ta det litt med detaljert. Du har garantert et titalls MCU-baserte systemer i livet ditt. De fleste av dem er konfigurerbare systemer. Men du kan ikke logge inn på dem (ikke noe shell) og ikke installere ny programvare på dem. De booter et image og de har konfigurasjon (SSID, ruting-tabell, etc), naturlig nok. Men hvorfor i alle dager skal jeg ha behov for å logge inn på et IP-kamera, en wifi-ruter og installere programvare vilkårlig programvare på dem? For det er situasjonen idag og det er titalls millioner av systemer som pga av denne fleksibiliteten er blitt kompromittert.

 

En wifi-ruter burde ha fullstendig nedlåst firmware, kryptografisk signert fra produsent og oppdatert OTA. Så kan de som har kompetanse og viljen til å dille med fortsette å kjøpe seg OpenWRT-baserte rutere slik at de kan gjøre hva de vil med dem. Men 99% av befolkning vil ikke ha slikt og burde få slippe å ha slike systemer.

[NgZ]

At Per Buer mener at rutere ikke skal være konfigurerbare får meg bare til å riste på hode

Du fikk åpenbart ikke med deg poenget. Så la meg ta det litt med detaljert. Du har garantert et titalls MCU-baserte systemer i livet ditt. De fleste av dem er konfigurerbare systemer. Men du kan ikke logge inn på dem (ikke noe shell) og ikke installere ny programvare på dem. De booter et image og de har konfigurasjon (SSID, ruting-tabell, etc), naturlig nok. Men hvorfor i alle dager skal jeg ha behov for å logge inn på et IP-kamera, en wifi-ruter og installere programvare vilkårlig programvare på dem? For det er situasjonen idag og det er titalls millioner av systemer som pga av denne fleksibiliteten er blitt kompromittert.

 

En wifi-ruter burde ha fullstendig nedlåst firmware, kryptografisk signert fra produsent og oppdatert OTA. Så kan de som har kompetanse og viljen til å dille med fortsette å kjøpe seg OpenWRT-baserte rutere slik at de kan gjøre hva de vil med dem. Men 99% av befolkning vil ikke ha slikt og burde få slippe å ha slike systemer.

 

men det du sier her henger jo åpenbart ikke på greip. Sandormen påpeker, som 100% riktig er, at de fleste vil ha konfigurerbare enheter. De vil f.eks. velge navn og passord på sitt eget trådløse nettverk. Det har ingen ting med å installere vilkårlig programvare på den å gjøre. I tillegg ønsker stadig flere mer av dingsene sine - blant annet at de snakker sammen. Og siden det ikke er mulig å legge inn all verdens i de små  flashminnene rutere utstyres med, fordrer ulik funksjonalitet at den kan installeres etter behov og ønske.

 

Stadig flere har også raske fiberlinjer, og jeg kjenenr flere ikke-tekniske brukere som elsker å koble seg til VPN når de er ute å reise, både for å kunne se norsk innhold fra f.eks. NRK, eller skremme samboer med å spille av lyd på anlegget hjemme... De fleste av disse ønsket riktignok ikke den muligheten før de oppdaget at ruteren de hadde kjøpt hadde funksjonaliteten, leste om det i en test, ble fortalt om det av en litt mer teknisk anlagt kompis e.l.

 

Kostnaden ved systemet du skisserer hadde selvfølgelig også vært enorm, og krevd utrolig mye egenskrevet kode, som ville vært full av hull. Det er en grunn til å gå for kode som er mye brukt og standardisert - den er stort sett mye sikrere enn noe man raskt kunne slengt sammen selv. IP-kameraene du nevner er et godt eksempel på dette - de billige kinesiske kjører ofte dårlige, hjemmesnekrede løsninger (om enn med noe bruk av kjente biblioteker), du MANGLER funksjonaliteten du beskriver, og er likevel oftest de med problemer, som ikke kan fikses, fordi nødvendige oppdtaeringer ikke er mulige, eller tilgjengelige. Manglende oppdateringer til/av lukkede enheter og miljøer vil alltid være en større sikkerhetstrussel enn noe så elementært som å tilby plugins i internetttilkoblede produkter der du ikke aner hva du vil ønske å koble til neste år. Automatiske OTA-oppdateringer hadde imidlertid vært en god idé, og at disse er signerte er vel allerede normalen.

[Per Buer]

men det du sier her henger jo åpenbart ikke på greip. Sandormen påpeker, som 100% riktig er, at de fleste vil ha konfigurerbare enheter. De vil f.eks. velge navn og passord på sitt eget trådløse nettverk. Det har ingen ting med å installere vilkårlig programvare på den å gjøre. I tillegg ønsker stadig flere mer av dingsene sine - blant annet at de snakker sammen. Og siden det ikke er mulig å legge inn all verdens i de små  flashminnene rutere utstyres med, fordrer ulik funksjonalitet at den kan installeres etter behov og ønske.

 

Stadig flere har også raske fiberlinjer, og jeg kjenenr flere ikke-tekniske brukere som elsker å koble seg til VPN når de er ute å reise, både for å kunne se norsk innhold fra f.eks. NRK, eller skremme samboer med å spille av lyd på anlegget hjemme... De fleste av disse ønsket riktignok ikke den muligheten før de oppdaget at ruteren de hadde kjøpt hadde funksjonaliteten, leste om det i en test, ble fortalt om det av en litt mer teknisk anlagt kompis e.l.

 

Kostnaden ved systemet du skisserer hadde selvfølgelig også vært enorm, og krevd utrolig mye egenskrevet kode, som ville vært full av hull. Det er en grunn til å gå for kode som er mye brukt og standardisert - den er stort sett mye sikrere enn noe man raskt kunne slengt sammen selv. IP-kameraene du nevner er et godt eksempel på dette - de billige kinesiske kjører ofte dårlige, hjemmesnekrede løsninger (om enn med noe bruk av kjente biblioteker), du MANGLER funksjonaliteten du beskriver, og er likevel oftest de med problemer, som ikke kan fikses, fordi nødvendige oppdtaeringer ikke er mulige, eller tilgjengelige. Manglende oppdateringer til/av lukkede enheter og miljøer vil alltid være en større sikkerhetstrussel enn noe så elementært som å tilby plugins i internetttilkoblede produkter der du ikke aner hva du vil ønske å koble til neste år. Automatiske OTA-oppdateringer hadde imidlertid vært en god idé, og at disse er signerte er vel allerede normalen.

Jeg burde sikkert vært tydeligere men hva jeg mener med konfigurasjon. Selvsagt skal en wifi-ruter ha konfigurasjon, hvis ikke blir den ubrukelig. Begrepet konfigurasjon er uklart det jeg mener med at Linux er for konfigurerbar er muligheten Linux har til å fundamentalt endre måten enheten fungerer på. Det er dette jeg vil ha bort - og det lar seg i liten grad gjøre uten å gå bort fra arkitekturen med en Linux-kjerne og matchende user-space.

 

Min wifi-ruter skal rute pakker. Det er alt den gjør og jeg vil ikke at den skal kunne gjøre noe mer. Den skal ikke mine bitcoin, servere torrents eller bli en del av et botnet. Den kan gjerne ha VPN-funksjonalitet hvis det er noe leverandøren leverer - men om den ikke har det er det heller ikke noe jeg vil at jeg som bruker skal kunne legge til ved å installere binærer som endrer enhetens funksjonalitet.

 

Alt av biblioteker som finnes kan selvsagt fortsette å fungere. De fleste bibliotek krever litt POSIX men de er stort sett skrevet slik at de fint kan kjøre uten en Linux-kjerne. De må bare statisk lenkes inn fremfor dynamisk.

 

Dette trenger ikke være noe dyrere og mer komplekst enn et Linux-basert system. Snarere tvert om. Linux, som en "runtime" er veldig kompleks og krever mengder av minne og lagring bare for å kunne starte. Og 99% av funksjonaliteten dette systemet tilbyr er ikke relevant for wifi-rutere - men øker angrepsflaten uten å tilføre verdi.

 

Linux-kit er et prosjekt som forsøker å adressere dette ved å forsøke å krympe Linux. Men jeg mener altså at dette ikke er ambisiøst nok. Grunnproblemet er der fortsatt og Linux-baserte systemer er rimelig lette å angripe hvis du finner en bug fordi systemkallene i bunn er statiske - noe som gjør det enkelt å skrive shellcode som modifiserer systemet. Enkle enheter som wifi-rutere burde funksjonelt kunne gjøre alt det en wifi-ruter forventes å gjøre uten en Linux-kjerne. Brukere og prosesser er ikke nødvendig.

 

Jeg håper å kunne vise frem noe slikt i slutten av 2019, kanskje kjørende på rPi eller noe lignende. Et aksesspunkt laget på 100% OSS - men uten tradisjonelt Unix userspace.

 

Uavhengig av arkitektur er dette selvsagt avhengig av at leverandøren greier å levere noe som faktisk fungerer. Men ideen min er at vi ved å gå bort fra Unix kan lage et langt mer sikkert system.

[1P4XZQB7]

For å klargjøre litt; Unix sitt design er ikke riktig for embedded. Og det var aldri meningen at det skulle kjøre på slike systemer heller. Multics og senere Unix var designet på å kjøre på DEC PDP11 og skulle oppfylle en bestemt rekke krav hvordan ingen er spesielt relevante for en wifi-ruter.

 

En faktor er jo den enorme angrepsoverflaten som disse systemene har. Det er ikke tilfeldig Linux på embedded blir cracket igjen og igjen og igjen.

Tror jeg ser problemet. Du lever i en lett utdatert villfarelse om hva innebygde systemer (embedded) er for noe per i dag. Nå har jeg personlig faktisk fått prøvd meg på å laste opp instruksjoner på minimaskin i klasse med PDP-8 sitt frontpanel. Riktignok en god stund etter at disse maskinene var stuet bort, men erfaring lot meg forstå hvordan konkurranser av typen korteste bootstrap kode dukket opp.

 

Innebygde systemer har alltid vært mer begrenset i sine ressurser. Det store spørsmålet er i forhold til hva.

 

Når Apple i dag kan kjøre iOS på en klokke, så er det rimelig åpenbart at det meste av innebygget maskinvare ikke lenger sliter med å dra rundt en U*IX kjerne eller tilsvarende. Og jeg velger nevne Apple av en grunn. Tidspunktet for Steve Jobs sin lansering av iPad var ikke tilfeldig. Det var på denne tiden innebygget maskinvare generelt ble tilstrekkelig kraftig for den tilgjengelige batterikapasitet. Apple prøvde seg mye tidligere med sin Newton, et produkt som var for tidlig ute og feilet miserabelt. M$ prøvde seg med sine PDA'er, med heller begrenset suksess – de fikk solgt til offer som ikke hadde noe valg. Dette var under det altomsluttende M$ monopolet.

 

Nei, det hele kom på gli med ARM7TDMI, men tok først av med ARM Cortex. Forskjellen på Cortex Mx og Ax serien er strømforbruket, i praksis tilstedeværelsen av MMU eller ikke. Imidlertid er det slik at et Gigabit Ethernet interface gjerne bruker mer strøm som hva en full Cortex-A prosessor trenger. Så for dagens rutere gir det ikke mening å designe inn noe annet som en full Cortex-Ax, gjerne med ytterligere hardware trafikkakseleratorer ved siden av. Faktisk benyttes der flere Cortex kontrollere, en for hvert grensesnitt.

 

Regnekraften som kreves for å flytte og filtrere Gigabit datapakker langt overskrider i alle tilfelle kravet for å dra rundt fullt GNU/Linux med userland tjenester. De samme tjenestene flere med meg faktisk etterspør.

 

Markedet for 8-bit mikrokontrollere er blitt fullstendig overkjørt. Den 32 bit brede ARM Cortex kjernen er fysisk på samme størrelse som disse, og gjennom Thumb-2 er også kodetettheten sammenlignbar. Der er bare ikke lenger noen god grunn til ikke å benytte en ARM kjerne. Eller MIPS / PowerPC, selv om disse nå er blitt for mer spesielt interesserte. Prisen på (innebygget) minne av alle typer er også nå på det punkt at omtrent alt som selges kan lagre unna et nedskrellet GNU/Linux system. Der er fortsatt unntak fra regelen, og det er system med krav til responstid (RTOS) samt system med krav til Function Safety. Sistnevnte benytter da gjerne Cortex-R i stedet. 

 

Et grelt eksempel på hvor maskinvaren befinner seg for tiden er STM32H7xx. Denne prosessoren kan fint dra rundt GNU/Linux kjerne (dog uten MMU) og userland med masse krefter i reserve. Utviklingskortet NUCLEO-H743ZI  inklusive JTAG debugger, USB og Ethernet koster kr 193,31 pluss MVA. 

 

Dernest har vi leveregel nummer en fra kryptografien – IKKE skriv din egen algoritme, den kommer til å feile. Det samme gjelder egentlig operativsystem og userland. Security by Obscurity feiler langt oftere som Linux tjenester gjør. Innen jeg (og alle andre) er ferdig med å skrive eget operativsystem med de samme tjenestene som Linux Userland tilbyr, så vil resultatet se ut som en sveitserost. Ibakt spagetti for å håndtere alle unntakene. Som demonstrert ved at også Intel går på trynet i sikkerhetsarbeidet, helt nede på maskinvarenivå. Der er alltid en ny angrepsvinkel. 

Endret 25. mai 2018 av 1P4XZQB7

[Per Buer]

Innebygde systemer har alltid vært mer begrenset i sine ressurser. Det store spørsmålet er i forhold til hva.

 

Når Apple i dag kan kjøre iOS på en klokke, så er det rimelig åpenbart at det meste av innebygget maskinvare ikke lenger sliter med å dra rundt en U*IX kjerne eller tilsvarende. Og jeg velger nevne Apple av en grunn. Tidspunktet for Steve Jobs sin lansering av iPad var ikke tilfeldig. Det var på denne tiden innebygget maskinvare generelt ble tilstrekkelig kraftig for den tilgjengelige batterikapasitet. Apple prøvde seg mye tidligere med sin Newton, et produkt som var for tidlig ute og feilet miserabelt. M$ prøvde seg med sine PDA'er, med heller begrenset suksess – de fikk solgt til offer som ikke hadde noe valg. Dette var under det altomsluttende M$ monopolet.

Helt enig. Klokka til Apple er dog perfekt med et Unix-basert system. Den trenger å ha mange forskjellige prosesser og hvis ikke brukeren kan installere applikasjoner på den så er den ubrukelig. Her gjør Unix-designet jobben på en god måte. Samme gjelder TV'er, telefoner og andre enheter som skal være veldig, veldig åpne.

 

Nei, det hele kom på gli med ARM7TDMI, men tok først av med ARM Cortex. Forskjellen på Cortex Mx og Ax serien er strømforbruket, i praksis tilstedeværelsen av MMU eller ikke. Imidlertid er det slik at et Gigabit Ethernet interface gjerne bruker mer strøm som hva en full Cortex-A prosessor trenger. Så for dagens rutere gir det ikke mening å designe inn noe annet som en full Cortex-Ax, gjerne med ytterligere hardware trafikkakseleratorer ved siden av. Faktisk benyttes der flere Cortex kontrollere, en for hvert grensesnitt.

 

Regnekraften som kreves for å flytte og filtrere Gigabit datapakker langt overskrider i alle tilfelle kravet for å dra rundt en fullt GNU/Linux med userland tjenester. 

Jepp. Jeg er fortsatt 100% enig. Vi må ha ordentlige CPUer til å dra rundt gigabit ethernet. Multi-core er i ferd med å bli et absolutt krav. Særlig der du f.eks. skal gjøre krypto på pakkene, som blir mer og mer vanlig.

 

Markedet for 8-bit mikrokontrollere er blitt fullstendig overkjørt. Den 32 bit brede ARM Cortex kjernen er fysisk på samme størrelse som disse, og gjennom Thumb-2 er også kodetettheten sammenlignbar. Der er bare ikke lenger noen god grunn til ikke å benytte en ARM kjerne. Eller MIPS / PowerPC, selv om disse nå er blitt for mer spesielt interesserte. Prisen på (innebygget) minne av alle typer er også nå på det punkt at omtrent alt som selges kan lagre unna et nedskrellet GNU/Linux system. Der er fortsatt unntak fra regelen, og det er system med krav til responstid (RTOS) samt system med krav til Function Safety. Sistnevnte benytter da gjerne Cortex-R i stedet. 

 

Et grelt eksempel på hvor maskinvaren befinner seg for tiden er STM32H7xx. Denne prosessoren kan fint dra rundt GNU/Linux kjerne (dog uten MMU) og userland med masse krefter i reserve. Utviklingskortet NUCLEO-H743ZI  inklusive USB og Ethernet koster kr 193,31 pluss MVA. 

 

Dernest har vi leveregel nummer en fra kryptografien – IKKE skriv din egen algoritme, den kommer til å feile. Det samme gjelder egentlig operativsystem og userland. Security by Obscurity feiler langt oftere som Linux tjenester gjør. Innen jeg (og alle andre) er ferdig med å skrive sitt eget operativsystem med de samme tjenestene som Linux Userland tilbyr, så vil resultatet se ut som en sveitserost. Som demonstrert ved at også Intel går på trynet i sikkerhetsarbeidet, helt nede på maskinvarenivå. Der er alltid en ny angrepsvinkel.

Nå har vi laget et OS som faktisk greier å pushe gigabits med trafikk uten å bruke en Linux-kjerne. 10Gbps eller så per CPU-kjerne på et virtuelt system. Så operativsystemet finnes (includeos.org). Jeg er også enig i at security by obscurity ikke fungerer og det er derfor vi bruker krypto-biblioteker fra OpenSSL og Botan for å gjøre krypto. Ideen vår er å gjøre dette til industri-standard. Vi kan støtte mesteparten av POSIX så programeringsgrensesnittene er omtrent identiske. Vi regner med at de aller fleste biblioteker som ikke gjør dumme ting vil kunne brukes umodifisert. For OpenSSL greier vi til og med å være binærkompatible med Linux slik at vi bruke libssl.a uten å måtte rekompilere den engang (!).

 

Det tar rundt 10000 timer å lage et OK OS. Den tiden har vi lagt ned og vi har noe som fungerer. Jeg tror det har livets rett på enkle enheter som wifi-rutere. Så får vi se om jeg greier å selge inn ideen til andre ila de neste årene. Vi må bare porte til ARM64 først. Hvis noen ser etter jobb for å være med så si ifra - vi har først og fremst jobbet på Intel-arkitektur så vi har mye lære om ARM. :-)

[Bjarne Kastanjenøtt]

Det er et fåtall enhter som står i fare for dette.

 

"The known devices affected by VPNFilter are Linksys, MikroTik, NETGEAR and TP-Link networking equipment in the small and home office (SOHO) space, as well at QNAP network-attached storage (NAS) devices."

 

https://blog.talosintelligence.com/2018/

 

https://blog.talosintelligence.com/2018/05/VPNFilter.html

 

referanse

 

LINKSYS DEVICES:

 

E1200

E2500

WRVS4400N

 

MIKROTIK ROUTEROS VERSIONS FOR CLOUD CORE ROUTERS:

 

1016

1036

1072

 

NETGEAR DEVICES:

 

DGN2200

R6400

R7000

R8000

WNR1000

WNR2000

 

QNAP DEVICES:

 

TS251

TS439 Pro

[bojangles]

 

At Per Buer mener at rutere ikke skal være konfigurerbare får meg bare til å riste på hodet.

Du fikk åpenbart ikke med deg poenget. Så la meg ta det litt med detaljert. Du har garantert et titalls MCU-baserte systemer i livet ditt. De fleste av dem er konfigurerbare systemer. Men du kan ikke logge inn på dem (ikke noe shell) og ikke installere ny programvare på dem. De booter et image og de har konfigurasjon (SSID, ruting-tabell, etc), naturlig nok. Men hvorfor i alle dager skal jeg ha behov for å logge inn på et IP-kamera, en wifi-ruter og installere programvare vilkårlig programvare på dem? For det er situasjonen idag og det er titalls millioner av systemer som pga av denne fleksibiliteten er blitt kompromittert.

 

En wifi-ruter burde ha fullstendig nedlåst firmware, kryptografisk signert fra produsent og oppdatert OTA. Så kan de som har kompetanse og viljen til å dille med fortsette å kjøpe seg OpenWRT-baserte rutere slik at de kan gjøre hva de vil med dem. Men 99% av befolkning vil ikke ha slikt og burde få slippe å ha slike systemer.

 

 

 

Det du sier gir mening nå når du forklarer mer enn du gjorde istad. Men du glemmer en vesentlig ting når du sier oppdatert firmware OTA. Tror nok det er mange som har samme erfaring som meg opp gjennom årene, når en kjøper seg en ruter (hjemmemarkdet or home/small office) så er det nærmest en naturlov skrevet i stein at produsenten dropper oppdatering av firmware jo før jo heller. Det var jo blant annet manglende oppdateringer som i sin tid gjorde at jeg ble introdusert for Openwrt. 

 

For at ideen skal virke og være tryggere enn alternativene bør jo produsentene faktisk oppdatere firmware. Slik det er idag så grenser det nærmest til det urasjonelle å tro at det vil være tilfellet for majoriteten av produsentene. Veksten av åpne løsninger for rutere tror jeg må sees i lys av produsentenes ønske om flytte fokus til nye produkter og at produsentene er raske med å snu ryggen til fjorårets modeller. 

 

Men om vi snur på det. En produsent velger å gjøre som du sier, og står bak produktet sitt og leverer både kritiske fixer i firmware og praktiske fixer OTA og kundene kan være trygg på at disse fixene vil komme dersom det er behov for dem, ja da vil jeg si at det nærmest har åpnet opp et nytt segment hvor kunder kanskje også vil ha økt betalingsvilje for produktet, evt. være villig til å betale en årlig sum for firmware fix OTA. For sålenge produktet virker som planlagt over tid, er stabilt, og kjører høyere sikkerhet så er det klart da blir det vanskelig å argumentere for openwrt el. 

Endret 25. mai 2018 av bojangles

[Per Buer]

Det du sier gir mening nå når du forklarer mer enn du gjorde istad. Men du glemmer en vesentlig ting når du sier oppdatert firmware OTA. Tror nok det er mange som har samme erfaring som meg opp gjennom årene, når en kjøper seg en ruter (hjemmemarkdet or home/small office) så er det nærmest en naturlov skrevet i stein at produsenten dropper oppdatering av firmware jo før jo heller. Det var jo blant annet manglende oppdateringer som i sin tid gjorde at jeg ble introdusert for Openwrt.

Jepp. Det er helt riktig. Litt av problemet er dog at Linux-systemet er _komplekst_. Det er støtte for absolutt alt mulig rart i en slik kjerne. I tillegg kan det være at f.eks. den SoC'en som ruteren bruker bare er støttet av Linux 2.6.46 fordi det var den aktuelle kjernen når SoC'en kom på markedet. Evt. kernel-feil som kommer etter dette må da portes tilbake til denne fordi dette er den eneste versjonen av kjerne som støttes fordi leverandøren aldri lykkes med å upstreame ARM-støtten sin.

 

Så jobben med vedlikeholde wifi-ruter kan være temmelig omfattende fordi OSet er så komplekst. Med et enklere OS som kun har det som skal til så burde problemene være noen størrelsesordener lettere.

 

I tillegg så vil kanskje 99% av feilene i et slikt OS være vanskelige å utnytte. Uten systemkall, skrivbare filsystemer eller shell så er det veldig vanskelig å bryte seg og gjøre noe slemt med et system. Så selv om leverandøren skulle gi blaffen i oppdatere så er ikke enheten dermed automatisk skadelig.

 

Men om vi snur på det. En produsent velger å gjøre som du sier, og står bak produktet sitt og leverer både kritiske fixer i firmware og praktiske fixer OTA og kundene kan være trygg på at disse fixene vil komme dersom det er behov for dem, ja da vil jeg si at det nærmest har åpnet opp et nytt segment hvor kunder kanskje også vil ha økt betalingsvilje for produktet, evt. være villig til å betale en årlig sum for firmware fix OTA. For sålenge produktet virker som planlagt over tid, er stabilt, og kjører høyere sikkerhet så er det klart da blir det vanskelig å argumentere for openwrt el.

Jeg tror at vi må dit at vi må regulere dette. Hvis vi tvinger alle som selger tilkoblede dingser til å støtte dem i minst tre å etter at siste enhet har forlatt fabrikken så blir det fart på sakene. Hvis da leverandøren er ansvarlig for dekke evt. skader som deres manglende oppdatering fører til så blir nok ting bedre.