S3 Ep112: Pelanggaran data dapat menghantui Anda lebih dari satu kali! [Audio + Teks]

Node Sumber: 1769637

PELANGGARAN DATA – SENGATAN DI TAIL

Klik-dan-tarik gelombang suara di bawah untuk melompat ke titik mana pun. Anda juga bisa dengarkan langsung di Soundcloud.

Dengan Doug Aamoth dan Paul Ducklin. Musik intro dan outro oleh Edith Mudge.

Anda dapat mendengarkan kami di SoundCloud, Podcast Apple, Google Podcast, Spotify, Mesin penjahit dan di mana pun podcast bagus ditemukan. Atau jatuhkan saja URL umpan RSS kami ke dalam podcatcher favorit Anda.


BACA TRANSKRIPNYA

ANJING.  Pertukaran SIM, zero-days, [suara dramatis] Ping of DEATH, dan LastPass… lagi.

Semua itu, dan banyak lagi, di podcast Naked Security.

[MODEM MUSIK]

Selamat datang di podcast semuanya.

Saya Doug Aamoth.

Dengan saya, seperti biasa, adalah Paul Ducklin.

Paulus, bagaimana kabarmu?


BEBEK.  Baiklah, Doug.

Anda memasukkan suara drama tinggi ke dalam intro itu, saya senang melihatnya!


ANJING.  Nah, bagaimana Anda mengatakan "Ping of Death" tanpa mengatakan [doom metal growl] "Ping of DEATH"?

Anda tidak bisa hanya mengatakan [suara lembut] "Ping of Death".

Anda harus memukulnya sedikit…


BEBEK.  Saya rasa begitu.

Ini berbeda dalam menulis – apa yang Anda punya?

Tebal dan miring.

Saya hanya menggunakan teks biasa, tetapi saya menggunakan huruf kapital, yang membantu.


ANJING.  Ya, saya pikir saya akan menebalkan dan memiringkan kata "kematian", jadi [doom metal lagi] "The Ping of DEATH".


BEBEK.  Dan gunakan banyak warna!

Aku akan melakukannya lain kali, Doug.


ANJING.  Hancurkan yang lama tag dalam HTML, membuatnya berkedip sedikit? [TERTAWA]


BEBEK.  Doug, untuk sesaat, saya khawatir Anda akan menggunakan kata [TERTAWA] .


ANJING.  [TERTAWA] Kami menyukai barang-barang lama di sini!

Dan itu sangat cocok dengan milik kita Minggu ini dalam Sejarah Teknologi segmen – Saya senang dengan yang ini karena saya belum pernah mendengarnya, tetapi tidak sengaja menemukannya.

Minggu ini, pada tanggal 04 Desember 2001, worm Goner mengobrak-abrik internet dengan kecepatan kedua setelah virus Love Bug.

Goner menyebar melalui Microsoft Outlook, dan menjanjikan screen saver yang menyenangkan kepada para korban yang tidak menaruh curiga saat dieksekusi.


BEBEK.  Seorang yg amblas…

Saya pikir itu mendapat nama itu karena ada popup di bagian akhir, bukan, yang menyebutkan Pentagon?

Tapi itu dimaksudkan untuk menjadi permainan kata – itu adalah “Penta/Gone”.

Itu pasti worm yang mengingatkan orang bahwa sebenarnya screensaver Windows hanyalah program yang dapat dieksekusi.

Jadi, jika Anda mencari secara khusus .EXE file, yah, mereka bisa dibungkus .SCR (screensaver) file juga.

Jika Anda hanya mengandalkan nama file, Anda bisa dengan mudah tertipu.

Dan banyak orang, sayangnya.


ANJING.  Baiklah, kita akan beralih dari sekolah lama ke sekolah baru.

Kita berbicara tentang LastPass: ada pelanggaran; pelanggaran itu sendiri tidak buruk; tetapi pelanggaran itu sekarang telah menyebabkan pelanggaran lain.

Atau mungkin ini hanya kelanjutan dari pelanggaran awal?

LastPass mengakui pelanggaran data pelanggan yang disebabkan oleh pelanggaran sebelumnya


