Ingen ljudspelare nedan? Lyssna direkt på Soundcloud.

DOUG.  Firefox-uppdateringar, en annan Bugg Med Ett Imponerande Namn, och SEC kräver avslöjande.

Allt det och mer i podden Naked Security.

[MUSIKALT MODEM]

Välkommen till podden, alla.

Jag är Doug Aamoth; han är Paul Ducklin.

Paul, jag hoppas att du kommer att vara stolt över mig... Jag vet att du är en cykelentusiast.

Jag cyklade igår i 10 amerikanska mil, vilket jag tror är ungefär 16 km, samtidigt som jag drog ett litet men inte otungt barn bakom cykeln i en tvåhjulig vagn.

Och jag lever fortfarande för att berätta sagan.

Är det långt att cykla, Paul?

ANKA.  [SKratt] Det beror på hur långt du verkligen behövde gå.

Som, om det faktiskt var 1200 meter som du var tvungen att gå och du gick vilse... [SKRATT]

Min entusiasm för cykling är väldigt hög, men det betyder inte att jag medvetet cyklar längre än jag behöver, för det är mitt främsta sätt att ta mig fram.

Men 10 mil är okej.

Visste du att amerikanska miles och brittiska miles faktiskt är identiska?

DOUG.  Det är bra att veta!

ANKA.  Och har varit det sedan 1959, när ett gäng länder inklusive, tror jag, Kanada, Sydafrika, Australien, USA och Storbritannien gick samman och kom överens om att standardisera på en "internationell tum".

Jag tror att den kejserliga tummen blev väldigt, väldigt lite mindre och den amerikanska tummen blev väldigt, väldigt lite längre, med resultatet att tummen (och därmed gården, och foten och milen)...

…de är alla definierade i termer av meter.

En tum är exakt 25.4 mm

Tre betydande siffror är allt du behöver.

DOUG.  Fascinerande!

Tja, på tal om fascinerande, det är dags för vår Denna vecka i teknisk historia segmentet.

Den här veckan, den 01 augusti 1981, gick Music Television, även känd som MTV, live som en del av amerikanska kabel- och satellit-tv-paket och introducerade allmänheten för musikvideor.

Den första spelade [SINGS, RETTHER WELL I Facts] "Video Killed the Radio Star" av The Buggles.

Passande på den tiden, även om det är ironiskt nuförtiden då MTV sällan spelar musikvideor längre, och inte spelar några nya musikvideor alls, Paul.

ANKA.  Ja, det är ironiskt, eller hur, att kabel-TV (med andra ord, där du hade sladdar som gick under marken in i ditt hus) dödade radiostjärnan (eller den trådlösa) och nu ser det ut som om kabel-TV, MTV… den sortens dog ut eftersom alla har mobila nätverk som fungerar trådlöst.

Det som händer kommer runt, Douglas.

DOUG.  Okej, låt oss prata om dessa Firefox-uppdateringar.

Vi får en dubbel dos av Firefox-uppdateringar den här månaden, eftersom de är på en 28-dagarscykel:

Firefox åtgärdar en uppsjö av brister i den första av två utgåvor denna månad

Inga nolldagar i denna första omgång utanför porten, men några lärbara ögonblick.

Vi har listat kanske hälften av dessa i din artikel, och en som verkligen stack ut för mig var: Potentiella tillståndsbegäran förbigås via clickjacking.

ANKA.  Ja, gamla goda clickjacking igen.

Jag gillar den termen eftersom den ganska mycket beskriver vad den är.

Du klickar någonstans och tror att du klickar på en knapp eller en oskyldig länk, men du tillåter oavsiktligt att något händer som inte är uppenbart av vad skärmen visar under din muspekare.

Problemet här verkar vara att under vissa omständigheter, när en behörighetsdialog var på väg att dyka upp från Firefox, till exempel, säg: "Är du verkligen säker på att du vill låta den här webbplatsen använda din kamera? har du tillgång till din plats? använda din mikrofon?”...

...alla de där sakerna som, ja, du vill bli tillfrågad.

