9 poin oleh GN⁺ 10 hari lalu | 1 komentar | Bagikan ke WhatsApp
  • Colin Percival, penanggung jawab keamanan FreeBSD sekaligus pendiri Tarsnap, menulis kilas balik kronologis selama 20 tahun sejak membuat akun AWS pertamanya pada 2006 hingga sekarang. Dari posisi sebagai kontributor eksternal, bukan karyawan resmi, ia terlibat luas dalam perkembangan AWS, mulai dari membangun dukungan FreeBSD di EC2, menemukan dan melaporkan kerentanan keamanan secara proaktif, hingga memberi masukan desain layanan
  • Pada masa awal AWS, setiap layanan harus diaktifkan secara terpisah, dan layanan yang pertama kali aktif secara default adalah Amazon SQS serta Amazon E-Commerce Service yang nyaris tidak dikenal
  • Untuk menjalankan FreeBSD di EC2, berbagai hambatan teknis selama bertahun-tahun harus diatasi, termasuk kompatibilitas versi Xen, dukungan PAE, dan transisi ke HVM; keberhasilan boot pertama tercapai pada 2010 di t1.micro
  • Ia juga lebih dulu menemukan dan melaporkan banyak isu keamanan, termasuk kerentanan collision kanonisasi pada skema penandatanganan request AWS, risiko kebocoran kredensial melalui IMDS (yang menjadi nyata dalam insiden pelanggaran Capital One 2019), serta masalah keamanan Seekable OCI
  • Sejak 2024, ia terus memelihara FreeBSD/EC2 dengan dukungan GitHub Sponsors dari Amazon; ini menjadi contoh hasil nyata yang dicapai sebagai kontributor eksternal tanpa akses ke sistem internal, lewat kerja sama dengan para engineer Amazon

Pembuatan akun AWS dan layanan awal

  • Pada 10 April 2006, setelah melihat pengumuman Amazon S3, ia membuat akun AWS pertamanya. Ketertarikannya dipicu oleh layanan penyimpanan online, dan sebelumnya ia sudah memiliki pengalaman membangun layanan web berbasis HTTP sejak 1998
  • Di AWS pada masa awal, setiap layanan harus diminta aktivasi terpisah ke dalam akun, dan layanan bawaan yang tersedia hanyalah Amazon SQS serta Amazon E-Commerce Service (API katalog produk untuk afiliasi Amazon)
    • Amazon E-Commerce Service pada praktiknya adalah layanan AWS pertama, tetapi hampir tidak dikenal dan kemudian dihapus diam-diam dari sejarah AWS

Ketertarikan awal pada keamanan dan masukan

  • Berdasarkan pengalamannya sebagai FreeBSD Security Officer, ia langsung tertarik pada struktur keamanan AWS. Ia menyoroti bahwa request AWS ditandatangani dengan API key untuk menjamin autentikasi dan integritas, tetapi responsnya tidak ditandatangani
  • Saat itu, request AWS melalui HTTP masih umum digunakan, sehingga kemungkinan manipulasi respons menjadi risiko nyata. Bahkan setelah beralih ke TLS, ia tetap berpandangan bahwa tanda tangan end-to-end lebih unggul daripada keamanan lapisan transport

FreeBSD on EC2 — tantangan awal

  • Segera setelah Amazon EC2 dirilis, ia menargetkan menjalankan FreeBSD dan melalui Jeff Barr terhubung dengan pihak internal Amazon; pada awal 2007 ia menandatangani Amazon NDA pertamanya
    • Saat itu Amazon masih memakai faks, tetapi karena ia tidak memiliki mesin faks, ia harus mengirim dokumen bertanda tangan asli lewat pos, sehingga briefing pertamanya tertunda
  • Pada awalnya EC2 dirilis tanpa dukungan custom kernel (mirip cara kerja AWS Lambda saat ini), dan pada November 2007, ketika fitur ini diaktifkan bersamaan dengan dukungan Red Hat, akun FreeBSD juga diberi akses ke API internal untuk “menerbitkan Amazon Kernel Images”

