Snabbare dator
Sprang på Expressens löpsedel häromveckan.
Den var såpass grov att jag kände mig tvingad att läsa artikeln. Tyvärr verkar det som att den inte låg ute på internetupplagan vid tillfället. Upprörd efter ett antal Google-sökningar gav jag upp. Jag upptäckte däremot något annat; att få en snabbare dator på n minuter är hett nyhetsstoff. Man kan snabba upp datorn på både 5, 9, 10, 15, 20 och 30 minuter!
Säg gärna till om ni har en URL till stjäla-allt-på-en-minut-artikeln.
--
Stefan Pettersson
"Vem som helst kan stjäla allt i din dator på en minut."
Den var såpass grov att jag kände mig tvingad att läsa artikeln. Tyvärr verkar det som att den inte låg ute på internetupplagan vid tillfället. Upprörd efter ett antal Google-sökningar gav jag upp. Jag upptäckte däremot något annat; att få en snabbare dator på n minuter är hett nyhetsstoff. Man kan snabba upp datorn på både 5, 9, 10, 15, 20 och 30 minuter!
Säg gärna till om ni har en URL till stjäla-allt-på-en-minut-artikeln.
--
Stefan Pettersson
Boktipset 4: File System Forensic Analysis
Just ordet "forensics" i titeln skulle egentligen kunna sättas inom parentes, det är mer att se som en anledning till att analysera filsystemet överhuvudtaget. FSFA är en alldeles utmärkt referens till volymer, partitioner och filsystem även om man är ointresserad av det forensiska.
Referens är nämligen precis vad det är. Läs boken noggrant, lägg undan den och ta fram den vid behov. Med något så grundläggande som filsystem är det inte svårt hitta behov...
En av de mest informativa böcker jag läst. 350 spänn på Adlibris.
--
Stefan Pettersson
Apoteket och autentisering
I Metro i torsdags fanns en artikel om att illegala läkemedel säljs på Internet. (Ni minns väl t ex Original Pharma?) Läsare varnades för att köpa från apotek som inte är godkända av Läkemedelsverket och "för att vara säker på att en webbsida tillhör ett godkänt svenskt apotek bör man leta efter den nationella apotekssymbolen".
Kom igen. Att använda en digital bild på en hemsida som autentisering är ju t o m svagare än att sätta en broderad krokodil på en tröja.
Efter en kortare undersökning kan vi konstatera att både den här bloggen och DocMorris är kända svenska apotek medan Familjeapoteket inte är det.
Underligt nog har Läkemedelsverket lagt betydligt mer energi på att underlätta verifiering av fysiska butiker, de har en lista på godkända Apotek (länk till Excel-dokument) på sin sida. På listan finns strax över 1 000 adresser till butiker. Det ter sig lite udda; risken att någon skulle sätta upp ett rogue-apotek inne i stan under några veckor för att sälja stulna eller fejkade läkemedel borde vara rätt liten. För webbplatser är detta däremot snarast rutin.
Varför kan de inte använda samma metod med webbplatser? Det skulle ju vara ännu enklare eftersom varje Apotek bara har en domän, listan skulle bara vara ett par rader lång. Dessutom kommer listan inte att behöva uppdateras lika ofta. Kombinera med krav på EV-cert om ni vill.
Bruce Schneier skrev om samma problem häromdagen angående förfalskade myndighetslegg (rapporten han hänvisar till är underhållande).
Man kan inte låta någon autentisera sig genom att bara visa upp en token som är lätt att kopiera; metallbricka, JPG-bild eller broderad krokodil. Säkerheten i sådana system måste vila på att det är omöjligt eller åtminstone svårt att kopiera. Jämför med sedlar, Riksbanken har en sida som beskriver vilka egenskaper som gör dem svåra att tillverka och det är dessa man använder för att avgöra om den är autentisk.
Tyvärr är det dyrt att tillverka tokens som är svåra att kopiera, det kanske till och med inte är värt det. Alternativet är att sköta autentiseringen out-of-band; som med kreditkort. Det viktiga är inte att Visakortet har ett hologram utan att det tillhör personen som håller i det (kolla kortet mot legitimation och personen) och att banken inte har något problem med det (kolla kortet mot banken). Out-of-band är precis vad man använder när man kollar Excel-dokumentet på Läkemedelverkets sida innan man går in i Apotek Hjärtat i Kista galleria eller Kronans droghandel i Kallinge.
Läkemedelsverket borde ha en lista på vilka domännamn som har deras godkännande att sälja läkemedel över Internet.
Se också en två år gammal post på samma ämne; Armani och autentisering.
Uppdatering: Berättade jag förresten att IT-säkerhet enligt HPS blev utnämnd till Sveriges bästa blogg 2010? Du behöver inte ta mitt ord för det, här är den digitala plaketten jag fick:
--
Stefan Pettersson
Kom igen. Att använda en digital bild på en hemsida som autentisering är ju t o m svagare än att sätta en broderad krokodil på en tröja.
Efter en kortare undersökning kan vi konstatera att både den här bloggen och DocMorris är kända svenska apotek medan Familjeapoteket inte är det.
Underligt nog har Läkemedelsverket lagt betydligt mer energi på att underlätta verifiering av fysiska butiker, de har en lista på godkända Apotek (länk till Excel-dokument) på sin sida. På listan finns strax över 1 000 adresser till butiker. Det ter sig lite udda; risken att någon skulle sätta upp ett rogue-apotek inne i stan under några veckor för att sälja stulna eller fejkade läkemedel borde vara rätt liten. För webbplatser är detta däremot snarast rutin.
Varför kan de inte använda samma metod med webbplatser? Det skulle ju vara ännu enklare eftersom varje Apotek bara har en domän, listan skulle bara vara ett par rader lång. Dessutom kommer listan inte att behöva uppdateras lika ofta. Kombinera med krav på EV-cert om ni vill.
Bruce Schneier skrev om samma problem häromdagen angående förfalskade myndighetslegg (rapporten han hänvisar till är underhållande).
Man kan inte låta någon autentisera sig genom att bara visa upp en token som är lätt att kopiera; metallbricka, JPG-bild eller broderad krokodil. Säkerheten i sådana system måste vila på att det är omöjligt eller åtminstone svårt att kopiera. Jämför med sedlar, Riksbanken har en sida som beskriver vilka egenskaper som gör dem svåra att tillverka och det är dessa man använder för att avgöra om den är autentisk.
Tyvärr är det dyrt att tillverka tokens som är svåra att kopiera, det kanske till och med inte är värt det. Alternativet är att sköta autentiseringen out-of-band; som med kreditkort. Det viktiga är inte att Visakortet har ett hologram utan att det tillhör personen som håller i det (kolla kortet mot legitimation och personen) och att banken inte har något problem med det (kolla kortet mot banken). Out-of-band är precis vad man använder när man kollar Excel-dokumentet på Läkemedelverkets sida innan man går in i Apotek Hjärtat i Kista galleria eller Kronans droghandel i Kallinge.
Läkemedelsverket borde ha en lista på vilka domännamn som har deras godkännande att sälja läkemedel över Internet.
Se också en två år gammal post på samma ämne; Armani och autentisering.
Uppdatering: Berättade jag förresten att IT-säkerhet enligt HPS blev utnämnd till Sveriges bästa blogg 2010? Du behöver inte ta mitt ord för det, här är den digitala plaketten jag fick:
--
Stefan Pettersson
Mer om börsbottar
Jag skrev om börsbottar, eller algotrading som det kallas, i höstas. Jag tycker fortfarande att det är läskigt. Wire har en intressant artikel från innan nyår; Algorithms Take Control of Wall Street:
At its best, this system represents an efficient and intelligent capital allocation machine, a market ruled by precision and mathematics rather than emotion and fallible judgment. But at its worst, it is an inscrutable and uncontrollable feedback loop.
Tydligen hamnar algoritmerna regelbundet i tillstånd där de påverkas av och påverkar varandras beslut i en spiral:
On May 6, 2010, the Dow Jones Industrial Average inexplicably experienced a series of drops that came to be known as the flash crash, at one point shedding some 573 points in five minutes. Less than five months later, Progress Energy, a North Carolina utility, watched helplessly as its share price fell 90 percent. Also in late September, Apple shares dropped nearly 4 percent in just 30 seconds, before recovering a few minutes later. These sudden drops are now routine, and it’s often impossible to determine what caused them.
Vidare angående the flash crash:
The chaos produced seemingly nonsensical trades—shares of Accenture were sold for a penny, for instance, while shares of Apple were purchased for $100,000 each. (Both trades were subsequently canceled.) The activity briefly paralyzed the entire financial system.
Två förslag på att lugna situationen har varit (1) att frysa handeln när någon kurs förändras för mycket för fort (rate-limit) och (2) att införa avgifter för att belasta sådan form av trading (ekonomiskt styrmedel).
Läskigt som sagt men det är tveklöst imponerande:
Bradley was among the first traders to explore the power of algorithms in the late ’90s, creating approaches to investing that favored brains over access. It took him nearly three years to build his stock-scoring program. First he created a neural network, painstakingly training it to emulate his thinking—to recognize the combination of factors that his instincts and experience told him were indicative of a significant move in a stock’s price.
Uppdatering: Schneier hänvisade igår till en artikel om att attackera bottarna. Eftersom algoritmerna vilar på att de är såpass snabba räcker det tydligen med att fördröja deras handlingar väldigt lite för att kunna utnyttja dem. Minns dock att utnyttjande av buggar i algoritmer är frowned upon...
--
Stefan Pettersson
At its best, this system represents an efficient and intelligent capital allocation machine, a market ruled by precision and mathematics rather than emotion and fallible judgment. But at its worst, it is an inscrutable and uncontrollable feedback loop.
Tydligen hamnar algoritmerna regelbundet i tillstånd där de påverkas av och påverkar varandras beslut i en spiral:
On May 6, 2010, the Dow Jones Industrial Average inexplicably experienced a series of drops that came to be known as the flash crash, at one point shedding some 573 points in five minutes. Less than five months later, Progress Energy, a North Carolina utility, watched helplessly as its share price fell 90 percent. Also in late September, Apple shares dropped nearly 4 percent in just 30 seconds, before recovering a few minutes later. These sudden drops are now routine, and it’s often impossible to determine what caused them.
Vidare angående the flash crash:
The chaos produced seemingly nonsensical trades—shares of Accenture were sold for a penny, for instance, while shares of Apple were purchased for $100,000 each. (Both trades were subsequently canceled.) The activity briefly paralyzed the entire financial system.
Två förslag på att lugna situationen har varit (1) att frysa handeln när någon kurs förändras för mycket för fort (rate-limit) och (2) att införa avgifter för att belasta sådan form av trading (ekonomiskt styrmedel).
Läskigt som sagt men det är tveklöst imponerande:
Bradley was among the first traders to explore the power of algorithms in the late ’90s, creating approaches to investing that favored brains over access. It took him nearly three years to build his stock-scoring program. First he created a neural network, painstakingly training it to emulate his thinking—to recognize the combination of factors that his instincts and experience told him were indicative of a significant move in a stock’s price.
Uppdatering: Schneier hänvisade igår till en artikel om att attackera bottarna. Eftersom algoritmerna vilar på att de är såpass snabba räcker det tydligen med att fördröja deras handlingar väldigt lite för att kunna utnyttja dem. Minns dock att utnyttjande av buggar i algoritmer är frowned upon...
--
Stefan Pettersson
Bakdörrar i program
Uppdatering @ 2011-01-13: Tydligen har jag och CJ fortfarande någon form av mind sync; han tar diskussionen om bakdörrar till en högre nivå på sin blogg. Samtidigt. :-)
I sin essä The Cathedral and the Bazaar från 1997 konstaterar Eric Raymond att given enough eyeballs, all bugs are shallow. När tillräckligt många programmerare tittar på koden kan alla buggar upptäckas. Bakgrunden till teorin är förstås erfarenheterna från Linuxkärnans utveckling under 90-talet.
I projekt med öppen källkod kan ju vem som helst titta på källkoden. "Vem som helst" borde ju innebära "väldigt många", inte sant? Eftersom säkerhetsbuggar är en delmängd av buggar, finns det generellt färre säkerhetsbuggar i program med öppen källkod?
Det här är ett fånigt känsligt ämne och är bidragande till många bråk. De som hörs mest är, som vanligt, de längst ut på vardera kant och, som vanligt, har ingen av kanterna rätt. Teorin är alldeles för generaliserad för att kunna besvaras som ett antingen-eller.
En vanlig tillflyktsort för Raymonds förespråkare är "...men du har åtminstone möjligheten att granska koden". Det är helt korrekt men har inget att göra med mängden buggar som finns eller inte. Det är dock intressant, varför skulle man vilja granska ett program? Uppfyller det våra säkerhetskrav? Verkar det vara välskrivet? Innehåller det några bakdörrar?
Bakdörrar
En bakdörr i ett program kan beskrivas som ett inofficiellt och dolt gränssnitt till programmet. Begreppet blev populärt i samband med filmen Wargames från 1983 där ett hemligt lösenord, "joshua", ger omedelbar tillgång till AI-datorn WOPR på NORAD. <begreppsnazism>Bakdörr är också vad många generellt menar när de istället säger trojan även fast gränsen ofta är fin.</begreppsnazism> Nyckeln till det hela är att bakdörren är just dold. Annars hade det väl bara varit en... dörr, antar jag.
Ken Thompson, legendarisk för sitt arbete med Multics och UNIX, höll 1984 ett tal, Reflections on Trusting Trust, där han beskrev hur en kompilator kan trojaniseras så att den lägger till bakdörrar i program den kompilerar. Som en bonus trojaniserar den även sig själv vid kompilering (även kompilatorer kompileras, ibland paradoxalt nog av sig själva). Inte nog med det, Thomson demonstrerade också en kompilator som sabbade de disassemblers den kompilerade så att de helt enkelt gömde de bakdörrar kompilatorn placerat ut.
Förhoppningsvis (vi vet ju inte) är bakdörrar i "verkligheten" sällan så esoteriska. För att knyta ihop; några exempel på bakdörrar i projekt med öppen källkod:
Linux 2.6
Vi börjar med ett som är rätt gammalt men ändå förtjänar ett omnämnande. I november 2003 lades två rader till i filen kernel/exit.c. Om ett särskilt kriterium uppfylldes uppgraderades användaren till root. Väldigt subtilt. Läs konversationen på kernel-listan på Kerneltrap. Bakdörren upptäcktes omedelbart.
UnrealIRCd 3.2.8.1
I somras (2010) gick utvecklarna bakom den populära IRC-servern ut med att en bakdörr har upptäckts i filen include/struct.h. Även den här gången har två rader lagts till varav den ena anropar system() för att exekvera kommandon. Läs mer på deras forum. Bakdörren hade funnits i källkoden i mer än ett halvår.
ProFTPD 1.3.3c
I början av december 2010 upptäcktes en bakdörr i FTP-servern. När kommandot "HELP ACIDBITCHEZ" gavs hamnade man i ett root-shell. Ändringen gjordes på servern som servrar tarbollarna, inte i CVS-trädet. Läs meddelandet på mailinglistan för mer information. Bakdörren hade existerat i mindre än en vecka.
OpenBSD?
I mitten av december fick Theo de Raadt ett mail som hävdade att FBI hade lagt in bakdörrar i operativsystemets IPSEC-stack. Det hela verkar ganska otroligt och har inte kunnat bevisas.
Ettercap NG-0.7.3?
I ett zine som publicerades under julhelgen, Owned and Exposed, gjordes antydningar till att det populära snifferverktyget Ettercap har haft en bakdörr sedan många år tillbaka. Inget har bekräftats och på SpiderLabs blogg har man undersökt saken och kommit fram till att det är osannolikt.
Samtliga exempel ovan har antingen upptäckts (ibland snabbt, ibland inte) eller inte kunnat bevisas. Vilka slutsatser kan vi dra från det gentemot Raymonds teori om många ögon och Thompsons exempel på bakdörrar som är extremt svåra att hitta? Inte många.
--
Stefan Pettersson
I sin essä The Cathedral and the Bazaar från 1997 konstaterar Eric Raymond att given enough eyeballs, all bugs are shallow. När tillräckligt många programmerare tittar på koden kan alla buggar upptäckas. Bakgrunden till teorin är förstås erfarenheterna från Linuxkärnans utveckling under 90-talet.
I projekt med öppen källkod kan ju vem som helst titta på källkoden. "Vem som helst" borde ju innebära "väldigt många", inte sant? Eftersom säkerhetsbuggar är en delmängd av buggar, finns det generellt färre säkerhetsbuggar i program med öppen källkod?
Det här är ett fånigt känsligt ämne och är bidragande till många bråk. De som hörs mest är, som vanligt, de längst ut på vardera kant och, som vanligt, har ingen av kanterna rätt. Teorin är alldeles för generaliserad för att kunna besvaras som ett antingen-eller.
En vanlig tillflyktsort för Raymonds förespråkare är "...men du har åtminstone möjligheten att granska koden". Det är helt korrekt men har inget att göra med mängden buggar som finns eller inte. Det är dock intressant, varför skulle man vilja granska ett program? Uppfyller det våra säkerhetskrav? Verkar det vara välskrivet? Innehåller det några bakdörrar?
Bakdörrar
En bakdörr i ett program kan beskrivas som ett inofficiellt och dolt gränssnitt till programmet. Begreppet blev populärt i samband med filmen Wargames från 1983 där ett hemligt lösenord, "joshua", ger omedelbar tillgång till AI-datorn WOPR på NORAD. <begreppsnazism>Bakdörr är också vad många generellt menar när de istället säger trojan även fast gränsen ofta är fin.</begreppsnazism> Nyckeln till det hela är att bakdörren är just dold. Annars hade det väl bara varit en... dörr, antar jag.
Ken Thompson, legendarisk för sitt arbete med Multics och UNIX, höll 1984 ett tal, Reflections on Trusting Trust, där han beskrev hur en kompilator kan trojaniseras så att den lägger till bakdörrar i program den kompilerar. Som en bonus trojaniserar den även sig själv vid kompilering (även kompilatorer kompileras, ibland paradoxalt nog av sig själva). Inte nog med det, Thomson demonstrerade också en kompilator som sabbade de disassemblers den kompilerade så att de helt enkelt gömde de bakdörrar kompilatorn placerat ut.
Förhoppningsvis (vi vet ju inte) är bakdörrar i "verkligheten" sällan så esoteriska. För att knyta ihop; några exempel på bakdörrar i projekt med öppen källkod:
Linux 2.6
Vi börjar med ett som är rätt gammalt men ändå förtjänar ett omnämnande. I november 2003 lades två rader till i filen kernel/exit.c. Om ett särskilt kriterium uppfylldes uppgraderades användaren till root. Väldigt subtilt. Läs konversationen på kernel-listan på Kerneltrap. Bakdörren upptäcktes omedelbart.
UnrealIRCd 3.2.8.1
I somras (2010) gick utvecklarna bakom den populära IRC-servern ut med att en bakdörr har upptäckts i filen include/struct.h. Även den här gången har två rader lagts till varav den ena anropar system() för att exekvera kommandon. Läs mer på deras forum. Bakdörren hade funnits i källkoden i mer än ett halvår.
ProFTPD 1.3.3c
I början av december 2010 upptäcktes en bakdörr i FTP-servern. När kommandot "HELP ACIDBITCHEZ" gavs hamnade man i ett root-shell. Ändringen gjordes på servern som servrar tarbollarna, inte i CVS-trädet. Läs meddelandet på mailinglistan för mer information. Bakdörren hade existerat i mindre än en vecka.
OpenBSD?
I mitten av december fick Theo de Raadt ett mail som hävdade att FBI hade lagt in bakdörrar i operativsystemets IPSEC-stack. Det hela verkar ganska otroligt och har inte kunnat bevisas.
Ettercap NG-0.7.3?
I ett zine som publicerades under julhelgen, Owned and Exposed, gjordes antydningar till att det populära snifferverktyget Ettercap har haft en bakdörr sedan många år tillbaka. Inget har bekräftats och på SpiderLabs blogg har man undersökt saken och kommit fram till att det är osannolikt.
Samtliga exempel ovan har antingen upptäckts (ibland snabbt, ibland inte) eller inte kunnat bevisas. Vilka slutsatser kan vi dra från det gentemot Raymonds teori om många ögon och Thompsons exempel på bakdörrar som är extremt svåra att hitta? Inte många.
--
Stefan Pettersson
