Serangan Downfall

 (downfall.page)
1 poin oleh GN⁺ 2023-08-09 | 1 komentar | Bagikan ke WhatsApp
  • Kerentanan CVE-2022-40982 pada prosesor Intel yang banyak digunakan di komputer pribadi dan cloud memungkinkan pencurian data milik pengguna lain yang berbagi komputer yang sama
  • Inti kerentanan ini adalah bahwa instruksi Gather membocorkan isi file register vektor internal selama eksekusi spekulatif dalam proses optimasi memori
  • Serangan diimplementasikan dengan teknik GDS·GVI, dan demo menunjukkan kebocoran lintas batas isolasi, termasuk kunci AES, data Linux Kernel, hingga pemantauan karakter yang dapat dicetak
  • Cakupan dampaknya meliputi Intel Core generasi ke-6 Skylake hingga generasi ke-11 Tiger Lake, dan pengguna cloud dapat terdampak meski tidak memiliki perangkat Intel secara langsung
  • Pembaruan microcode dari Intel memblokir hasil transient dari Gather, tetapi beberapa workload dapat mengalami overhead hingga 50% setelah mitigasi diterapkan

Kerentanan yang dibidik Downfall

  • Downfall menargetkan kelemahan penting pada prosesor modern yang digunakan di komputer pribadi dan cloud
  • Kerentanan ini diidentifikasi sebagai CVE-2022-40982
  • Penyerang dapat mengakses dan mencuri data pengguna lain yang berbagi komputer yang sama
    • Aplikasi berbahaya yang diunduh dari app store dapat mencuri informasi sensitif seperti kata sandi, kunci enkripsi, data perbankan, email pribadi, dan pesan
    • Di cloud, pelanggan berbahaya dapat mencuri data dan kredensial milik pelanggan lain yang berbagi komputer cloud yang sama

Penyebab teknis kerentanan

  • Fitur optimasi memori pada prosesor Intel tanpa sengaja mengekspos register perangkat keras internal ke perangkat lunak
  • Perangkat lunak yang tidak tepercaya dapat mengakses data program lain yang seharusnya tidak bisa diakses
  • Instruksi Gather, yang dirancang untuk membaca data memori yang tersebar dengan lebih cepat, membocorkan isi file register vektor internal selama eksekusi spekulatif
  • Teknik yang digunakan untuk mengeksploitasinya adalah Gather Data Sampling(GDS) dan Gather Value Injection(GVI)
  • Rincian teknis dirangkum dalam makalah Downfall

Contoh kebocoran yang terkonfirmasi lewat demo

  • Demo Downfall menunjukkan bahwa data sensitif dapat bocor melintasi berbagai batas isolasi
    • Video 7: pencurian kunci AES 128-bit dan 256-bit milik pengguna lain
    • Video 8: pencurian data arbitrer dari Linux Kernel
    • Video 9: pemantauan karakter yang dapat dicetak

Sistem yang terdampak dan syarat serangan

  • Perangkat yang terdampak adalah perangkat komputasi berbasis prosesor Intel Core generasi ke-6 Skylake hingga generasi ke-11 Tiger Lake
  • Daftar prosesor terdampak yang lebih lengkap akan tersedia di daftar affected processors milik Intel
  • Pengguna cloud dapat terdampak meski tidak memiliki perangkat fisik berbasis Intel
    • Pangsa pasar server Intel melebihi 70%
  • Penyerang dapat membidik kredensial bernilai tinggi seperti kata sandi dan kunci enkripsi
  • Pencurian kredensial dapat berkembang menjadi serangan lain yang merusak ketersediaan dan integritas komputer, bukan hanya melanggar kerahasiaan
  • GDS tergolong cukup mudah diwujudkan menjadi serangan nyata
    • Pengembangan serangan end-to-end untuk mencuri kunci enkripsi dari OpenSSL memakan waktu 2 minggu
    • Penyerang dan korban hanya perlu berbagi core prosesor fisik yang sama
    • Pada komputer modern dengan preemptive multitasking dan simultaneous multithreading, kondisi berbagi seperti ini sering terjadi