Audit keamanan Xen dan peringatan serangan side-channel

  • Pada Maret 2007, ia menyampaikan kepada kontak Amazon bahwa audit keamanan Xen diperlukan; ketika tidak tahu auditor yang cocok, ia merekomendasikan Tavis Ormandy
    • Pada tahun yang sama, Tavis melaporkan dua kerentanan Xen (CVE-2007-1320, CVE-2007-1321), tetapi hubungan keduanya dengan rekomendasi tersebut tidak jelas
  • Dalam pertemuan pengguna AWS di Second Life yang diadakan Jeff Barr, ia meminta fitur root disk read-only dan jaminan inisialisasi memori saat reboot untuk skenario menjalankan kode tak tepercaya, seperti build paket FreeBSD; EC2 Instance Attestation baru hadir 18 tahun kemudian
  • Pada re:Invent 2012, ia menjelaskan riset tentang pencurian kunci RSA menggunakan HyperThreading kepada seorang EC2 Principal Engineer, dan sangat menyarankan agar instance EC2 tidak dijalankan paralel pada dua thread di core yang sama
    • Rekomendasi ini disebut-sebut menjadi alasan banyak keluarga instance EC2 melewati ukuran “medium” dan langsung mulai dari 2 vCPU (“large”)

Eventual Consistency dan usulan teoretis

  • Dalam sebuah posting blog pada akhir 2007 yang banyak dibaca di internal Amazon, ia mengkritik persoalan Eventual Consistency dan mengusulkan model yang sedikit lebih kuat bernama Eventually Known Consistency
    • Dalam teorema CAP, model ini mempertahankan jalur “A” (availability), tetapi juga membuka status internal sehingga pada jalur normal bisa memperoleh “C” (consistency)
    • Amazon S3 kemudian bergeser dari optimisasi ketersediaan ke optimisasi konsistensi, dan DynamoDB menyediakan pilihan pembacaan Eventual/Strongly Consistent

Masalah kompatibilitas Xen dan kegagalan boot FreeBSD

  • Pada awal 2008, Kip Macy menulis kernel FreeBSD dengan dukungan Xen PAE, dan perlu beberapa minggu untuk mem-porting tool AMI internal ke FreeBSD
    • Ia juga menyinggung bahwa struktur Ruby script yang menghasilkan lalu menjalankan bash script layak dipertimbangkan ulang dari sisi pemilihan bahasa
  • Namun AMI FreeBSD tidak bisa boot di EC2; penyebabnya adalah bug pada Xen 3.0 yang dipakai EC2, karena tidak mendukung recursive page table pada kode VM FreeBSD
    • Masalah ini diperbaiki di Xen 3.1, tetapi karena tidak ada ABI stabil, Amazon memilih tetap menggunakan Xen 3.0 demi menjaga kompatibilitas AMI lama

Menemukan dan memperbaiki kerentanan tanda tangan AWS

  • Pada April 2008, saat menggunakan Amazon SimpleDB untuk beta Tarsnap, ia menemukan collision kanonisasi pada skema tanda tangan
    • Saat itu belum ada kanal pelaporan isu keamanan ke Amazon, jadi ia menyampaikannya lewat Jeff Barr
  • Amazon kemudian meminta tinjauan desain untuk Signature Version 2; setelah perbaikan ambiguitas dokumentasi, koreksi keputusan desain, dan penambahan allowlist akun, perbaikannya selesai pada Desember

Masalah hygiene keamanan pada NextToken SimpleDB

  • Pada Juni 2008, ia menemukan bahwa nilai NextToken di SimpleDB hanyalah objek serialisasi Java yang di-encode base64
    • Ia melaporkan bahwa seharusnya ada enkripsi untuk mencegah kebocoran informasi internal dan tanda tangan untuk mencegah manipulasi, tetapi tidak mendapat respons
    • Enam bulan kemudian ia melaporkannya lagi melalui engineer lain hingga dibuat tiket internal, namun tetap tidak ada tanggapan resmi setelah itu

Uji alfa EBS dan timing masukan desain

  • Pada Maret 2008, Matt Garman dari tim EC2 mengundangnya ke alfa tertutup Elastic Block Storage (kini Elastic Block Store)
    • Menurutnya, masukan paling berguna untuk layanan baru datang pada tahap desain sebelum dibangun; dengan latar belakang matematika dan teori, meninjau dokumen desain lebih efektif daripada sekadar menguji alfa

