S3 Ep112: Az adatszivárgás többször is kísérthet! [Hang + szöveg]

Forrás csomópont: 1769637

ADATKEZELÉS – A SZÍPÉS A FAROKBAN

Kattintson és húzza az alábbi hanghullámokat, hogy bármelyik pontra ugorjon. Te is hallgatni közvetlenül a Soundcloudon.

Doug Aamoth-tal és Paul Ducklinnal. Intro és outro zene szerzője Edith Mudge.

Tovább hallgathatsz minket Soundcloudon, Apple Podcastok, Google Podcastok, Spotify, Fűzőgép és bárhol, ahol jó podcastok találhatók. Vagy csak dobd le a RSS hírfolyamunk URL-je a kedvenc podcatcheredbe.


OLVASSA EL AZ ÍRÁST

DOUG.  SIM-csere, nulla napok, [drámai hang] Ping of DEATH, és LastPass… újra.

Mindez, és még sok más, a Naked Security podcastban.

[ZENEI MODEM]

Üdvözlünk mindenkit a podcastban.

Doug Aamoth vagyok.

Velem, mint mindig, Paul Ducklin.

Paul, hogy vagy?


KACSA.  Nagyon jól, Doug.

Magas drámai hangzást adtál ebbe a bevezetőbe, örömmel látom!


DOUG.  Nos, hogyan mondod azt, hogy „Ping of Death” anélkül, hogy azt mondanád [doom metal morgás] „Ping of DEATH”?

Nem mondhatod csak úgy [szelíd hangon], hogy „Ping of Death”.

Ki kell ütni egy kicsit…


KACSA.  Azt hiszem, így.

Írásban más a helyzet – mi van?

Félkövér és dőlt.

Csak normál szöveggel mentem, de nagybetűket használtam, ami segít.


DOUG.  Igen, azt hiszem, félkövér és dőlt betűvel szedném a „death” szót, így [megint doom metal] „The Ping of DEATH”.


KACSA.  És használj több színt!

Legközelebb megteszem, Doug.


DOUG.  Törd ki a régit címkét a HTML-ben, villogtat egy kicsit? [NEvet]


KACSA.  Doug, egy pillanatig aggódtam, hogy ezt a szót fogod használni [NEvet] .


DOUG.  [NEVETÉS] Szeretjük a régi dolgokat!

És ez szépen illeszkedik a miénkhez Ezen a héten a technikatörténetben szegmens – Izgatott vagyok, mert nem hallottam róla, de véletlenül belebotlottam.

Ezen a héten, 04. december 2001-én a Goner féreg olyan ütemben dúlta fel az internetet, mint a Love Bug vírus.

Goner a Microsoft Outlookon keresztül terjedt el, és a gyanútlan áldozatoknak szórakoztató képernyővédőt ígért, amikor kivégzik.


KACSA.  Halott…

Azt hiszem, azért kapta ezt a nevet, mert volt egy felugró ablak a végén, ugye, ami a Pentagont említette?

De szójátéknak szánták – ez volt a „Penta/Gone”.

Minden bizonnyal ez volt az a féreg, amely emlékeztette az embereket, hogy valójában a Windows képernyővédői csak végrehajtható programok.

Tehát, ha kifejezetten keresett .EXE fájlokat, nos, be lehet őket csomagolni .SCR (képernyővédő) fájlokat is.

Ha csak a fájlnevekre hagyatkozna, könnyen becsaphat.

És sokan voltak, sajnos.


DOUG.  Rendben, átmegyünk a régi iskolából az új iskolába.

A LastPass-ról beszélünk: szabálysértés történt; maga a törés nem volt szörnyű; de ez a jogsértés most újabb jogsértéshez vezetett.

Vagy talán ez csak az eredeti jogsértés folytatása?

A LastPass elismeri, hogy az ügyféladatokat a korábbi incidens okozta