BEBEK.  Ya, LastPass telah menulis tentangnya pada dasarnya sebagai tindak lanjut dari pelanggaran sebelumnya, yang menurut saya adalah Agustus 2022, bukan?

Dan seperti yang kami katakan saat itu, LastPass terlihat sangat memalukan.

Tapi saat pelanggaran terjadi, itu mungkin lebih buruk untuk PR, pemasaran, dan (saya kira) untuk departemen kekayaan intelektual mereka, karena tampaknya hal utama yang dilakukan penjahat adalah kode sumber dari sistem pengembangan mereka.

Dan LastPass dengan cepat meyakinkan orang…

Pertama, penyelidikan mereka menunjukkan bahwa, ketika mereka berada di sana, para penjahat tidak dapat membuat perubahan tidak sah yang nantinya dapat meresap ke dalam kode sebenarnya.

Kedua, akses ke sistem pengembangan tidak memberi Anda akses ke sistem produksi, tempat kode sebenarnya dibuat.

Dan ketiga, mereka dapat mengatakan bahwa tampaknya tidak ada brankas kata sandi terenkripsi yang dicuri, sehingga penyimpanan cloud dari kata sandi terenkripsi Anda tidak dapat diakses.

Dan bahkan jika itu telah diakses, maka hanya Anda yang akan mengetahui kata sandinya, karena dekripsi (apa yang Anda sebut "angkat berat" ketika kami membicarakannya di podcast) sebenarnya dilakukan di memori pada perangkat Anda – LastPass tidak pernah melihat Anda kata sandi.

Dan kemudian, keempat, mereka berkata, sejauh yang kami tahu, sebagai akibat dari pelanggaran itu, beberapa hal yang ada di lingkungan pengembangan sekarang telah memberikan hal yang sama… atau mungkin beban penjahat yang sama sekali berbeda yang membeli data yang dicuri dari lot sebelumnya, siapa tahu?

Itu memang memungkinkan mereka untuk masuk ke beberapa layanan cloud di mana beberapa data pelanggan yang tampaknya belum diketahui dicuri.

Saya rasa mereka belum tahu, karena perlu beberapa saat untuk mengetahui apa yang sebenarnya bisa diakses setelah pelanggaran terjadi.

Jadi menurut saya adil untuk mengatakan ini adalah semacam sisi-B dari pelanggaran asli.


ANJING.  Baiklah, kami menyarankan jika Anda pelanggan LastPass, untuk mengawasi laporan insiden keamanan perusahaan.

Kami akan mengawasi cerita ini karena masih berkembang.

Dan jika Anda, seperti Paul dan saya, melawan kejahatan dunia maya untuk mencari nafkah, ada beberapa pelajaran bagus yang bisa dipetik dari pelanggaran Uber.

Jadi itulah episode podcast – sebuah “minisode” – dengan Chester Wisniewski yang disematkan Paul di bagian bawah artikel LastPass:

S3 Ep100.5: Pelanggaran Uber – seorang ahli berbicara [Audio + Teks]

Banyak yang harus dipelajari di bagian depan itu!


BEBEK.  Seperti yang Anda katakan, itu adalah mendengarkan yang bagus, karena saya yakin, inilah yang dikenal di Amerika sebagai "nasihat yang dapat ditindaklanjuti", atau "berita yang dapat Anda gunakan".


ANJING.  [TERTAWA] Luar biasa.

Berbicara tentang berita-yang-tidak-bisa-digunakan-, Apple umumnya bungkam tentang pembaruan keamanannya… dan ada pembaruan keamanan:

Apple meluncurkan pembaruan keamanan iOS yang lebih tertutup dari sebelumnya


BEBEK.  Oh, Doug, itu salah satu karya terbaikmu... Aku suka segue itu.


ANJING.  [TERTAWA] Terima kasih; terima kasih banyak.


BEBEK.  Ya, ini mengejutkan saya.

Saya berpikir, "Baiklah, saya akan mengambil pembaruan karena kedengarannya serius."

Dan saya memberi diri saya alasan, "Biarkan saya melakukannya untuk pembaca Keamanan Telanjang."