Kisah wawancara kerja di Amazon

  • Pada 2008, atas dorongan Jeff Barr, ia sempat mempertimbangkan bergabung ke Amazon. Dalam wawancara telepon dengan Al Vermeulen, 30 dari 45 menit dihabiskan untuk berdebat soal kelebihan dan kekurangan exceptions
    • Ia tetap berpandangan bahwa exception handling adalah cara penanganan error yang pada dasarnya tidak tepat, karena mudah menimbulkan bug yang sulit ditemukan dalam code review santai

IAM dan access key terbatas — perjalanan menuju SigV4

  • Pada November 2008, dalam Seattle AWS Start-up Tour, ia bertemu langsung dengan engineer Amazon dan membahas kebutuhan akan AWS access key yang dibatasi
    • Ia mendorong pendekatan kunci turunan kriptografis yang di-hash per layanan dari satu master secret, sementara pihak Amazon lebih menyukai desain berbasis aturan
  • Pada Januari 2010, ia diundang ke beta tertutup IAM, dan saat SigV4 dirilis pada 2012, pendekatan kunci turunan akhirnya diadopsi

Masalah firewall EC2 dan Path MTU Discovery

  • Pada 2009, ia menemukan dan melaporkan bahwa aturan firewall bawaan EC2 memblokir pesan ICMP Destination Unreachable (Fragmentation Required), sehingga Path MTU Discovery tidak berfungsi
    • Pada Desember 2009, manajer EC2 setuju dengan solusi yang diajukan, tetapi perbaikan nyata baru dilakukan setelah ia mengangkat masalah ini secara publik pada 2012

Jalan memutar lewat NetBSD dan transisi ke HVM

  • Pada awal 2010, karena EC2 masih bertahan pada Xen versi lama, ia mencoba beralih ke NetBSD, dan dalam waktu satu minggu berhasil boot, mount filesystem, mengatur jaringan, dan menjalankan sshd
  • Pada Juli 2010, instance Cluster Compute mulai mendukung HVM, memberi harapan baru untuk FreeBSD, dan semakin jelas bahwa PV (paravirtualization) adalah jalan buntu teknis

FreeBSD/EC2 pertama berjalan — t1.micro

  • Keluarga instance t1.micro yang dirilis pada September 2010 ternyata secara internal menjalankan Xen 3.4.2, sehingga bug yang selama ini menghalangi boot FreeBSD terselesaikan
  • Pada pertengahan November 2010, ia berhasil masuk via SSH ke instance FreeBSD/EC2 t1.micro, dan pada 13 Desember dukungan FreeBSD EC2 t1.micro diumumkan secara resmi

Perluasan tipe instance dan trik “Defenestration”

  • Seorang Amazon Solutions Architect menghubungkannya dengan pengguna FreeBSD yang menginginkan instance lebih besar, sehingga dukungan untuk Cluster Compute instance bisa diwujudkan
  • Dengan memanfaatkan fakta bahwa EC2 sebenarnya tidak tahu OS apa yang dijalankan, FreeBSD bisa dipakai di semua tipe instance 64-bit melalui defenestration (menyamar sebagai instance Windows)
    • Pengguna harus membayar “Windows tax” dan Amazon pun tidak menyukainya, tetapi itu diperlukan untuk memenuhi kebutuhan pelanggan; trik ini menjadi tidak perlu pada Juli 2014, ketika instance T2 melengkapi dukungan HVM “Linux”

Diagnosis kegagalan hardware router S3

  • Pada April 2012, terjadi banyak kegagalan request, termasuk error SignatureDoesNotMatch, pada endpoint S3 tertentu
  • Dari pola ketidaksesuaian nilai StringToSign dalam respons error dibanding nilai yang dikirim, ia mengidentifikasi stuck bit, lalu memakai traceroute dan jutaan ping untuk melokalisasi kerusakan hardware pada router tertentu di jalur
    • Setelah dilaporkan di AWS Developer Forums, Amazon mengonfirmasi gangguan tersebut dalam beberapa hari dan mengganti hardware-nya