Tydligen, om du kunde få webbläsaren till en prestandapunkt (igen, prestanda kontra säkerhet) där den kämpade för att hänga med, kunde du fördröja uppkomsten av behörighetspopupen.

Men genom att ha en knapp på platsen där popup-fönstret skulle dyka upp och locka användaren att klicka på den, kunde du locka till klicket, men klicket skulle sedan skickas till behörighetsdialogrutan som du inte riktigt hade sett ännu.

Ett slags visuellt rastillstånd, om du vill.

DOUG.  OK, och den andra var: Duk utanför skärmen kunde ha kringgått begränsningar för korsning.

Du fortsätter med att säga att en webbsida kan titta på bilder som visas på en annan sida från en annan sida.

ANKA.  Det är väl inte meningen att det ska hända?

DOUG.  Nej!

ANKA.  Jargongtermen för det är "same-origin policy".

Om du kör webbplats X och du skickar mig en hel massa JavaScript som sätter en hel mängd cookies, så lagras allt det i webbläsaren.

Men bara ytterligare JavaScript från webbplats X kan läsa tillbaka dessa data.

Det faktum att du surfar till webbplats X på en flik och webbplats Y på den andra fliken låter dem inte titta på vad den andra gör, och webbläsaren är tänkt att hålla isär allt det där.

Det är så klart ganska viktigt.

Och det verkar här som, så vitt jag förstår det, om du renderade en sida som inte visades ännu...

…en duk utanför skärmen, det är där du skapar, om du vill, en virtuell webbsida och sedan någon gång i framtiden säger du, "Just nu är jag redo att visa den," och bingo, sidan visas kl. en gång.

Problemet kommer med att försöka se till att det som du renderar osynligt inte oavsiktligt läcker data, även om det aldrig i slutändan visas för användaren.

De upptäckte det, eller så avslöjades det på ett ansvarsfullt sätt, och det lappades.

Och de två, tror jag, ingick i de så kallade sårbarheterna på "hög" nivå.

De flesta av de andra var "Moderate", med undantag för Mozillas traditionella, "Vi hittade en hel massa buggar genom fuzzing och genom automatiserade tekniker; vi undersökte dem inte för att ta reda på om de kunde utnyttjas överhuvudtaget, men vi är villiga att anta att någon som försökte tillräckligt hårt kunde göra det.”

Det är ett erkännande som vi båda gillar så mycket, Doug... för potentiella buggar är värda att slå sönder, även om du känner dig säker i ditt hjärta att ingen någonsin kommer att komma på hur man kan utnyttja dem.

För inom cybersäkerhet lönar det sig att aldrig säga aldrig!

DOUG.  Okej, du letar efter Firefox 116, eller om du har en utökad version, 115.1.

Samma sak med Thunderbird.

Och låt oss gå vidare till... åh, man!

Paul, det här är spännande!

Vi har en ny BWAIN efter en dubbel-BWAIN förra veckan: en bugg med ett imponerande namn.

Den här heter Kollidera+Ström:

Prestanda och säkerhet krockar ännu en gång i "Collide+Power"-attacken

ANKA.  [SKratt] Ja, det är spännande, eller hur, att de valde ett namn som har ett plustecken?

DOUG.  Ja, det gör det svårt att säga.

ANKA.  Du kan inte ha ett plustecken i ditt domännamn, så domännamnet är det collidepower.com.

DOUG.  Okej, låt mig läsa från forskarna själva, och jag citerar:

Roten till problemet är att delade CPU-komponenter, som det interna minnessystemet, kombinerar angripardata och data från vilken annan applikation som helst, vilket resulterar i en kombinerad läcksignal i strömförbrukningen.

Genom att känna till sina egna data kan angriparen således bestämma de exakta datavärdena som används i andra applikationer.

ANKA.  [skrattar] Ja, det är väldigt vettigt om du redan vet vad de pratar om!

För att försöka förklara detta på vanlig engelska (jag hoppas att jag har fattat detta rätt)...

Detta går ner till de prestanda-versus-säkerhetsproblem som vi har pratat om tidigare, inklusive förra veckans podcast med det Zenbleed bugg (som är mycket allvarligare, förresten):

