Slakter sikkerheten og kildekoden til Samsungs Android-alternativ

[Harald Brombach (digi.no)]

Bruker Tizen i en rekke produkter, inkludert selskapets tv-er.

Slakter sikkerheten og kildekoden til Samsungs Android-alternativ

[Gjest Slettet-Pqy3rC]

Men sårbarhetene skyldes ifølge Neiderman feil av den typen som utviklere typisk gjorde for 20 år siden, blant annet bruken av strcpy()-funksjonen, som ikke sjekker om det er nok plass i minnet til å skrive dataene som skal kopieres.

Er det journalisten eller denne Neiderman som her ikke vet hva de prater om ?

 

Funksjoner som memmov(), memcpy(), strcpy() er alle basert på at programmerer vet hva de driver med. Når en jobber med pekere (C/C++) er det å holde kontroll på minnet en del av greia. Disse funksjonene er det flusst av i kildekoden til de fleste OS.

 

Det spesielle med strcpy() er at den stopper kopieringen først når den treffer en NUL byte, i motsetning til andre funksjoner hvor en isteden angir antall bytes som skal kopieres. Alle funksjonene forutsetter at programmerer har orden på minnet det skal kopieres til (malloc(), free()).

Endret 6. april 2017 av Slettet-Pqy3rC

[Xantippe]

 

Men sårbarhetene skyldes ifølge Neiderman feil av den typen som utviklere typisk gjorde for 20 år siden, blant annet bruken av strcpy()-funksjonen, som ikke sjekker om det er nok plass i minnet til å skrive dataene som skal kopieres.

Er det journalisten eller denne Neiderman som her ikke vet hva de prater om ?

 

Funksjoner som memmov(), memcpy(), strcpy() er alle basert på at programmerer vet hva de driver med. Når en jobber med pekere (C/C++) er det å holde kontroll på minnet en del av greia. Disse funksjonene er det flusst av i kildekoden til de fleste OS.

 

Det spesielle med strcpy() er at den stopper kopieringen først når den treffer en NUL byte, i motsetning til andre funksjoner hvor en isteden angir antall bytes som skal kopieres. Alle funksjonene forutsetter at programmerer har orden på minnet det skal kopieres til (malloc(), free()).

Jeg skjønner ikke poenget ditt med å kritisere journalisten eller Neiderman.

Neiderman sier at programmererne har brukt strcpy() uten å sjekke om bufferen er stor nok.

Dette er det reneste vanvidd, og du kritiserer at han eksemplifiserer det.

strcpy() stopper kopieringen når den finner NULL i memory, og det er kun nybegynnere som gjør en så banal, men akk så alvorlig tabbe å ikke sjekke bufferstørrelsen.

[Gjest Slettet-Pqy3rC]

Neiderman sier at programmererne har brukt strcpy() uten å sjekke om bufferen er stor nok.

Det er ikke hva som står;

...blant annet bruken av strcpy()-funksjonen, som ikke sjekker om det er nok plass i minnet til å skrive dataene som skal kopieres.

Det står, ganske riktig, at strcpy() selv ikke sjekker størrelsen på bufferet. Så her kritiseres bruken av strcpy() generelt, uavhengig av hvordan funksjonen brukes.

 

..men det kan jo hende du har rett; dvs. at journalisten mente å skrive noe annet.

[CaZpeR]

Hadde vært interessant om noen plukket på WebOS 3.0 til LG sine TV'er.

[Emancipate]

 

Neiderman sier at programmererne har brukt strcpy() uten å sjekke om bufferen er stor nok.

Det er ikke hva som står;

...blant annet bruken av strcpy()-funksjonen, som ikke sjekker om det er nok plass i minnet til å skrive dataene som skal kopieres.

Det står, ganske riktig, at strcpy() selv ikke sjekker størrelsen på bufferet. Så her kritiseres bruken av strcpy() generelt, uavhengig av hvordan funksjonen brukes.

 

..men det kan jo hende du har rett; dvs. at journalisten mente å skrive noe annet.

 

feil av den typen som utviklere typisk gjorde for 20 år siden, blant annet bruken av strcpy()-funksjonen

Man kan tolke det sånn at det er "bruken av strcpy-funksjonen" han kritiserer, altså akkurat den bruken, som i det tilfellet var feilbruk, ikke "bruk av strcpy-funksjonen". Det er en nyanseforskjell på bruken og bruk.

 

Men uansett mener han nok at man ikke bør bruke den funksjonen. Dette fordi det er så lett å gjøre feil. Sett fra et sikkerhetsperspektiv er det uheldig å bruke funksjoner det er lett å lage sikkerhetshull med. Noe jeg tolker det som at han har funnet her.