KACSA.  Igen, a LastPass lényegében az előző jogsértés folytatásaként írt róla, ami szerintem 2022 augusztusa volt, nem?

És ahogy annak idején mondtuk, nagyon kínos megjelenés volt a LastPass számára.

De ahogy a jogsértések mennek, valószínűleg rosszabb volt a PR, a marketing és (azt hiszem) a szellemi tulajdonnal foglalkozó részlegük, mert úgy tűnik, hogy a szélhámosok főként a fejlesztői rendszerük forráskódja volt.

A LastPass pedig gyorsan megnyugtatta az embereket…

Először is, a vizsgálataik azt sugallták, hogy amíg bent voltak, a csalók nem tudtak olyan illetéktelen változtatásokat végrehajtani, amelyek később beszivároghatnának a valódi kódba.

Másodszor, a fejlesztői rendszerhez való hozzáférés nem ad hozzáférést az éles rendszerhez, ahol a tényleges kód épül.

Harmadszor pedig azt tudták mondani, hogy úgy tűnt, hogy nem loptak el titkosított jelszótárolókat, így a titkosított jelszavak felhőalapú tárhelyéhez nem fértek hozzá.

És még ha hozzá is fértek volna, akkor is csak te tudnád a jelszót, mert a visszafejtés (amit te „nehéz emelésnek” neveztél, amikor a podcastban beszéltünk róla) valójában az eszközeid memóriájában történik – a LastPass soha nem látja Jelszó.

Aztán negyedszer azt mondták, hogy amennyire meg tudjuk állapítani, a jogsértés eredményeként a fejlesztői környezetben lévő cuccok egy része mostanra ugyanazt adta… vagy esetleg teljesen más csalók tömegét, akik megvették a lopott adatokat az előző tételről, ki tudja?

Ez lehetővé tette számukra, hogy bejussanak egy felhőszolgáltatásba, ahol elloptak néhány, még nyilvánvalóan ismeretlen ügyféladat-készletet.

Azt hiszem, még nem tudják egészen, mert eltarthat egy ideig, amíg kiderítik, hogy mihez fértek hozzá a jogsértés megtörténte után.

Tehát úgy gondolom, jogos azt mondani, hogy ez egyfajta B-oldala az eredeti jogsértésnek.


DOUG.  Rendben, azt javasoljuk, hogy ha Ön LastPass-ügyfél, tartsa szemmel a vállalat biztonsági incidens jelentését.

Figyelni fogjuk ezt a történetet, mivel még csak alakul.

És ha Ön, mint Paul és én, a megélhetésért küzd a kiberbűnözés ellen, van néhány kiváló tanulság az Uber-sértésből.

Tehát ez egy podcast epizód – egy „minizód” – Chester Wisniewskivel, amelyet Paul beágyazott a LastPass cikk aljába:

S3 Ep100.5: Uber megsértése – egy szakértő beszél [Hang + szöveg]

Rengeteg tanulnivaló ezen a téren!


KACSA.  Ahogy mondod, nagyszerű hallgatni, mert szerintem ez az, amit Amerikában „cselekvendő tanácsként” vagy „hasznosítható hírként” ismernek.


DOUG.  [NEvet] Csodálatos.

Ha már a nem igazán használható hírekről beszélünk, az Apple általában szűkszavú a biztonsági frissítéseivel kapcsolatban… és volt egy biztonsági frissítés:

Az Apple kiadta az iOS biztonsági frissítését, amely minden eddiginél szűkszavúbb


KACSA.  Ó, Doug, ez az egyik legjobb... Tetszik ez a lépés.


DOUG.  [NEVETÉS] Köszönöm; nagyon szépen köszönjük.


KACSA.  Igen, ez meglepett.

Azt gondoltam: "Nos, megragadom a frissítést, mert komolyan hangzik."

És megadtam magamnak az okot: „Hadd tegyem meg a Naked Security olvasóiért.”