re:Invent 2012 dan peringatan serangan side-channel

  • re:Invent pertama dinilai minim konten teknis dan dipenuhi orang berjas, tetapi tetap memberi kesempatan bertemu langsung dengan banyak engineer Amazon
  • Setelah seorang VP pembicara Intel pada sesi “keamanan virtual machine” menjawab bahwa ia tidak tahu soal side-channel attack, ia langsung menjelaskan riset terkait itu kepada Principal Engineer di booth EC2

Formalkan FreeBSD/EC2 dan release engineering

  • Pada April 2015, proses build AMI FreeBSD/EC2 diintegrasikan ke tree src FreeBSD, dan pembangunan image dialihkan ke tim FreeBSD Release Engineering, mengubahnya dari proyek pribadi menjadi proyek FreeBSD resmi
  • Pada September 2020, atas permintaan FreeBSD Release Engineering Lead Glen Barber, ia menerima peran Deputy Release Engineer
    • Pada akhir 2022, Glen dirawat di rumah sakit karena pneumonia, dan efek jangka panjang membuatnya sulit kembali, sehingga pada 17 November 2023 ia mengambil alih langsung sebagai FreeBSD Release Engineering Lead
    • Ia kemudian mengelola build snapshot mingguan, memperketat jadwal, membangun siklus rilis yang cepat dan dapat diprediksi, serta mengelola empat rilis per tahun

Peringatan keamanan IMDS dan insiden pelanggaran Capital One

  • Pada Oktober 2016, setelah menganalisis IAM Roles for Amazon EC2, ia menulis di blog bahwa kebocoran kredensial melalui IMDS berbahaya, karena layanan itu bekerja lewat HTTP tanpa autentikasi dan dokumentasinya sendiri memperingatkan untuk tidak menyimpan data sensitif
  • Pada Juli 2019, Capital One benar-benar dieksploitasi melalui risiko ini, menyebabkan kebocoran data 106 juta pelanggan; setelah berbicara dengan Amazon pada November tahun yang sama, dua minggu kemudian IMDSv2 dirilis
    • Menurutnya, IMDSv2 hanya mengurangi jalur serangan tertentu, bukan menyelesaikan masalah mendasar bahwa kredensial diekspos lewat antarmuka yang tidak layak

Program AWS Heroes

  • Pada Mei 2019, ia diundang ke program AWS Heroes, yang mengakui kontribusi penting terhadap AWS dari orang-orang non-Amazon
    • Pemilihannya tergolong tidak biasa karena program ini umumnya berfokus pada kontributor edukasi developer seperti blog, YouTube, dan workshop; ia disetujui atas rekomendasi Distinguished Engineer dan Senior Principal Engineer

Boot UEFI dan BootMode=uefi-preferred

  • Pada Maret 2021, EC2 menambahkan dukungan boot UEFI untuk instance x86; di FreeBSD, transisi ke UEFI menghilangkan kebutuhan I/O mode 16-bit dan mempercepat waktu boot 7 detik
    • Karena tidak semua tipe instance mendukung UEFI, ia meminta pengaturan BootMode=polyglot agar image bisa boot baik di BIOS lama maupun UEFI
    • Pada Maret 2023, fitur ini diimplementasikan dengan nama BootMode=uefi-preferred

Menemukan isu keamanan Seekable OCI dan lambatnya perbaikan

  • Pada Agustus 2023, di Heroes Summit, ia melihat desain Seekable OCI dan menemukan bahwa klaim keamanannya tidak berlaku pada use case tertentu, lalu melaporkannya ke tim AWS Security
  • Ia mendapat janji bahwa perbaikan internal akan dilakukan, tetapi ternyata tidak ada kemajuan nyata; setelah meminta pengecekan ulang di re:Invent 2024 dan melaporkannya lagi pada Januari 2025, dipastikan bahwa commit 2023 hanya mencegah korupsi data yang tidak disengaja, bukan serangan yang disengaja
    • Setelah masalah itu kembali disorot, respons bergerak cepat, dan hingga akhir Februari 2025 fitur tersebut dinonaktifkan untuk sebagian besar pelanggan, sambil menunggu “major revision”