Endret 6. april 2017 av Emancipate

[_dundun_]

...og det er jo helt riktig. Det er elendig praksis å benytte funksjoner som gir store sikkerhetshull ved små forglemmelser fra programmereren. Folk gjør feil, mye av håndverket ligger i å gjøre feilene så lite alvorlige som mulig ved gode rutiner og fornuftig praksis. Noen ganger må man selvsagt leke med ilden, men bare når det er helt nødvendig. Programmerere som benytter masseødeleggelsesvåpen til alt fordi "jeg har jo kontroll" kan du få billig av meg. "Pusser alltid tenna med motorsag jeg, er jo fagmann og vet hva jeg gjør!". De er gjerne stolte av at de kjører alt som root også.

 

Men altså, dette er software fra Samsung. Hvem hadde ventet noe annet fra den kanten? Tven min er iallfall blokka fra å snakke med internett, og det burde være helt uaktuelt for alle å kjøpe noe som helst med Tizen på heretter.

Endret 7. april 2017 av Audun_K

[Gjest Slettet-Pqy3rC]

Man kan tolke det sånn at det er "bruken av strcpy-funksjonen" han kritiserer, altså akkurat den bruken, som i det tilfellet var feilbruk, ikke "bruk av strcpy-funksjonen". Det er en nyanseforskjell på bruken og bruk.

Tja, kanskje det. Setningen var uansett underlig nok til at jeg missforsto. Hvilket jeg fortsatt ikke er sikker på at jeg faktisk gjorde. 

Men uansett mener han nok at man ikke bør bruke den funksjonen. Dette fordi det er så lett å gjøre feil. Sett fra et sikkerhetsperspektiv er det uheldig å bruke funksjoner det er lett å lage sikkerhetshull med. Noe jeg tolker det som at han har funnet her.

...og det er jo helt riktig. Det er elendig praksis å benytte funksjoner som gir store sikkerhetshull ved små forglemmelser fra programmereren.

strcpy() er ikke værre (å holde orden på) enn alt annet i C. Det mest "normale" er å bomme på adresseringen fordi en flytter feil adresse inn i en eller annen variabel, altså ikke noen funksjon i det hele tatt.

Kan en bruke C++ vil jo objektorientering og STL hjelpe en hel del om en har minne og cpu kraft nok.

Folk gjør feil, mye av håndverket ligger i å gjøre feilene så lite alvorlige som mulig ved gode rutiner og fornuftig praksis.

Nja, poenget er å ha et testregime som plukker vekk (alle) feil, mens rutinene/reglene (en koder etter) bør gi mest mulig effektiv kode. Rent teoretisk altså, det finnes mange ulike måter å løse det på i praksis.

[_dundun_]

Nja, poenget er å ha et testregime som plukker vekk (alle) feil, mens rutinene/reglene (en koder etter) bør gi mest mulig effektiv kode. Rent teoretisk altså, det finnes mange ulike måter å løse det på i praksis.

I de fleste tilfeller vil jeg si at effektiv kode er godt etter "leselig", "sikker" og "vedlikeholdbar" på prioriteringslista. Det finnes selvsagt en hel del unntak, men som en generell regel er jeg nervøs for kode som er optimalisert for effektivitet.

 

For meg er uansett "Ikke skrevet av Samsung" også et viktig poeng. Dette kan de ikke.

Endret 7. april 2017 av Audun_K

[Eplekatt]

 

Men sårbarhetene skyldes ifølge Neiderman feil av den typen som utviklere typisk gjorde for 20 år siden, blant annet bruken av strcpy()-funksjonen, som ikke sjekker om det er nok plass i minnet til å skrive dataene som skal kopieres.

Er det journalisten eller denne Neiderman som her ikke vet hva de prater om ?

 

Funksjoner som memmov(), memcpy(), strcpy() er alle basert på at programmerer vet hva de driver med. Når en jobber med pekere (C/C++) er det å holde kontroll på minnet en del av greia. Disse funksjonene er det flusst av i kildekoden til de fleste OS.

 

Det spesielle med strcpy() er at den stopper kopieringen først når den treffer en NUL byte, i motsetning til andre funksjoner hvor en isteden angir antall bytes som skal kopieres. Alle funksjonene forutsetter at programmerer har orden på minnet det skal kopieres til (malloc(), free()).

med andre ord er det snakk om at tv produsenten selv har mekket appene på 5 minutter.

[Gjest Slettet-Pqy3rC]

I de fleste tilfeller vil jeg si at effektiv kode er godt etter "leselig", "sikker" og "vedlikeholdbar" på prioriteringslista.