Mert ha megcsinálom, és nincsenek mellékhatásai, akkor legalább azt mondhatom másoknak: „Nézd, csak vakon csináltam, és nem történt semmi bántódásom. Szóval talán te is meg tudod csinálni."

Hirtelen észrevettem, hogy elérhető egy iOS 16.1.2-es frissítés, bár nem kaptam biztonsági e-mailt az Apple-től.

Nincs e-mail?!

Ez furcsa.. ezért elmentem a HT201222 portáloldal, amelyet az Apple a biztonsági közleményeihez készít, és ott ez volt: iOS 16.1.2.

És mit mond, Doug: „A részletek hamarosan jelentkeznek”?


DOUG.  És hamarosan követték?


KACSA.  Nos, ez több mint egy hete volt, és még nincsenek ott.

Tehát a „hamarosan” kifejezés órákat, napokat, heteket vagy hónapokat jelent?

Jelenleg úgy néz ki, mint hetek.

És mint mindig az Apple esetében, semmi jele annak, hogy bármi köze lenne más operációs rendszerekhez.

Feledésbe merültek?

Nem kell nekik a frissítés?

Nekik is kellett a frissítés, de még nincs kész?

Kiestek a támogatásból?

De úgy tűnt, ahogy a címben is mondtam, még szűkszavúbbnak, mint általában az Apple számára, és nem feltétlenül a leghasznosabb dolognak a világon.


DOUG.  Rendben, nagyon jó… van még néhány kérdés, ami elvezet minket a következő történetünkhöz.

Nagyon érdekes kérdés!

Néha, amikor feliratkozik egy szolgáltatásra, amely kétlépcsős hitelesítést kényszerít ki, azt mondja: „Sms-ben szeretne értesítést kapni, vagy hitelesítő alkalmazást szeretne használni?”

Ez a történet pedig egy figyelmeztető mese, hogy ne használja a telefont – használjon hitelesítő alkalmazást, még akkor is, ha az egy kicsit körülményesebb.

Ez egy nagyon érdekes történet:

Börtönbe küldték a SIM-cserélőt 2 millió dollár feletti kriptovaluta-rablás miatt


KACSA.  Az, Doug!

Ha valaha is elveszítette mobiltelefonját, vagy túl sokszor hibásan írta be a PIN-kódot, úgy zárta ki magát a SIM-kártyájából, tudja, hogy betérhet a mobiltelefon boltba…

…és általában igazolványt vagy ilyesmit kérnek, te pedig azt mondod: "Hé, új SIM-kártyára van szükségem."

És generálnak egyet neked.

Amikor beteszed a telefonodba, bingó!… a régi számod van rajta.

Tehát ez azt jelenti, hogy ha egy szélhámos ugyanazon a gyakorlaton megy keresztül, mint amivel Ön meggyőzné a mobiltelefon-társaságot arról, hogy „elvesztette” vagy „eltörte” a SIM-kártyáját (azaz *az Ön SIM-kártyáját*), és megkaphatja. azt a kártyát vagy odaadták, vagy elküldték nekik, vagy valahogy odaadták nekik…

…majd amikor csatlakoztatják a telefonjukhoz, megkapják az SMS-ben a kétfaktoros hitelesítési kódokat, *és* telefonja leáll.

Ez a rossz hír.

A jó hír ebben a cikkben az, hogy ez egy fickó esete volt, akit emiatt lebuktak.

18 hónapra börtönbe került az Egyesült Államokban.

Ő egy csomó cinkossal – vagy az Igazságügyi Minisztérium szavaival élve a A rendszer résztvevői… [NEvet]

…egy bizonyos áldozat kriptovalutájával búcsúztak, látszólag 20 millió dollár értékben, ha nem bánod.


DOUG.  Hoppá!


KACSA.  Így hát beleegyezett, hogy bűnösnek vallja magát, börtönbüntetést szab ki, és azonnal elveszíti… az összeg [figyelmesen olvasva] 983,010.72 XNUMX dollár volt… csak hogy azonnal elveszítse.