Dukungan Amazon dan model kolaborasi

  • Pada April 2024, ia memberi tahu Amazon bahwa ia tidak bisa mencurahkan cukup waktu untuk pemeliharaan FreeBSD/EC2 dan meminta dukungan pendanaan; dalam beberapa minggu, Amazon menyetujui sponsorship via GitHub Sponsors selama 10 jam per minggu selama 1 tahun
    • Setelah menyelesaikan banyak isu tertunda dan melewati jeda enam bulan (sebagian besar tanpa bayaran, sambil fokus pada release engineering FreeBSD 15.0), ia memulai sponsorship 12 bulan kedua
  • Ia menegaskan bahwa kontribusi 20 tahun ini bukan hasil kerja sendirian. Meski tanpa akses ke sistem internal AWS, para engineer Amazon bertindak sebagai “tangan jarak jauh” dengan membuat tiket, mencari kontak internal, menyelidiki log API, dan memperoleh dokumentasi teknis

1 komentar

 
GN⁺ 10 hari lalu
Komentar Hacker News
  • Penulis bercanda bahwa ‘Heroes pada dasarnya adalah karyawan Amazon tak dibayar’, tapi itu sebenarnya bukan lelucon, melainkan kenyataan
    Saya tidak mempublikasikan riset pribadi saya. Soalnya saya tidak ingin memberi R&D gratis kepada mesin ekstraksi nilai yang sudah cukup efisien
    Amazon telah meruntuhkan premis ekonomi open source, dan akibatnya banyak proyek beralih ke Business Source License
    Para developer ini tahu betapa rakusnya Amazon. Pada akhirnya kontribusi komunitas berubah menjadi tenaga kerja gratis bagi korporasi raksasa, lalu Amazon menyerap pengguna lewat layanan terkelola dan melemahkan dukungan serta komunitas proyek aslinya

    • Kalau tidak suka Amazon memakai kode saya, tinggal kecualikan Amazon secara eksplisit di lisensi
      Tulis saja “siapa pun bebas menggunakan ini kecuali Amazon”, maka Amazon tidak akan menyentuhnya karena risiko hukum
      Namun jika dianggap perlu, Amazon mungkin akan membuat versi mereka sendiri dari nol
    • Perusahaan SaaS besar bisa saja tetap mengimplementasikan antarmuka API yang sama walaupun ada Business Source License
      Seperti kasus Redis, perlindungan hukum atas permukaan API tidak jelas
      Saya ingat dulu putusan Google v. Oracle sempat berpotensi menetapkan perlindungan seperti itu, tapi akhirnya tertunda
    • Lisensi seperti AGPL atau GPL3 juga bisa dipakai. Lisensi seperti ini hampir selalu dilarang oleh para hyperscaler
      Sebenarnya, perusahaan yang memilih BSL kemungkinan besar merilis kodenya bukan karena semangat open source sejati, melainkan demi manajemen citra atau agar disukai developer
    • “Untungnya” saya bukan orang yang cukup pintar atau penting untuk memikirkan masalah ini sedalam itu
      Meski begitu, saya sepenuhnya setuju. Sekarang kode yang saya buka akan jatuh ke salah satu dari dua kategori: open source sepenuhnya atau sepenuhnya tertutup
      Kalau ada kemungkinan seseorang bisa menghasilkan uang darinya, saya tidak akan membukanya
  • Saya paham sudut pandang yang tidak ingin memberikan waktu kepada perusahaan besar, tapi saya ingin menawarkan perspektif lain
    Pada 2006 saya membuat sebuah proyek, lalu pada 2012 developer lain ingin memakai nama proyek itu, dan saya dengan senang hati memberikannya
    Proyek itu adalah scrypt, dan developernya adalah Colin
    Kebaikan dalam komunitas seperti ini menjadi karma baik yang terakumulasi meskipun tanpa ekspektasi komersial

  • Pernyataan “meetup pengguna AWS oleh Jeff Barr diadakan di Second Life” sangat menarik
    Second Life adalah salah satu pengguna awal AWS, dan Jeff Bezos ikut langsung dalam putaran pendanaan tahun 2005
    Karena itu Jeff Barr mengadakan meetup AWS di dalam Second Life, dan saat itu kelompok seperti Reuters atau Jonathan Coulton juga sedang masuk ke ruang virtual

    • Saya masih ingat pertama kali melihat Second Life di sebuah konferensi sekitar 2002~2003
      Kami punya booth Evolution Robotics untuk mendemokan robot ER1, dan Second Life benar-benar mengesankan
      Itu jadi kenangan yang bagus
    • Saat re:Invent 2020 digelar di ruang virtual, saya sangat merasakan déjà vu era Second Life
      Tentu saja, Second Life di layar laptop dan headset VR adalah pengalaman yang sepenuhnya berbeda
  • Bingkai “tenaga kerja gratis untuk Amazon” melewatkan inti persoalan
    Colin bukan sedang beramal, melainkan memperbaiki sesuatu karena Tarsnap bergantung pada FreeBSD/EC2
    Model seperti ini adalah bentuk open source yang paling sehat — memperbaiki fondasi produk sendiri, dan hasilnya menguntungkan semua orang
    Menunggu sampai Amazon sendiri tertarik itu sama saja dengan menunggu selamanya

  • Saya terkejut membaca bahwa Amazon mendukung lewat GitHub Sponsors sebesar 10 jam per minggu selama 1 tahun
    $300 per jam itu setara dengan level gaji engineer Google L6
    Semoga sekarang dia dibayar lebih tinggi

    • Tarif per jam di industri TI Amerika memang benar-benar tidak normal
      Di Eropa berbahasa Jerman, dengan 120 euro Anda sudah bisa mendapatkan engineer hebat. Eropa Timur bahkan lebih murah
  • Saya tidak setuju dengan kritik penulis terhadap IAM Roles for EC2
    IAM adalah fitur inti yang memungkinkan pengelolaan kredensial berbasis kebijakan
    Jauh lebih aman daripada Outlook, Slack, atau Teams, dan bahkan bisa dibuktikan secara matematis bahwa anggota tim tidak dapat melihat kunci penandatanganan
    Azure juga menerapkan konsep serupa untuk menangani akses MSSQL dengan rapi

    • Saya tidak menentang IAM Roles itu sendiri. Saya hanya menganggap mereka memilih opsi terburuk untuk antarmuka penyampaian kredensial peran
      Dulu saya pernah mengusulkan agar kredensial disampaikan ke kernel lewat XenStore. Dengan basis Nitro, sekarang seharusnya lebih mudah diimplementasikan
      Kernel cukup menerima kredensial lalu mengeksposnya sebagai filesystem virtual yang bisa mengatur kepemilikan dan izin
    • Scaleway hanya mengizinkan token diambil dari port di bawah 1024
      Lucunya, itu berarti hanya proses dengan izin CAP_NET_BIND_SERVICE yang bisa mengaksesnya
      Jika memakai socket vsock(7), itu menjadi cara koneksi yang sulit dipalsukan, jadi lebih aman
      Lebih jauh lagi, kalau kredensial bootstrap dimasukkan ke data DMI, lokasinya akan berada di direktori sysfs yang hanya bisa dibaca root
  • Setelah memeriksa email tahun 2007, ternyata memang benar bahwa pada masa awal akses ke layanan AWS harus diminta satu per satu
    Awalnya saya hanya disetujui untuk “Amazon E-Commerce Service”, lalu kemudian mendapat akses ke S3, lalu beta EC2
    Saat itu “Alexa Web Information Service” bukan asisten suara, melainkan API pencarian web. Masa itu memang menarik

  • Ini benar-benar sebuah catatan sejarah teknologi yang menarik
    Mengesankan bahwa engineer terkenal seperti Tavis Ormandy pun bisa salah bicara dalam wawancara
    Saya sangat suka tulisan blog berisi pengalaman langsung seperti ini

  • Tidak adanya penyebutan Hetzner atau OVH dalam kilas balik 20 tahun ini terasa cukup bermakna
    Saya memakai AWS, Hetzner, dan cloud kecil secara bersamaan, dan selisih harganya luar biasa
    AWS menelan biaya $350 per bulan, sementara Hetzner hanya 20~25 euro untuk spesifikasi serupa plus trafik 20TB
    Yang dijual AWS sekarang bukan lagi komputasi, melainkan model IAM, infrastruktur global, dan konsensus internal organisasi
    Persepsi bahwa “kalau memilih AWS, tidak ada yang akan dipecat” itulah produk yang sebenarnya
    Saya ingin bertanya kepada orang-orang yang belakangan memindahkan workload keluar dari AWS — bagian mana yang ternyata lebih menyakitkan dari dugaan