Karena jika saya melakukannya dan tidak ada efek samping, maka saya setidaknya dapat mengatakan kepada orang lain, “Lihat, saya melakukannya secara membabi buta dan tidak ada salahnya bagi saya. Jadi mungkin Anda juga bisa melakukannya.”

Saya tiba-tiba menyadari bahwa ada pembaruan iOS 16.1.2 yang tersedia, meskipun saya tidak memiliki email penasehat keamanan dari Apple.

Tidak ada email?!

Itu aneh .. jadi saya pergi ke HT201222 halaman portal yang dimiliki Apple untuk buletin keamanannya, dan itu dia: iOS 16.1.2.

Dan apa yang tertulis, Doug, "Rincian akan segera menyusul"?


ANJING.  Dan apakah mereka segera menyusul?


BEBEK.  Yah, itu sudah lebih dari seminggu yang lalu, dan mereka belum sampai.

Jadi, apakah kita berbicara "segera" yang berarti berjam-jam, berhari-hari, berminggu-minggu, atau berbulan-bulan?

Saat ini, sepertinya berminggu-minggu.

Dan, seperti biasa dengan Apple, tidak ada indikasi hubungannya dengan sistem operasi lain.

Apakah mereka telah dilupakan?

Apakah mereka tidak membutuhkan pembaruan?

Apakah mereka juga membutuhkan pembaruan, tetapi belum siap?

Apakah mereka telah keluar dari dukungan?

Tapi sepertinya, seperti yang saya katakan di judul, bahkan lebih bungkam dari biasanya untuk Apple, dan belum tentu hal yang paling membantu di dunia.


ANJING.  Oke, bagus sekali… masih ada beberapa pertanyaan, yang membawa kita ke cerita selanjutnya.

Pertanyaan yang sangat menarik!

Kadang-kadang, saat Anda mendaftar ke suatu layanan dan menerapkan autentikasi dua faktor, dikatakan, "Apakah Anda ingin mendapat pemberitahuan melalui pesan teks, atau apakah Anda ingin menggunakan aplikasi autentikasi?"

Dan kisah ini adalah kisah peringatan untuk tidak menggunakan ponsel Anda – gunakan aplikasi autentikasi, meskipun sedikit lebih rumit.

Ini adalah kisah yang sangat menarik:

Penukar SIM dikirim ke penjara karena pencurian cryptocurrency 2FA lebih dari $20 juta


BEBEK.  Ini, Doug!

Jika Anda pernah kehilangan ponsel, atau mengunci kartu SIM karena salah memasukkan PIN berkali-kali, Anda akan tahu bahwa Anda dapat pergi ke toko ponsel…

…dan biasanya mereka akan meminta ID atau semacamnya, dan Anda berkata, “Hai, saya perlu kartu SIM baru.”

Dan mereka akan menghasilkan satu untuk Anda.

Ketika Anda memasukkannya ke ponsel Anda, bingo!… ada nomor lama Anda di dalamnya.

Artinya, jika seorang penjahat dapat melakukan latihan yang sama seperti yang Anda lakukan untuk meyakinkan perusahaan telepon seluler bahwa mereka telah "kehilangan" atau "rusak" kartu SIM mereka (yaitu *kartu SIM Anda*), dan mereka bisa mendapatkan kartu itu diserahkan kepada, atau dikirim ke, atau diberikan kepada mereka entah bagaimana…

…kemudian, saat mereka menyambungkannya ke ponsel, mereka mulai mendapatkan kode autentikasi dua faktor SMS Anda, *dan* ponsel Anda berhenti berfungsi.

Itu kabar buruknya.

Kabar baiknya dalam artikel ini adalah ini adalah kasus seorang pria yang tertangkap basah karenanya.

Dia telah dikirim ke penjara di AS selama 18 bulan.

Dia, dengan sekelompok kaki tangannya – atau, menurut Departemen Kehakiman, the Peserta Skema… [TERTAWA]

…mereka kabur dengan mata uang kripto korban tertentu, tampaknya mencapai $20 juta, jika Anda tidak keberatan.


ANJING.  Aduh!


BEBEK.  Jadi dia setuju untuk mengaku bersalah, mengambil hukuman penjara, dan segera kehilangan… jumlahnya adalah [baca dengan cermat] $983,010.72… hanya untuk segera membatalkannya.