Batas isolasi, SGX, dan dampak pada browser

  • Downfall juga memengaruhi batas isolasi umum
    • mesin virtual
    • proses
    • isolasi pengguna-kernel
  • Intel SGX juga terdampak
    • Intel SGX adalah fitur keamanan perangkat keras pada CPU Intel untuk melindungi data pengguna dari perangkat lunak berbahaya
  • Eksploitasi jarak jauh melalui browser web secara teoretis memungkinkan
    • Namun, untuk menunjukkan serangan yang benar-benar berhasil di browser masih dibutuhkan riset dan pekerjaan rekayasa tambahan

Lama paparan dan tingkat kesulitan deteksi

  • Pengguna telah terpapar kerentanan ini setidaknya selama 9 tahun
    • Prosesor yang terdampak sudah ada sejak 2014
  • Serangan Downfall sulit dideteksi
    • Bentuk eksekusinya sebagian besar tampak seperti aplikasi normal
    • Secara teoretis, sistem dapat dibuat untuk mendeteksi perilaku tidak wajar seperti cache miss berlebihan dengan memanfaatkan hardware performance counter
    • Perangkat lunak antivirus komersial pada umumnya tidak dapat mendeteksi serangan ini

Mitigasi dan overhead performa

  • Intel telah merilis pembaruan microcode
    • Pembaruan ini memblokir hasil transient dari instruksi Gather
    • Dengan demikian, kode penyerang tidak dapat mengamati data spekulatif yang keluar dari Gather
  • Overhead mitigasi bergantung pada apakah Gather berada di jalur eksekusi penting program
  • Menurut Intel, beberapa workload dapat mengalami overhead hingga 50%
  • Tidak aman menonaktifkan mitigasi hanya karena workload dianggap tidak memakai Gather
    • CPU modern menggunakan register vektor untuk mengoptimalkan tugas umum seperti penyalinan memori dan perpindahan isi register
    • Dalam proses itu, data dapat bocor ke kode tidak tepercaya yang mengeksploitasi Gather

Jadwal pengungkapan dan kode reproduksi

  • Kerentanan ini berada dalam status embargo selama hampir 1 tahun
  • Dilaporkan ke Intel pada 24 Agustus 2022
  • Downfall dipresentasikan di BlackHat USA pada 9 Agustus 2023 dan di USENIX Security Symposium pada 11 Agustus 2023
  • Kode reproduksi tersedia di GitHub POC

Hal yang perlu diperhatikan perancang prosesor lain

  • Prosesor lain juga memiliki memori SRAM bersama di dalam core, seperti file register perangkat keras dan fill buffer
  • Produsen perlu merancang unit memori bersama dengan lebih hati-hati agar data tidak bocor antar domain keamanan yang berbeda
  • Investasi pada verifikasi dan pengujian keamanan perlu ditingkatkan

Nama dan kerentanan terkait

  • Nama Downfall diberikan karena kerentanan ini meruntuhkan sebagian besar batas keamanan dasar komputer
  • Downfall dapat dipandang sebagai penerus dari kerentanan kebocoran data CPU sebelumnya, Meltdown dan Fallout
  • Dalam alur ini, Downfall kembali melewati mitigasi-mitigasi sebelumnya

Rekomendasi vendor dan dokumen teknis

Bacaan terkait