Tehát feltehetően ott hevert.

És nyilvánvalóan valamilyen jogi kötelezettsége is van több mint 20 millió dollár visszatérítésére.


DOUG.  Sok sikert ehhez mindenkinek! Sok szerencsét.

A másik [vokális dőlt betűs] A rendszer résztvevői problémákat okozhat! [NEvet]


KACSA.  Igen, nem tudom, mi történik, ha ők is megtagadják az együttműködést.

Például, ha kiakasztják, hogy megszáradjon, mi történik?

A cikkben azonban találunk néhány tippet és tanácsot a biztonság fokozásához (többféleképpen, mint az Ön által használt 2FA).

Szóval menj és olvasd el… minden apróság segít.


DOUG.  Oké, ha már az „apróságokról” beszélünk…

…ez egy másik lenyűgöző történet volt, hogy mennyire alázatosak ping távoli kódvégrehajtás indítására használható:

Halál ping! A FreeBSD kijavítja a hálózati eszköz katasztrofális hibáját


KACSA.  [Ismét tetszik a folytatás] Azt hiszem, javítottad magad, Doug!


DOUG.  [NEVESZ] Ma gurulok…


KACSA.  Az Apple-től a [gyenge kísérlet a doom-énekre] Ping of DEATH!

Igen, ez egy érdekes hiba volt.

Nem hiszem, hogy ez sok embernek sok kárt okozna, és * van* foltozva, így a javítása egyszerű.

De van egy nagyszerű írás a FreeBSD-ben biztonsági tanácsadás...

…és ez egy szórakoztató, és ha magam mondom, nagyon informatív történet a programozók jelenlegi generációja számára, akik bízhattak abban, hogy „A harmadik féltől származó könyvtárak megteszik helyettem. Alacsony szintű hálózati csomagokkal foglalkozik? Soha nem kell ezen gondolkodnom…”

Van itt néhány nagyszerű tanulság.

A ping segédprogram, amely az egyetlen hálózati eszköz, amelyet nagyjából mindenki tud róla, a nevét a SONAR-ról kapta.

Menj [film tengeralattjáró zajt ad] ping, majd a visszhang visszajön a másik végén lévő szerverről.

És ez egy olyan szolgáltatás, amely az Internet Protocol-ba, az IP-be van beépítve, egy ICMP nevű dologgal, ami az Internet Control Message Protocol.

Ez egy speciális, alacsony szintű protokoll, sokkal alacsonyabb, mint az UDP vagy a TCP, amit valószínűleg megszoktak az emberek, és nagyjából pontosan ilyen dolgokra tervezték: „Tényleg életben vagy a másik végén, mielőtt azon aggódnék, hogy miért nem működik a webszervere?”

Létezik egy speciális csomag, amelyet kiküldhet, „ICMP Echo” néven.

Tehát elküldöd ezt az apró kis csomagot egy rövid üzenettel (az üzenet bármi lehet, amit akarsz), és ez egyszerűen ugyanazt az üzenetet küldi vissza neked.

Ez csak egy alapvető módja annak, hogy kimondja: „Ha az üzenet nem jön vissza, akkor vagy a hálózat, vagy az egész szerver nem működik”, ahelyett, hogy valami szoftverprobléma lenne a számítógépen.

A SONAR analógiájára a visszhangkéréseket küldő program neve… [szünet] Megcsinálom a hangeffektust, Doug… [megint hamis tengeralattjáró filmzaj] ping. [NEVETÉS]

És az ötlet az, hogy menj, mondd, ping -c3 (azaz háromszor ellenőrizze) nakedsecurity.sophos.com.

Ezt most megteheti, és három választ kell kapnia, mindegyik egy másodperc különbséggel a webhelyünket kiszolgáló WordPress-kiszolgálóktól.

És azt mondja, hogy az oldal él.