Jadi, mungkin, dia memilikinya.

Dan dia rupanya juga memiliki semacam kewajiban hukum untuk mengembalikan lebih dari $20 juta.


ANJING.  Semoga beruntung dengan itu, semuanya! Semoga beruntung.

Nya yang lain [vokal miring] Peserta Skema mungkin menyebabkan beberapa masalah di sana! [TERTAWA]


BEBEK.  Ya, saya tidak tahu apa yang terjadi jika mereka menolak untuk bekerja sama juga.

Seperti, jika mereka menjemurnya begitu saja, apa yang terjadi?

Tapi kami punya beberapa tip, dan beberapa saran tentang cara meningkatkan keamanan (lebih dari sekadar 2FA yang Anda gunakan) di artikel.

Jadi pergi dan baca itu… setiap sedikit membantu.


ANJING.  Oke, berbicara tentang "sedikit" ...

… ini adalah kisah menarik lainnya, betapa rendahnya ping dapat digunakan untuk memicu eksekusi kode jarak jauh:

Ping kematian! FreeBSD memperbaiki bug crashtastic di alat jaringan


BEBEK.  [Menyukai segue lagi] Saya pikir Anda telah menjadi lebih baik, Doug!


ANJING.  [TERTAWA] Saya sedang bersemangat hari ini…


BEBEK.  Dari Apple ke [upaya lemah pada vokal malapetaka] Ping of DEATH!

Ya, ini adalah bug yang menarik.

Saya tidak berpikir itu akan benar-benar membahayakan banyak orang, dan * sudah * ditambal, jadi memperbaikinya mudah.

Tapi ada Langganan yang bagus di FreeBSD penasehat keamanan...

… dan itu membuat menghibur, dan, jika saya mengatakannya sendiri, kisah yang sangat informatif untuk generasi pemrogram saat ini yang mungkin mengandalkan, “Perpustakaan pihak ketiga hanya akan melakukannya untuk saya. Berurusan dengan paket jaringan tingkat rendah? Aku tidak pernah memikirkannya…”

Ada beberapa pelajaran besar yang bisa dipelajari di sini.

Grafik ping utilitas, yang merupakan satu-satunya alat jaringan yang diketahui hampir semua orang, mendapatkan namanya dari SONAR.

Anda pergi [membuat kebisingan film kapal selam] ping, lalu gema kembali dari server di ujung lainnya.

Dan ini adalah fitur yang dibangun ke dalam Internet Protocol, IP, menggunakan sesuatu yang disebut ICMP, yaitu Internet Control Message Protocol.

Ini adalah protokol khusus, tingkat rendah, jauh lebih rendah daripada UDP atau TCP yang mungkin biasa digunakan orang, yang dirancang untuk hal-hal seperti ini: “Apakah Anda benar-benar masih hidup di ujung sana, sebelum saya khawatir tentang mengapa server web Anda tidak berfungsi?”

Ada jenis paket khusus yang dapat Anda kirimkan yang disebut "ICMP Echo".

Jadi, Anda mengirim paket kecil ini dengan pesan singkat di dalamnya (pesannya bisa apa saja yang Anda suka), dan itu hanya mengirimkan pesan yang sama kembali kepada Anda.

Itu hanya cara dasar untuk mengatakan, "Jika pesan itu tidak kembali, baik jaringan atau seluruh server mati", daripada ada masalah perangkat lunak di komputer.

Dengan analogi dengan SONAR, program yang mengirimkan permintaan gema ini disebut… [jeda] Saya akan melakukan efek suara, Doug… [suara film kapal selam palsu lagi] ping. [TAWA]

Dan idenya adalah, Anda pergi, katakanlah, ping -c3 (itu berarti periksa tiga kali) nakedsecurity.sophos.com.

Anda dapat melakukannya sekarang, dan Anda akan mendapatkan tiga balasan, masing-masing terpisah satu detik, dari server WordPress yang menghosting situs kami.

Dan itu mengatakan situs itu hidup.

Itu tidak memberi tahu Anda bahwa server web sedang aktif; itu tidak memberi tahu Anda bahwa WordPress sudah habis; itu tidak mengatakan bahwa Naked Security sebenarnya tersedia untuk dibaca.