Zenbleed: Hur strävan efter CPU-prestanda kan utsätta dina lösenord för fara

Det finns en hel mängd data som förvaras inuti CPU:n ("cache" är den tekniska termen för det) så att CPU:n inte behöver gå och hämta den senare.

Så det finns en hel del interna saker som du inte riktigt får hantera; CPU:n tar hand om det åt dig.

Och hjärtat av denna attack verkar gå ungefär så här...

Vad angriparen gör är att komma åt olika minnesplatser på ett sådant sätt att den interna cachelagringen kommer ihåg dessa minnesplatser, så att den inte behöver gå och läsa dem ur RAM-minnet igen om de snabbt återanvänds.

Så angriparen får på något sätt dessa cachevärden fyllda med kända mönster av bitar, kända datavärden.

Och sedan, om offret har minne som *de* använder ofta (till exempel byten i en dekrypteringsnyckel), om deras värde plötsligt bedöms av CPU:n vara mer sannolikt att återanvändas än ett av angriparnas värden, det sparkar ut angriparens värde från den interna supersnabba cacheplatsen och lägger in det nya värdet, offrets värde, där.

Och vad dessa forskare upptäckte (och så långsökt som attacken låter i teorin och är i praktiken, det är en ganska fantastisk sak att upptäcka)...

Antalet bitar som skiljer sig mellan det gamla värdet i cachen och det nya värdet *ändrar mängden ström som krävs för att utföra cacheuppdateringsoperationen*.

Om du därför kan mäta strömförbrukningen för CPU:n tillräckligt exakt, kan du dra slutsatser om vilka datavärden som skrevs in i det interna, dolda, annars osynliga cacheminnet inuti CPU:n som CPU:n trodde inte var din sak.

Ganska spännande, Doug!

DOUG.  Utestående.

Okej, det finns vissa begränsningar.

Det avsnittet börjar: "Först och främst behöver du inte oroa dig," men också nästan alla processorer påverkas.

ANKA.  Ja, det är intressant, eller hur?

Det står "först av allt" (normal text) "dig" (i kursiv) "behöver inte oroa dig" (i fetstil). [SKratt]

Så, i princip, kommer ingen att attackera dig med detta, men kanske CPU-designerna vill tänka på detta i framtiden om det finns någon väg runt det. [SKratt]

Jag tyckte det var ett intressant sätt att uttrycka det.

DOUG.  OK, så begränsningen är i princip att stänga av hypertrådning.

Är det så det fungerar?

ANKA.  Hyperthreading gör det här mycket värre, så vitt jag kan se.

Vi vet redan att hyperthreading är ett säkerhetsproblem eftersom det har funnits många sårbarheter som beror på det tidigare.

Det är där en CPU, säg, med åtta kärnor låtsas ha 16 kärnor, men de är faktiskt inte i separata delar av chippet.

De är faktiskt par av slags pseudokärnor som delar mer elektronik, fler transistorer, fler kondensatorer än vad som kanske är en bra idé av säkerhetsskäl.

Om du kör gamla goda OpenBSD, tror jag att de bestämde att hypertrådning helt enkelt är för svårt att säkra med begränsningar; kan lika gärna stänga av den.

När du har fått de prestandaträffar som begränsningarna kräver kan du lika gärna helt enkelt inte ha det.

Så det tycker jag stänga av hyperthreading kommer att kraftigt immunisera dig mot denna attack.

Det andra du kan göra är, som författarna säger i fet stil: oroa dig inte. [SKRATT]

DOUG.  Det är en stor mildring! [SKratt]

ANKA.   Det finns en hel del (jag måste läsa upp det här, Doug)...

Det finns en stor del där forskarna själva fann att för att få någon form av pålitlig information överhuvudtaget fick de datahastigheter på någonstans mellan 10 bitar och 100 bitar per timme ut ur systemet.

Jag tror att åtminstone Intel-processorer har en begränsning som jag tror skulle hjälpa mot detta.

Och detta för oss tillbaka till MSR, de modellspecifika registren som vi pratade om förra veckan med Zenbleed, där det fanns en magisk bit som du kunde slå på som sa: "Gör inte de riskabla grejerna."