Ez nem azt jelenti, hogy a webszerver működik; ez nem azt jelenti, hogy a WordPress elkészült; ez nem azt mutatja, hogy a Naked Security valóban olvasható.

De ez legalább megerősíti, hogy látja a szervert, és a szerver el tud érni.

És ki gondolta volna, hogy ez az alázatos kis ping válasz megbotolhatja a FreeBSD-t ping program oly módon, hogy egy szélhámos szerver visszaküldhetne egy csapdába esett „Igen, élek” üzenetet, amely elméletben (csak elméletben; nem hiszem, hogy a gyakorlatban ezt senki sem tette meg) távoli kódfuttatást válthat ki a számítógéped.


DOUG.  Igen, ez csodálatos; ez a csodálatos része.

Még akkor is, ha ez egy fogalombizonyítvány, olyan apróság!


KACSA.  A ping maga a program visszakapja a teljes IP-csomagot, és állítólag két részre osztja.

Általában a kernel kezeli ezt helyetted, tehát csak az adatrészt látod.

De amikor az ún nyers foglalatok, amit visszakap, az az Internet Protocol fejléc, amely csak annyit mond: „Hé, ezek a bájtok egy ilyen és egy ilyen szerverről származnak.”

Aztán kapsz egy „ICMP Echo Reply” nevű dolgot, ami a visszakapott csomag második fele.

Nos, ezek a csomagok általában csak 100 bájtosak, és ha IPv4-ről van szó, akkor az első 20 bájt az IP-fejléc, a maradék pedig, bármi legyen is, az Echo Reply.

Ebben van néhány bájt a következő szöveggel: „Ez egy visszhangválasz”, majd az eredeti üzenet, amely kiment, visszajön.

És hát az nyilvánvaló, Doug, ha megkapod, felosztod…

…az IP-fejléc, amely 20 bájt hosszú, és a többi.

Találd ki, hol a probléma?


DOUG.  Mondd meg!


KACSA.  A probléma az, hogy az IP-fejlécek *majdnem mindig* 20 bájt hosszúak – sőt, azt hiszem, még soha nem láttam olyat, amely ne lett volna az.

És láthatod, hogy 20 bájt hosszúak, mert az első bájt hexadecimális lesz 0x45.

A „4” az IPv4-et jelenti, az „5” pedig… „Ó, ezzel fogjuk megmondani, milyen hosszú a fejléc.”

Vedd azt az 5-ös számot, és megszorozod 4-gyel (32 bites értékek esetén), és 20 bájtot kapsz.

…és ez akkora, mint valószínűleg hat szigma értékű IP-fejléc, amit valaha is látni fogsz az egész világon, Doug. [NEVETÉS]

De akár 60 bájtig *mehetnek*.

Ha beteszed 0x4F helyett 0x45, vagyis a fejlécben 0xF (vagy 15 decimális) × 4 = 60 bájt van.

A FreeBSD-kód pedig egyszerűen vette ezt a fejlécet, és bemásolta a verem 20 bájt méretű pufferébe.

Egyszerű, régi iskolai verempuffer túlcsordulás.

Ez egy tiszteletreméltó hálózati hibaelhárító eszköz esete, amelyben egy tiszteletreméltó típusú hiba található. (Nos, már nem.)

Tehát, amikor programozunk, és olyan alacsony szintű dolgokkal kell megküzdeniük, amelyekre már régóta senki sem gondolt, ne csak a kapott bölcsességgel éljen, amely azt mondja: „Ó, ez mindig 20 bájt lesz; soha nem fogsz látni nagyobbat."

Mert egy napon lehet.

És amikor eljön az a nap, lehet, hogy szándékosan volt ott, mert egy szélhámos tette szándékosan azzá.

Tehát az ördög, mint mindig, a programozás részleteiben van, Doug.


DOUG.  Rendben, nagyon érdekes; nagyszerű történet.

A Chrome-ról szóló utolsó történettel a kód témánál maradunk.

Újabb nulladik nap, amivel a 2022-es összesítés kilencszeresére nő:

Kilences szám! A Chrome egy újabb 2022-es nulladik napot javít, az Edge is javítva


KACSA.  [Formális hang, úgy hangzik, mint egy felvétel] "9. szám. 9. szám. 9. szám, 9. szám," Douglas.


DOUG.  [NEVETÉS] Ez Yoko Ono?


KACSA.  Ez Revolution 9 le a Beatles „White Album”-ról.

Yoko hallatszik a dalban – ez hangzáskép, azt hiszem, így hívják – de úgy tűnik, az elején lévő rész, amikor valaki újra és újra azt mondja, hogy „9. szám, 9. szám”, valójában egy tesztszalag volt, amit heverni találtak.


DOUG.  Ah, nagyon klassz.


KACSA.  Egy EMI mérnök valami ilyesmit mond: „Ez a 9-es számú EMI tesztszalag” [NEVETÉS], és úgy tűnik, nem is hiszem, hogy bárki is tudja, kinek a hangja volt.

Ennek semmi köze a Chrome-hoz, Doug.

De tekintettel arra, hogy a minap valaki hozzászólt a Facebookon: „Az a Paul srác kezd úgy kinézni, mint egy Beatle”… [kvízes], amit kissé furcsának találtam.


DOUG.  [NEVETÉS] Igen, hogyan kell ezt felfogni?


KACSA.  …Arra jutottam, hogy a „9-es számmal” étkezhetek.

Úgy tűnik, ez az év eddigi kilencedik nulladik napja, Doug.

És ez egy hibajavítás, a hibát CVE 2022-4282-ként azonosították.

Mivel a Microsoft Edge a Chromium nyílt forráskódú magot használja, ez is sebezhető volt, és néhány nappal később a Microsoft követte az Edge frissítését.

Tehát ez Chrome és Edge probléma is.

Bár ezeknek a böngészőknek frissíteniük kell magukat, azt javaslom, hogy mindenesetre ellenőrizze – a cikkben megmutatjuk, hogyan kell ezt megtenni – minden esetre.

A verziószámokat itt nem fogom felolvasni, mert más a Mac, Linux és Windows Chrome-on, és megint más az Edge esetében.

Az Apple-hez hasonlóan a Google is kissé szűkszavú ezzel kapcsolatban.

Azt hiszem, az egyik fenyegetésvadász csapatuk találta meg.

Tehát úgy gondolom, hogy egy vadonban történt incidens nyomozása közben találtak rá, és ezért valószínűleg a kalapjuk alatt akarják tartani, pedig a Google rendszerint sokat mond a „nyitottságról”, ha hibajavításról van szó.

Láthatja, hogy egy ilyen esetben miért van szüksége egy kis időre, hogy egy kicsit mélyebbre ásson, mielőtt elmondja mindenkinek, hogyan működik pontosan.


DOUG.  Kiváló… és van egy olvasói kérdésünk, amely valószínűleg sok emberben felmerül.

Cassandra megkérdezi: „A hibakeresőknek csak szerencséjük van a hibák megtalálásában? Vagy egy "varrat" tele van hibákkal? Vagy a Chromium olyan új kódot ad ki, amely a szokásosnál hibásabb? Vagy valami más történik?”


KACSA.  Igen, ez egy nagyszerű kérdés, és attól tartok, hogy csak kissé elgondolkodtató módon tudnék rá válaszolni, Doug.

Mivel Cassandra megadta az A), B) és C) lehetőséget, azt mondtam: „Nos, talán így van D) A fentiek mindegyike."

Tudjuk, hogy ha egy bizonyos fajta hiba jelenik meg a kódban, akkor ésszerűen feltételezhető, hogy ugyanaz a programozó máshol is hasonló hibákat követhetett el a szoftverben.

Vagy más programozók ugyanannál a cégnél azt használták, amit akkoriban bevett bölcsességnek vagy szokásos gyakorlatnak tekintettek, és követték a példát.