Tapi setidaknya itu menegaskan bahwa Anda dapat melihat server, dan server dapat menghubungi Anda.

Dan siapa yang mengira bahwa balasan ping kecil itu bisa membuat FreeBSD tersandung ping program sedemikian rupa sehingga server jahat dapat mengirim kembali pesan jebakan "Ya, saya hidup" yang dapat, secara teori (hanya dalam teori; saya tidak berpikir ada orang yang melakukan ini dalam praktik) memicu eksekusi kode jarak jauh pada komputer Anda.


ANJING.  Ya, itu luar biasa; itulah bagian yang menakjubkan.

Bahkan jika itu adalah pembuktian konsep, itu adalah hal yang sangat kecil!


BEBEK.  Grafik ping program itu sendiri mendapatkan kembali seluruh paket IP, dan seharusnya membaginya menjadi dua bagian.

Biasanya, kernel akan menangani ini untuk Anda, jadi Anda cukup melihat bagian datanya.

Tapi ketika Anda sedang berhadapan dengan apa yang disebut soket mentah, yang Anda dapatkan kembali adalah header Protokol Internet, yang hanya mengatakan, "Hei, byte ini berasal dari server ini dan itu."

Dan kemudian Anda mendapatkan sesuatu yang disebut "ICMP Echo Reply", yang merupakan bagian kedua dari paket yang Anda dapatkan kembali.

Sekarang, paket-paket ini, biasanya hanya sekitar 100 byte, dan jika itu adalah IPv4, 20 byte pertama adalah header IP dan sisanya, apa pun itu, adalah Echo Reply.

Itu memiliki beberapa byte untuk mengatakan, "Ini adalah Balasan Echo," dan kemudian pesan asli yang keluar kembali.

Jadi hal yang jelas harus dilakukan, Doug, saat Anda mendapatkannya, adalah Anda membaginya menjadi…

… header IP, yang panjangnya 20 byte, dan sisanya.

Tebak di mana letak masalahnya?


ANJING.  Beri tahu!


BEBEK.  Masalahnya adalah header IP *hampir selalu* panjangnya 20 byte – faktanya, saya rasa saya belum pernah melihat yang bukan.

Dan Anda dapat mengetahui panjangnya 20 byte karena byte pertama akan berupa heksadesimal 0x45.

“4”” berarti IPv4, dan “5”… “Oh, kami akan menggunakannya untuk mengatakan berapa panjang headernya.”

Anda mengambil angka itu 5 dan mengalikannya dengan 4 (untuk nilai 32-bit), dan Anda mendapatkan 20 byte..

…dan itu adalah ukuran header IP senilai enam sigma yang mungkin pernah Anda lihat di seluruh dunia, Doug. [TAWA]

Tapi mereka * bisa * mencapai 60 byte.

Jika Anda menempatkan 0x4F alih-alih 0x45, artinya ada 0xF (atau 15 dalam desimal) × 4 = 60 byte di header.

Dan kode FreeBSD hanya mengambil tajuk itu dan menyalinnya ke buffer di tumpukan yang berukuran 20 byte.

Sebuah buffer overflow tumpukan jadul yang sederhana.

Ini adalah kasus alat pemecahan masalah jaringan yang terhormat dengan jenis bug yang terhormat di dalamnya. (Yah, tidak lagi.)

Jadi, ketika Anda memprogram dan Anda harus berurusan dengan hal-hal tingkat rendah yang tidak pernah dipikirkan orang selama berabad-abad, jangan hanya mengikuti kebijaksanaan yang diterima yang mengatakan, “Oh, itu akan selalu menjadi 20 byte; Anda tidak akan pernah melihat sesuatu yang lebih besar.”

Karena suatu hari Anda mungkin.

Dan ketika hari itu tiba, itu mungkin ada di sana dengan sengaja karena seorang penjahat sengaja membuatnya.

Jadi iblis, seperti biasa, ada dalam detail pemrograman, Doug.


ANJING.  Oke, sangat menarik; cerita yang bagus.

Dan kami akan tetap pada subjek kode dengan cerita terakhir tentang Chrome ini.