Det finns en funktion som du kan ställa in som kallas RAPL-filtrering, och RAPL är en förkortning för löpande medeleffektgräns.

Den används av program som vill se hur en CPU presterar för strömhanteringsändamål, så du behöver inte bryta dig in i serverrummet och sätta en strömmonitor på en kabel med en liten sond på moderkortet. [SKratt]

Du kan faktiskt få CPU:n att berätta hur mycket ström den använder.

Intel har åtminstone det här läget som kallas RAPL-filtrering, som medvetet introducerar jitter eller fel.

Så du kommer att få resultat som i genomsnitt är korrekta, men där varje enskild läsning kommer att vara avstängd.

DOUG.  Låt oss nu rikta uppmärksamheten mot detta nya SEC-avtal.

Security and Exchange Commission kräver fyra dagars avslöjandegränser för cybersäkerhetsbrott:

SEC kräver fyra dagars avslöjandegräns för cybersäkerhetsbrott

Men (A) du får bestämma om en attack är tillräckligt allvarlig för att rapportera, och (B) fyradagarsgränsen börjar inte förrän du bestämmer dig för att något är tillräckligt viktigt att rapportera, Paul.

Så, en bra första start, men kanske inte så aggressiv som vi skulle vilja?

ANKA.  Jag håller med om din bedömning där, Doug.

Det lät bra när jag först tittade på det: "Hej, du har den här fyra dagar långa avslöjandet om du har ett dataintrång eller ett cybersäkerhetsproblem."

Men så var det den här biten om, "Ja, det måste betraktas som ett materiellt problem", en juridisk term som betyder att det faktiskt är tillräckligt viktigt för att vara värt att avslöja i första hand.

Och sedan kom jag till den biten (och det är inte ett särskilt långt pressmeddelande från SEC) som typ sa: "Så fort du har bestämt dig för att du verkligen borde rapportera detta, har du fortfarande fyra dagar på dig att anmäla det."

Nu föreställer jag mig att det inte riktigt är så det kommer att fungera rent juridiskt. Doug

Kanske är vi lite hårda i artikeln?

DOUG.  Du zoomar in på ransomware-attacker och säger att det finns några olika typer, så låt oss prata om det... det är viktigt för att avgöra om detta är en materiell attack som du behöver rapportera.

Så vilken typ av ransomware tittar vi på?

ANKA.  Ja, bara för att förklara, jag trodde att det var en viktig del av det här.

Inte för att peka finger åt SEC, men det här är något som inte verkar ha kommit ut i tvätten i många eller några länder ännu...

…om att bara drabbas av en ransomware-attack oundvikligen räcker för att vara ett väsentligt dataintrång.

Detta SEC-dokument nämner faktiskt inte "R-ordet" alls.

Det nämns inget om ransomware-specifika saker.

Och ransomware är ett problem, eller hur?

I artikeln ville jag förtydliga att ordet "ransomware", som vi fortfarande använder flitigt, inte är riktigt rätt ord längre, eller hur?

Vi borde nog kalla det "utpressningsprogram" eller helt enkelt "cyberextortion".

Jag identifierar tre huvudtyper av ransomware-attacker.

Typ A är där skurkarna inte stjäl din data, de får bara förvränga din data på plats.

Så de behöver inte ladda upp en enda sak.

De förvränger allt på ett sätt så att de kan förse dig med dekrypteringsnyckeln, men du kommer inte att se en enda byte med data som lämnar ditt nätverk som ett tecken på att något dåligt är på gång.

Sedan finns det en typ B ransomware-attack, där skurkarna säger: "Vet du vad, vi kommer inte att riskera att skriva till alla filer och bli ertappad när vi gör det. Vi kommer bara att stjäla all data, och istället för att betala pengarna för att få tillbaka din data, betalar du för vår tystnad.”

Och så, naturligtvis, finns det typ C ransomware-attacken, och det är: "Både A och B."

Det är där skurkarna stjäl din data *och* de förvränger den och de säger: "Hej, om det inte är en sak som kommer att få dig i trubbel, så är det den andra."