"Leselig" er en god ting. Det er viktig å gjøre ting ensrettet så en unngår missforståelser. F.eks. holde seg til enten "Zero based" eller "One based" (i funksjonskall/iteratorer mm) og ikke mikse bruk av de to. Da blir det enklere både å skrive ny kode og å vedlikeholde eksisterende.

 

Begrepet "sikker" vet jeg ikke hvordan jeg skal tolke. Jeg har skrevet kode som benyttes i fly, der gjør en periodiske bl.a. tester av hardware regelmessig (test av RAM blokker før bruk- software ECC). Det er altså uvanlig høy sikkerhet mot feil.

Tenker du sikkerhet som "hindre uvedkommende tilgang" er det mer politisk avhengig enn koding. Det er egentlig veldig få feil som lettere gir uvedkommende tilgang, da aller fleste feil fører bare til at systemet ikke virker slik det er tenkt.

med andre ord er det snakk om at tv produsenten selv har mekket appene på 5 minutter.

øh.. apper?

[_dundun_]

Jepp, ser at "sikker" er upresist. "Oppfyller alle krav til integritet" er bedre å si. Kravene til integritet varierer åpenbart fra applikasjon til applikasjon.

[tommyb]

Det er én ting om dette er status for IoT-enheter og smartenheter. Der er det allerede kjent at sikkerhet er et problem som man avfeier og kommer til å avfeie inntil det kommer ofte som hovedsak på nyhetene.

Jeg er mer bekymret fordi Tizen også er et operativsystem på mobiltelefoner. Lite brukt utenfor India, kanskje, men deres uttalte backup-plan og viktig for dem dersom de mister grepet over Android-salget.

Samsung burde derfor vært langt mer motivert til å tenke sikkerhet på mobiltelefoner - som er av de mest åpenbare angrepspunktene, ikke beskyttet bak hjemmenettverk, alle de store mobilplattformene allerede kjent med store mengder angrep, og med tilgang til både kontaktinformasjon for effektiv spredning, enkle muligheter til å utnytte betalingsinformasjon eller betalingstjenester, og de mest effektive mulighetene til overvåkning.

Hvis ikke Samsung er motivert til å tenke sikkerhet når de lager et OS for mobiltelefoner, vil de aldri kunne bli motivert til å tenke sikkerhet. Kanskje det beste som kan skje Samsung er at de får et massivt angrep spesifikt mot dem, slik at de får en viktig lærepenge. Akkurat nå ville jeg vært ganske skeptisk til å kjøpe et Samsung-produkt som ikke kjører ren Android uten Samsung-lag.

Men det er ikke dermed sagt at jeg tror noen av de andre OEMene nødvendigvis tar det mer alvorlig. Det eneste jeg vet er at deler av Sony allerede har fått noen alvorlige nesestyvere på grunn av totalt manglende respekt for sikkerhet/brukerne sine, og forhåpentlig har noen der lært noe. Kanskje trenger alle i disse bransjene noen slike oppvekkere. 

Endret 8. april 2017 av tommyb

[Emancipate]

Nja, poenget er å ha et testregime som plukker vekk (alle) feil

Et testregime kan bare bevise at et program har feil, ikke at det ikke har feil. For det kan alltids lure noen feiltyper i kulissene som man ikke har tenkt på, eller selve testen kan være skrevet feil. Derfor er ikke et testregime en erstatning for mer solide garantier, som f.eks. statisk typing, bruk av "trygge" funksjoner, osv... Testregimet må være et supplement.

Endret 8. april 2017 av Emancipate

[_dundun_]

Det viktigste er uansett kompetanse. Dårlige programmerere klarer å snike de utroligste ting forbi ethvert regime. Man skal jo shippe også, så man får aldri testa alt.

[vidor]

Kan være verdt å se på implementasjonen av C-bibliotekene til Qmail. David J Bernstein som stod bak dette var villig til å betale plenty hvis noen fant huller i sikkerhetsaspektet.

[linux-fan]

 

Nja, poenget er å ha et testregime som plukker vekk (alle) feil

Et testregime kan bare bevise at et program har feil, ikke at det ikke har feil. For det kan alltids lure noen feiltyper i kulissene som man ikke har tenkt på, eller selve testen kan være skrevet feil. Derfor er ikke et testregime en erstatning for mer solide garantier, som f.eks. statisk typing, bruk av "trygge" funksjoner, osv... Testregimet må være et supplement.

 

 

Også viktig å ha ledere som ikke premierer/fokuserer på antall testcase man godkjenner per dag, da blir hele testingen bortkastet.

Har koden mange feil vil testing og retesting ta lang tid.

Poenget med testing er å finne feil, ikke byråkratisk tull for å estimere og fakturere flere timer på prosjektet.