Zero-day lainnya, yang menjadikan total tahun 2022 menjadi sembilan kali lipat:

Nomor sembilan! Chrome memperbaiki zero-day 2022 lainnya, Edge juga ditambal


BEBEK.  [Suara formal, terdengar seperti rekaman] "Nomor 9. Nomor 9. Nomor 9, nomor 9," Douglas.


ANJING.  [TERTAWA] Apakah ini Yoko Ono?


BEBEK.  Itu Revolusi 9 dari "Album Putih" The Beatles.

Yoko terdengar riffing di lagu itu – itu pemandangan suara, Saya percaya mereka menyebutnya – tetapi tampaknya di bagian awal di mana ada seseorang yang mengatakan "Nomor 9, nomor 9" berulang kali, itu sebenarnya adalah rekaman uji yang mereka temukan tergeletak di sekitar.


ANJING.  Ah, sangat keren.


BEBEK.  Seorang insinyur EMI mengatakan sesuatu seperti, "Ini adalah rekaman uji EMI nomor 9" [TERTAWA], dan sepertinya saya bahkan tidak berpikir ada yang tahu suara siapa itu.

Itu *tidak* ada hubungannya dengan Chrome, Doug.

Tetapi mengingat seseorang berkomentar di Facebook beberapa hari yang lalu, "Pria Paul itu mulai terlihat seperti Beatle"… [bingung] yang menurut saya agak aneh.


ANJING.  [TERTAWA] Ya, bagaimana Anda bisa menerimanya?


BEBEK.  … Saya pikir saya bisa makan di "Nomor 9".

Tampaknya ini adalah hari nol kesembilan dalam setahun sejauh ini, Doug.

Dan ini adalah perbaikan satu bug, dengan bug yang diidentifikasi sebagai CVE 2022-4282.

Karena Microsoft Edge menggunakan inti sumber terbuka Chromium, itu juga rentan, dan beberapa hari kemudian, Microsoft menindaklanjuti dengan pembaruan untuk Edge.

Jadi ini adalah masalah Chrome dan Edge.

Meskipun browser tersebut harus memperbarui dirinya sendiri, saya tetap menyarankan untuk memeriksanya – kami tunjukkan cara melakukannya di artikel – untuk berjaga-jaga.

Saya tidak akan membacakan nomor versi di sini karena berbeda untuk Mac, Linux dan Windows di Chrome, dan berbeda lagi untuk Edge.

Seperti Apple, Google agak bungkam tentang yang satu ini.

Itu ditemukan oleh salah satu tim pemburu ancaman mereka, saya percaya.

Jadi saya membayangkan mereka menemukannya saat menyelidiki insiden yang terjadi di alam liar, dan oleh karena itu mereka mungkin ingin menyembunyikannya, meskipun Google biasanya banyak berbicara tentang "keterbukaan" dalam hal perbaikan bug.

Anda dapat melihat mengapa, dalam kasus seperti ini, Anda mungkin perlu sedikit waktu untuk menggali sedikit lebih dalam sebelum Anda memberi tahu semua orang bagaimana cara kerjanya.


ANJING.  Luar biasa… dan kami memiliki pertanyaan pembaca yang mungkin merupakan pertanyaan yang dipikirkan banyak orang.

Cassandra bertanya, “Apakah pencari bug hanya beruntung menemukan bug? Atau apakah mereka menemukan 'lapisan' yang penuh dengan serangga? Atau apakah Chromium mengeluarkan kode baru yang lebih bermasalah dari biasanya? Atau ada hal lain yang terjadi?”


BEBEK.  Ya, itu pertanyaan yang bagus, sebenarnya, dan saya khawatir saya hanya bisa menjawabnya dengan cara yang sedikit bercanda, Doug.

Karena Cassandra sudah memberikan pilihan A), B) dan C), saya berkata, “Yah, mungkin begitu D) Semua hal di atas."

Kami tahu bahwa ketika bug dari jenis tertentu muncul dalam kode, maka masuk akal untuk berasumsi bahwa programmer yang sama mungkin telah membuat bug serupa di tempat lain di perangkat lunak.