Och det skulle vara trevligt att veta var det jag tror att advokatkåren kallar materialitet (med andra ord den juridiska betydelsen eller den juridiska relevansen för en viss förordning)...

… där det slår in, i fallet med ransomware-attacker.

DOUG.  Tja, det här är ett bra tillfälle att ta in vår Veckans kommentator, Adam, om den här historien.

Adam ger sina tankar om de olika typerna av ransomware-attacker.

Så, till att börja med typ A, där det bara är en okomplicerad ransomware-attack, där de låser upp filerna och lämnar en lösensumma för att få dem upplåsta...

Adam säger:

Om ett företag drabbas av ransomware, inte hittade några bevis för dataexfiltrering efter en grundlig undersökning och återställde sina data utan att betala lösen, då skulle jag vara benägen att säga, "Ingen [avslöjande behövs]."

ANKA.  Har du gjort tillräckligt?

DOUG.  Ja.

ANKA.  Du förhindrade det inte riktigt, men du gjorde det näst bästa, så du behöver inte berätta för dina investerare...

Det ironiska är, Doug, om du hade gjort det som företag skulle du kanske vilja säga till dina investerare: "Hej, gissa vad? Vi hade en ransomware-attack som alla andra, men vi kom ur den utan att betala pengarna, utan att engagera oss med skurkarna och utan att förlora någon data. Så även om vi inte var perfekta var vi det näst bästa.”

Och det kan faktiskt väga tungt att avslöja det frivilligt, även om lagen sa att du inte behövde det.

DOUG.  Och sedan, för typ B, utpressningsvinkeln, säger Adam:

Det är en knepig situation.

Teoretiskt skulle jag säga "Ja."

Men det kommer sannolikt att leda till många avslöjanden och skadat affärsrykte.

Så, om du har ett gäng företag som kommer ut och säger, "Titta, vi drabbades av ransomware; vi tror inte att något dåligt hände; vi betalade skurkarna för att hålla dem tysta; och vi litar på att de inte kommer att spilla bönorna, så att säga...

…det skapar en knepig situation, eftersom det kan skada ett företags rykte, men hade de inte avslöjat det, skulle ingen veta.

ANKA.  Och jag ser att Adam kände på samma sätt som både du och jag gjorde när det gällde: "Du har fyra dagar, och inte mer än fyra dagar... från det ögonblick du tror att de fyra dagarna ska börja."

Han mullrade det också, eller hur?

Han sade:

Vissa företag kommer sannolikt att anta taktik för att avsevärt fördröja beslutet om det finns en väsentlig påverkan.

Så vi vet inte riktigt hur det här kommer att gå, och jag är säker på att SEC inte riktigt vet heller.

Det kan ta ett par testfall för dem att ta reda på vad som är rätt mängd byråkrati för att se till att vi alla lär oss det vi behöver veta, utan att tvinga företag att avslöja varje litet IT-fel som någonsin händer och begrava oss alla i en mängd pappersarbete.

Vilket i huvudsak leder till bryttrötthet, eller hur?

Om du har så mycket dåliga nyheter som inte är särskilt viktiga, skölj bara över dig...

…på något sätt är det lätt att missa de riktigt viktiga sakerna som finns bland alla "behövde jag verkligen höra om det?"

Det får tiden utvisa, Douglas.

DOUG.  Ja, knepigt!

Och jag vet att jag säger detta hela tiden, men vi kommer att hålla ett öga på detta, för det kommer att bli fascinerande att se detta utvecklas.

Så tack, Adam, för att du skickade in den kommentaren.

ANKA.  Ja verkligen!

DOUG.  Om du har en intressant historia, kommentar eller fråga som du vill skicka in, läser vi gärna på podden.

Du kan skicka e-post till tips@sophos.com, du kan kommentera någon av våra artiklar, eller så kan du kontakta oss på sociala medier: @nakedsecurity.

Det är vår show för idag; tack så mycket för att du lyssnade.

För Paul Ducklin, jag heter Doug Aamoth, påminner dig tills nästa gång att...

BÅDE.  Håll dig säker.

[MUSIKALT MODEM]