És egy nagyszerű példa, ha visszanéz a Log4J-re… volt egy javítás a probléma javítására.

Aztán, amikor elmentek nézni, "Ó, valójában vannak más helyek is, ahol hasonló hibákat követtek el."

Tehát volt egy javítás a javításhoz, majd volt egy javítás a javításhoz, ha jól emlékszem.

Természetesen az is probléma, hogy amikor új kódot ad hozzá, olyan hibákat kaphat, amelyek egyediek az új kódhoz, és a funkciók hozzáadásával jönnek létre.

És ez az oka annak, hogy sok böngészőnek, beleértve a Chrome-ot is, van egy „kicsit régebbi” verziója, amelyhez ragaszkodhat.

És az ötlet az, hogy ezek a „régebbi” kiadások… semmi új funkciót nem tartalmaznak, csak az összes vonatkozó biztonsági javítást.

Tehát, ha konzervatív szeretne lenni az új funkciókkal kapcsolatban, megteheti.

De biztosan tudjuk, hogy néha, amikor új funkciókat lapátol bele egy termékbe, új hibák jönnek az új funkciókkal együtt.

És ezt például akkor lehet tudni, ha frissítés érkezik, mondjuk az iPhone-hoz, és frissítéseket kap, mondjuk az iOS 15 és iOS 16 rendszerhez.

Aztán, ha megnézi a hibalistákat, kevés olyan hiba van, amely csak az iOS 16-ra vonatkozik.

És azt gondolja: „Helló, ezek bizonyára olyan hibák a kódban, amelyek korábban nem voltak ott.”

Szóval igen, ez egy lehetőség.

És azt hiszem, a többi dolog, ami folyik, jónak tekinthető.

Az első az, hogy úgy gondolom, hogy különösen az olyan dolgok esetében, mint a böngészők, a böngészőgyártók egyre jobban teljesítik a teljes újraépítést, nagyon-nagyon gyorsan.


DOUG.  Érdekes.


KACSA.  És azt hiszem, a másik dolog, ami megváltozott, az az, hogy a múltban vitatkozni lehetett azzal, hogy sok eladó számára… meglehetősen nehéz volt rávenni az embereket, hogy egyáltalán alkalmazzanak javításokat, még akkor is, ha csak havi ütemezés szerint jelentek meg, és még akkor is, ha több nulladik napi javítás volt bennük.

Azt hiszem, ez talán egy válasz arra is, hogy egyre többen és egyre inkább nem csak elfogadják, hanem *elvárják* az igazán gyors automatikus frissítést.

Szóval szerintem jó dolgokat olvashatsz ebből.

Nemcsak az a tény, hogy a Google szinte azonnal ki tud nyomni egyetlen nulladik napi javítást, hanem az is, hogy az emberek ezt hajlandók elfogadni, sőt követelni is.

Szóval szeretem látni azt a kérdést: „Hú, az év kilenc nulladik napját külön-külön rögzítik!”…

…szeretem ezt inkább úgy gondolni, mint „félig megtölteni és feltölteni az üveget”, mint „félig üres pohár, és egy kis lyukon keresztül kiüríteni az alján”. [NEVETÉS]

Ez az én véleményem.


DOUG.  Rendben, nagyon jó.

Köszönöm a kérdést, Cassandra.

Ha van egy érdekes története, megjegyzése vagy kérdése, amelyet fel szeretne tenni, azt szívesen olvassuk a podcastban.

Írhat e-mailt a tips@sophos.com címre, kommentálhatja bármelyik cikkünket, vagy felkereshet minket a közösségi oldalon: @NakedSecurity.

Ez a mai műsorunk; köszönöm szépen, hogy meghallgattál.

For Paul Ducklin, I’m Doug Aamoth, reminding you: Until next time…


MINDKÉT.  Maradjon biztonságban!

[ZENEI MODEM]


Időbélyeg:

Még több Meztelen biztonság