Atau pemrogram lain di perusahaan yang sama mungkin telah menggunakan apa yang dianggap sebagai kebijaksanaan yang diterima atau praktik standar pada saat itu, dan mungkin mengikutinya.

Dan contoh yang bagus adalah, jika Anda melihat kembali Log4J… ada perbaikan untuk menambal masalah.

Dan kemudian, ketika mereka pergi mencari, "Oh, sebenarnya, ada tempat lain di mana kesalahan serupa terjadi."

Jadi ada perbaikan untuk perbaikan, dan kemudian ada perbaikan untuk perbaikan, Jika saya ingat.

Ada, tentu saja, juga masalah ketika Anda menambahkan kode baru, Anda mungkin mendapatkan bug yang unik untuk kode baru tersebut dan muncul karena penambahan fitur.

Dan itulah mengapa banyak browser, termasuk Chrome, memiliki versi "sedikit lebih lama" jika Anda suka yang dapat Anda pertahankan.

Dan idenya adalah bahwa rilis “lama” itu… mereka tidak memiliki fitur baru, tetapi semua perbaikan keamanan yang relevan.

Jadi, jika Anda ingin konservatif tentang fitur baru, Anda bisa.

Namun kita pasti tahu bahwa, terkadang, saat Anda menyekop fitur baru ke dalam suatu produk, bug baru datang dengan fitur baru tersebut.

Dan Anda dapat mengetahuinya, misalnya, saat ada pembaruan, katakanlah, untuk iPhone Anda, dan Anda mendapatkan pembaruan, katakanlah, untuk iOS 15 dan iOS 16.

Kemudian, ketika Anda melihat daftar bug, ada beberapa bug yang hanya berlaku untuk iOS 16.

Dan Anda berpikir, "Halo, itu pasti bug dalam kode yang sebelumnya tidak ada."

Jadi, ya, itu kemungkinan.

Dan saya pikir hal-hal lain yang sedang terjadi dapat dianggap baik.

Yang pertama adalah menurut saya, terutama untuk hal-hal seperti browser, pembuat browser menjadi jauh lebih baik dalam mendorong pembuatan ulang penuh dengan sangat, sangat cepat.


ANJING.  Menarik.


BEBEK.  Dan saya pikir hal lain yang berubah adalah, di masa lalu, Anda dapat berargumen bahwa bagi banyak vendor… cukup sulit untuk membuat orang menerapkan tambalan sama sekali, bahkan ketika mereka keluar hanya pada jadwal bulanan, dan bahkan jika mereka memiliki beberapa perbaikan zero-day di dalamnya.

Saya pikir, mungkin itu juga merupakan tanggapan terhadap fakta bahwa semakin banyak dari kita semakin cenderung tidak hanya menerima, tetapi sebenarnya untuk * mengharapkan * pembaruan otomatis yang benar-benar cepat.

Jadi, saya pikir Anda bisa membaca beberapa hal bagus tentang ini.

Fakta bahwa Google tidak hanya dapat mendorong satu perbaikan zero-day hampir secara instan, tetapi juga bahwa orang-orang bersedia menerimanya dan bahkan menuntutnya.

Jadi saya suka melihat masalah, "Wow, sembilan hari nol dalam setahun diperbaiki satu per satu!"…

… Saya lebih suka memikirkannya sebagai “gelas setengah terisi dan terisi” daripada “gelas setengah kosong dan dikuras melalui lubang kecil di bagian bawah”. [TAWA]

Itu pendapat saya.


ANJING.  Baiklah, sangat bagus.

Terima kasih atas pertanyaannya, Cassandra.

Jika Anda memiliki cerita, komentar, atau pertanyaan menarik yang ingin Anda sampaikan, kami ingin membacanya di podcast.

Anda dapat mengirim email ke tips@sophos.com, Anda dapat mengomentari salah satu artikel kami, atau Anda dapat menghubungi kami di sosial: @NakedSecurity.

Itu acara kami untuk hari ini; terima kasih banyak untuk mendengarkan.

Untuk Paul Ducklin, saya Doug Aamoth, mengingatkan Anda: Sampai lain kali…


KEDUA.  Tetap aman!

[MODEM MUSIK]


Stempel Waktu:

Lebih dari Keamanan Telanjang