1 komentar

 
GN⁺ 2023-08-09
Komentar Hacker News

  • Terasa aneh bahwa bahkan setelah serangan Spectre awal, peneliti eksternal terus menemukan serangan serupa, lalu produsen chip menambalnya belakangan
    Secara prinsip, produsen chip adalah pihak yang ahli dalam speculative execution, mengetahui persis cara kerja chip, dan bahkan memiliki suite verifikasi, simulator, serta spesifikasi internal yang dapat dibaca mesin, sehingga seharusnya berada pada posisi paling menguntungkan untuk menemukannya
    Peneliti eksternal harus menjelajahi black box dan melakukan rekayasa balik dengan bahan yang jauh lebih terbatas seperti paten, tetapi bahkan setelah beberapa tahun berlalu, individu atau kelompok eksternal masih menemukan kerentanan seperti ini
    Sebelum Spectre, mungkin saja vektor serangan seperti ini belum dipertimbangkan, tetapi setelah mekanisme umumnya terungkap, bukankah produsen chip semestinya mengumpulkan orang-orang paling cerdas dan berkata, “sisir semuanya dan temukan serangan lain sejenis Spectre”?
    Mungkin saja mereka sebenarnya sudah mengetahui semuanya, tetapi menguburnya sambil berharap tidak terungkap demi menghindari kehilangan muka dan penurunan performa

    • Bisa jadi ini bias penyintas. Kita tidak tahu berapa banyak bug sejenis Spectre yang ditambal tanpa pernah dipublikasikan
    • Logika seperti ini terasa tidak nyaman. Dengan pola pikir yang sama, programmer yang dua kali membuat error keamanan memori juga bisa diasumsikan bukan sekadar melakukan kesalahan manusiawi, melainkan berniat jahat
      Jika suatu benda dipakai oleh miliaran orang, menurut saya mereka akan menemukan lebih banyak masalah, cacat, dan exploit daripada pihak yang membuatnya. Fakta bahwa masalah seperti itu ada tidak dengan sendirinya mendukung ataupun membantah kesimpulan tambahan tentang alasannya
    • Kemungkinan yang belum disebut siapa pun adalah bahwa alasan vendor chip tidak menginvestasikan banyak waktu untuk mencari hal-hal seperti ini mungkin karena sebenarnya hal itu tidak terlalu penting
      Peneliti keamanan punya insentif untuk menemukan sesuatu demi membangun reputasi. Sering kali sesuatu yang tidak terlalu berarti bagi penyerang di dunia nyata diklaim sebagai kerentanan keamanan yang akan mengguncang dunia
      Pernahkah serangan speculative execution ditemukan di lingkungan nyata? Mungkin tidak. Jika demikian, alasan vendor chip untuk menghabiskan dana besar di sini lemah
      Pelanggan nyata tidak dirugikan, kecuali ketika peneliti eksternal memaksa tindakan sehingga microcode baru yang memperlambat performa harus dirilis
      Patut dicatat juga bahwa mitigasi untuk serangan seperti ini selalu disertai sakelar untuk mematikannya. Itu bukan bentuk yang umum terlihat pada perbaikan keamanan, dan dalam banyak kasus alasannya adalah serangan-serangan ini tidak begitu penting
      Software yang berjalan pada core fisik yang sama atau CPU fisik yang sama berada pada tingkat kepercayaan yang sama, atau disandbox cukup kuat sehingga tidak dapat melakukan serangan
    • Bisa jadi ini terkena hukum debugging Kernighan. “Semua orang tahu debugging itu dua kali lebih sulit daripada menulis programnya sejak awal. Jadi jika saat menulisnya Anda membuatnya secerdas mungkin, bagaimana mungkin Anda bisa men-debug-nya?”
      Intel tanpa diragukan membuat chip “secerdas mungkin”, sehingga menurut definisi tidak dapat di-debug sepenuhnya
    • Sebagai seorang engineer CPU, Spectre mengungkap kanal kebocoran informasi yang sebelumnya tidak dianggap rentan. Karena itu exploit baru bermunculan, dengan sebuah ide baru di pusatnya, dan orang lain membangun di atas ide tersebut
      Penting juga dicatat bahwa ini bukan bug. Desainnya bekerja sesuai maksud. Sudah dipahami bahwa performa CPU berbeda tergantung kode yang sebelumnya dijalankan, dan hal itu diterima karena biaya alternatifnya dianggap terlalu besar dari sisi daya, performa, dan area. Itulah engineering: menimbang alternatif lalu memilih
      Dalam kasus ini, ketika CPU menjadi cukup cepat, sebagian kecil bit per iterasi berubah menjadi bandwidth yang dapat diserang, tetapi industri perlu ada seseorang yang menunjukkannya agar bisa memahaminya. Itulah yang mengubah penilaian engineering

  • Tautan makalah Intel sudah mati, dan tautan yang benar tampaknya yang ini: https://www.intel.com/content/www/us/en/developer/articles/t...
    Sebagai catatan umum, apakah masih banyak cloud yang menjalankan workload dari pengguna berbeda pada core fisik yang sama? Saya kira sebagian besar sudah mengubah scheduler beberapa tahun lalu untuk mencegah kebocoran lintas domain di antara hyperthread
    Klaim bahwa ini memengaruhi semua pengguna internet tampaknya terlalu dilebih-lebihkan. Saya juga tidak melihat exploit berbasis browser, dan kalaupun ada, kemungkinan hanya akan memengaruhi segelintir sangat kecil pengguna yang menjadi target. Sudah bertahun-tahun sejak Spectre muncul, dan saya bertanya-tanya apakah pernah ada serangan speculative execution yang ditemukan di lingkungan nyata
    Yang lebih menarik adalah bug speculative execution seperti ini terus tampak bisa dipatch lewat microcode. Saat pertama kali muncul, ada ketakutan bahwa chip fisik mungkin harus dibuang dan diganti secara massal, tetapi apakah itu pernah benar-benar diperlukan?
    Setahu saya, semua bug bisa ditangani dengan kombinasi perubahan software dan microcode, dalam beberapa kasus dengan sedikit biaya performa. Tidak ada bug yang membutuhkan silicon baru. Pengecualian mungkin kasus seperti versi awal AMD SEV yang benar-benar berhasil di-jailbreak dan tidak bisa dipatch

    • Selain cloud besar seperti AWS/GCP/Azure, ada sangat banyak penyedia VPS, dan di sana jawabannya adalah “ya”. Tempat yang menjual core ‘dedicated’ pun sering kali sebenarnya hanya berarti memberi penggunaan CPU tanpa batas
    • Serangan Spectre harus dipatch di kernel, dan sangat memperlambat kecepatan eksekusi CPU Intel: https://www.notebookcheck.net/Spectre-v2-mitigation-wreaks-h...
    • Bukankah instance t AWS memang untuk tujuan seperti itu? Saya memahaminya sebagai “shared” di tingkat core, dan kalau tidak begitu, tidak ada alasan konsep seperti saldo CPU credit ada
    • Saya rasa sebagian besar, mungkin hampir semua VM cloud, memberikan core secara dedicated
      Tentu ada yang shared seperti seri T AWS, dan mungkin ada yang serupa di cloud lain, tetapi saya kira mereka bisa menambahkan “flush” tambahan di antara pengguna untuk mencegah kebocoran antar-tenant
      Tentu saja kebocoran antarproses dalam satu tenant adalah masalah baik di cloud maupun on-premises, dan pada akhirnya kita harus memutuskan seberapa besar kita percaya bahwa proses di mesin sendiri tidak akan berubah menjadi jahat
    • Disebut berpotensi memengaruhi “semua orang di internet” karena sebagian besar server rentan

  • Menjalankan kode dari domain keamanan berbeda pada core prosesor fisik yang sama tampaknya mustahil dilakukan dengan benar, dan sepertinya sudah saatnya dihentikan
    Kasus yang umum pada dasarnya hanya ada dua: VM dan JavaScript
    VM harus ditinggalkan. Core tertentu harus didedikasikan untuk VM tertentu, atau setidaknya untuk pelanggan tertentu
    JavaScript sedikit lebih sulit
    Apa pun pilihannya, kita tidak boleh mengorbankan performa pada kasus umum

    • Untuk JavaScript, “berhenti saja” tampaknya cukup masuk akal
    • Ada peluang marketing di sini untuk kembali menonjolkan multicore. Kebanyakan workload sudah mencapai titik diminishing returns ketika CPU ditambah core lagi, tetapi jika kesimpulannya adalah bahwa kita membutuhkan lebih banyak core agar bisa menjalankan lebih banyak proses atau tab browser secara bersamaan dengan aman, chip laptop 128-core bisa saja muncul
    • Saya sudah cukup lama bertanya-tanya apakah masuk akal membagi CPU menjadi “IOPU” dan “SPU”
      IOPU bertugas mengarahkan hardware lain di sistem, dan tidak perlu punya performa yang sangat tinggi
      SPU dioptimalkan untuk kode skalar dan kode dengan banyak branch yang harus berjalan cepat
      SPU cukup memiliki keamanan minimal sebatas mencegah pembacaan memori sembarang saat mengambil dari RAM. Karena hanya menjalankan satu program dalam satu waktu, speculative execution tidak akan menjadi masalah
      Di sistem saya, hampir tidak ada program yang membutuhkan banyak kemampuan pemrosesan, dan kalaupun ada, kebutuhannya bersifat sesekali, jadi sepertinya tidak akan banyak task switching di SPU
    • Benar. Pendekatan ini sudah melewati masa jayanya. Itu adalah era sistem time-sharing dari 1960-an hingga 1990-an, ketika banyak pengguna punya akun shell di sistem Unix milik universitas atau ISP
      Serangan CPU seperti ini menunjukkan bahwa sistem time-sharing yang aman, di mana pengguna menjalankan kode mesin arbitrer, tidak lagi realistis
      Time-sharing masih akan tetap ada untuk kasus orang-orang yang saling percaya, seperti pekerja dalam proyek yang sama berbagi mesin build
    • Ini mirip dengan hukum kedua termodinamika sebelum mekanika statistik hadir dan merapikannya. Mungkin belum punya fondasi analitis dan filosofis yang kokoh, tetapi secara eksperimental begitu kuat sehingga siapa pun yang mencoba menjual kebalikannya terlihat sangat mencurigakan
      Gagasan bahwa dua program yang berjalan di komputer bisa dicegah agar tidak mengintip satu sama lain juga berada pada level seperti itu

  • Advisory keamanan Intel: https://www.intel.com/content/www/us/en/developer/articles/t...
    Merge kernel Linux: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

  • Katanya hanya berdampak sampai generasi ke-11; rasanya kerentanan ini tidak diungkapkan ke Intel cukup awal untuk diperbaiki di generasi ke-12. Kalau begitu, mungkin ini terselesaikan secara tidak sengaja saat mereka memperbaiki hal lain
    Melihat makalahnya, tertulis bahwa “Intel menyatakan CPU terbaru seperti Alder Lake, Raptor Lake, dan Sapphire Rapids tidak terdampak. Namun, ini tampaknya lebih merupakan efek samping dari arsitektur yang berubah besar, bukan karena pertimbangan keamanan”
    Pada akhirnya, entah diperbaiki secara acak, atau setidaknya exploit spesifik ini jadi tidak bisa bekerja

    • Perilaku mikroarsitektur berubah dari generasi ke generasi, sehingga efek sampingnya juga berubah. Cukup sering terjadi masalah yang kebetulan diperbaiki, atau masalah baru yang kebetulan tercipta

  • Menurut FAQ, pengguna sudah terpapar kerentanan ini selama setidaknya 9 tahun. Karena prosesor yang terdampak sudah ada sejak 2014
    Mengejutkan bahwa kerentanan seperti ini tidak terlihat selama bertahun-tahun, lalu hanya butuh 2 minggu bagi seseorang untuk mengodekan exploit

    • Sepertinya waktu untuk menemukan kerentanan itu sendiri sejak awal jauh lebih lama dari 2 minggu
    • Fakta bahwa ini dipublikasikan hanya berarti seorang peneliti white hat atau gray hat menemukan kerentanannya. Tidak ada cara untuk tahu apakah pihak yang kurang bermoral mengeksploitasi cacat yang sama selama itu, atau berapa kali mereka melakukannya
    • Besar kemungkinan pekerjaan ini didasarkan pada exploit sebelumnya

  • Lihat juga artikel LWN: https://lwn.net/Articles/940783/
    Di Linux, untuk CPU yang tidak memiliki microcode terbaru, AVX dinonaktifkan sepenuhnya sebagai mitigasi untuk masalah ini. Menurut saya ini cukup keras dan dampaknya mungkin terasa besar. Jadi ingin mengecek apakah bisa mendapatkan microcode yang diperbarui

    • Penonaktifan AVX hanya diterapkan saat menggunakan gather_data_sampling=force. Nilai default-nya adalah membiarkan AVX tetap aktif dan menandai sistem sebagai rentan
      Jika dilihat di https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...:
      Jika gather_data_sampling=force ditentukan, gunakan mitigasi microcode jika memungkinkan, dan nonaktifkan AVX pada sistem terdampak yang microcode-nya belum diperbarui agar memuat mitigasi tersebut
      Sebagai catatan, saya bekerja di Intel untuk urusan Linux. Ada kemungkinan saya yang menulis atau menyunting dokumentasi dan changelog yang membuat orang bingung
    • [ 0.000000] microcode: updated early: 0x27 -> 0x28, date = 2019-11-12
      Saya memakai Haswell. Apakah ada daftar CPU mana saja yang menerima microcode terbaru? Sayang sekali
    • Mungkin itu bukan nilai default. Dari teksnya saja, tidak sepenuhnya jelas

  • Perlu dicatat juga bahwa GCP sudah menambal masalah ini: https://cloud.google.com/support/bulletins#gcp-2023-024

    • Tim-tim tetangga yang menjadi SRE Google Cloud (GCE) di London mendistribusikan patch tepat waktu, jadi hari ini mereka mendapat donat yang memang pantas mereka terima
    • Pengumuman AWS yang terkait: https://aws.amazon.com/security/security-bulletins/AWS-2023-...
      Data dan instance pelanggan AWS tidak terdampak oleh masalah ini, dan tidak ada tindakan yang perlu dilakukan pelanggan
      AWS telah merancang dan mengimplementasikan infrastruktur dengan perlindungan terhadap kelas masalah ini. Instance Amazon EC2, termasuk Lambda, Fargate, serta layanan komputasi dan container terkelola AWS lainnya, melindungi data pelanggan dari GDS melalui microcode dan mitigasi berbasis perangkat lunak

  • Dampak performanya sangat besar. Diklaim sampai 50%, dan katanya 70% prosesor Intel modern terdampak

    • “Dalam pengujian performa internal Red Hat, microbenchmark terburuk menunjukkan penurunan kecepatan yang besar. Namun, aplikasi yang lebih realistis yang memanfaatkan vector gather hanya menunjukkan penurunan kecepatan dalam kisaran persen satu digit rendah.”
      https://access.redhat.com/solutions/7027704
      Dampak performa terbatas pada aplikasi yang menggunakan instruksi gather dan instruksi CLWB yang disediakan oleh Intel Advanced Vector Extensions (AVX2 dan AVX-512). Dampak performa nyata bergantung pada seberapa banyak aplikasi menggunakan instruksi-instruksi tersebut
      Jika pengguna memutuskan untuk mematikan mitigasi setelah analisis risiko yang menyeluruh, misalnya jika sistem bukan multi-tenant dan tidak menjalankan kode yang tidak tepercaya, mitigasi dapat dinonaktifkan
      Setelah menerapkan pembaruan microcode dan kernel, mitigasi dapat dimatikan dengan menambahkan gather_data_samping=off ke command line kernel. Atau, untuk mematikan semua mitigasi speculative execution CPU termasuk GDS, gunakan mitigations=off
    • Apakah overhead 50% itu untuk instruksi “Gather”? Kalau begitu, jika 10% instruksi dalam workload adalah gather, overhead totalnya menjadi 5%
    • Ungkapannya adalah “sebagian workload dapat mengalami overhead hingga 50%”. Dari kata sebagian workload, sepertinya dampak performanya jarang terjadi
    • Konteks penting yang hilang adalah bagian “tergantung apakah Gather ada di jalur eksekusi inti program”
    • Ini mirip melihat kalimat “diskon hingga 70%” lalu mengira itu obral besar-besaran. Kadang di seluruh toko hanya ada sekitar dua barang yang diskon 70%
      Klaim “hingga” selalu patut dicurigai

  • NES memakai chipset yang di dalamnya tertanam seluruh 6502, dan dengan harga satu loyang pizza, kita bisa membeli chip Rockchip ARM yang memasukkan core campuran di atas die. Produsen chip tidak harus menyelesaikan semua kasus pinggiran selamanya, dan mungkin saja mitigasi serangan side-channel seperti ini dikembalikan kepada kita yang melahap chip-chip itu
    Bagaimana kalau tidak menjadikannya pilihan untuk menyalakan semua SMT atau mematikan semuanya, melainkan mengirim kode yang tidak tepercaya ke “core jelek”, lalu meminta pelanggan “membuktikan” bahwa kode itu boleh dinaikkan ke core yang memiliki SMT?
    Tidak ada yang ingin merusak chip yang menjalankan pekerjaan penggajian superpenting yang tidak bisa dipindahkan siapa pun ke board lain. Tapi tidak masalah kalau kita dipaksa menandai hal-hal yang boleh dijalankan dengan aman di SMT, dan kalau tidak, hal itu diikat ke core yang lebih aman
    Seorang intern yang sama sekali tidak tahu ini apa bisa saja mencarinya, lalu mempelajari apa sebenarnya vektor serangan ini dan menyusun rencana pertahanan
    Apakah aku yang aneh?

    • Menurutku ini masalah pasar
      Core performa × core efisiensi itu mungkin
      Tapi orang tidak akan mau menjadi pihak yang mengusulkan core tepercaya × core tidak tepercaya yang “jelek”. Sebanyak apa pun kelebihannya, itu akan terkubur dalam narasi “menebar kecemasan”. Begitulah hidup