- FFmpeg, yang memproses media di browser dan infrastruktur streaming di seluruh dunia, menjadi permukaan serangan penting bagi keamanan karena harus mem-parsing input yang kompleks dan tidak tepercaya
- Agen keamanan otonom dari depthfirst menemukan 21 zero-day dalam sekitar 1,5 juta baris kode C yang sangat dioptimalkan, dengan biaya sekitar $1k, atau sekitar 10% dari biaya penggunaan Mythos milik Anthropic yang sebesar $10k
- Temuan tersebar di berbagai komponen, termasuk TS demuxer, VP9 decoder, serta jalur pemrosesan RTP/RTSP/RTMP, dan beberapa kerentanan telah laten selama 15–20 tahun
- Kerentanan pada AV1 RTP depacketizer menghasilkan PoC yang dapat menimpa function pointer hanya dengan paket RTP 183 byte, dan dapat dicapai cukup dengan menjalankan
ffmpeg -i rtsp://attacker/stream
- Verifikasi keamanan yang nyata memerlukan bukan sekadar peringatan teoretis, tetapi juga input yang dapat direproduksi dan konfirmasi eksekusi, dan analisis berbasis agen dapat langsung dimanfaatkan untuk menemukan kerentanan tersembunyi di codebase C besar
Ikhtisar
- FFmpeg adalah perangkat lunak yang didistribusikan secara luas untuk memproses media di browser, infrastruktur platform streaming besar, dan lingkungan lainnya
- Karena merupakan pustaka yang terus-menerus mem-parsing media yang kompleks dan tidak tepercaya, FFmpeg penting dari sisi keamanan dan menjadi target utama serangan zero-click
- Repositori FFmpeg terdiri dari sekitar 1,5 juta baris kode C yang sangat dioptimalkan dan mem-parsing ratusan format media yang kompleks
- FFmpeg telah menjalani fuzzing dan audit manual selama lebih dari 20 tahun, dan baru-baru ini tim Google Big Sleep mengungkap 13 kerentanan di FFmpeg
- Anthropic memindai FFmpeg dengan model Mythos dan menemukan sebagian isu keamanan
- Setelah pekerjaan pendahuluan tersebut, mencari kerentanan baru di FFmpeg menjadi lebih sulit, sehingga FFmpeg menjadi target untuk menguji kemampuan sistem berbasis agen dalam memindai codebase besar secara mendalam
Agen keamanan Depthfirst
- Agen coding dan agen keamanan dapat menggunakan model dasar yang sama, tetapi tujuannya sangat berbeda
- Agen coding biasanya menerima tugas dari manusia dan berfokus pada penulisan kode aplikasi
- Agen keamanan mengambil peran yang sempit dan sangat berorientasi tujuan untuk menemukan isu keamanan nyata yang bisa dieksploitasi dalam sistem yang sudah ada, tanpa instruksi spesifik
- Agen keamanan harus terlebih dahulu memahami arsitektur codebase, parser dan protocol handler yang terekspos, serta titik masuk bagi input yang dikendalikan penyerang
- Setelah itu, agen tidak memperlakukan repositori sebagai kumpulan file yang datar, melainkan mengikuti komponen terkait dari kode permukaan serangan untuk melacak aliran data
- Agen keamanan yang praktis memerlukan guardrail agar tidak mengarang kondisi yang hilang, membesar-besarkan bug teoretis, atau menghasilkan banyak false positive
- Agen harus memastikan apakah penyerang benar-benar dapat mengendalikan input yang valid, apakah jalur rentan dapat dicapai, dan apakah cacat yang dicurigai dapat direproduksi
- Jika perlu, agen harus mengidentifikasi atau membuat harness yang berinteraksi dengan komponen target untuk menguji hipotesis secara konkret
- Agen keamanan khusus milik depthfirst menganalisis kode secara mendalam dan menguji beberapa hipotesis secara paralel
- Hasilnya bukan laporan teoretis atau peringatan yang samar, melainkan isu keamanan konkret yang terverifikasi eksekusinya dengan input yang dapat direproduksi
Hasil temuan
- Agen menemukan total 21 zero-day, dengan cakupan dari TS demuxer hingga VP9 decoder
- Total biaya sekitar $1k, setara sekitar 10% dari biaya yang dikeluarkan Anthropic untuk penggunaan Mythos
- Perbandingan biaya: {b:1,10}
-
Kerentanan yang telah diberi CVE
- CVE-2026-39210 adalah heap buffer overflow di TS demuxer akibat tidak adanya pemeriksaan batas panjang sebelum membaca dua byte, masuk pada 2010
- CVE-2026-39211 adalah integer overflow yang masuk saat refactoring swscale, ketika rumus faktor ukuran tanpa batas atas memungkinkan parameter yang dikendalikan pengguna memicu scaling yang sewenang-wenang besar, masuk pada 2010
- CVE-2026-39212 adalah stack overflow di
ffmpeg_opt.c, ketika file preset dapat memicu parsing opsi secara rekursif tanpa batas kedalaman, masuk sebagai regresi pada Juli 2025
- CVE-2026-39213 adalah heap buffer overflow di jalur input rawvideo yuv4mpegenc akibat tidak adanya validasi dimensi terhadap ukuran paket, masuk pada 2023
- CVE-2026-39214 adalah stack buffer overflow di implementasi SDT asli yang menulis entri layanan tanpa melacak ruang yang tersisa, masuk pada 2003 dan tetap laten selama 23 tahun
- CVE-2026-39215 adalah heap buffer overflow akibat kesalahan logika di
update_mb_info() yang membuat panggilan berikutnya menulis 12 byte di belakang buffer yang dialokasikan, masuk pada 2012
- CVE-2026-39216 adalah heap buffer overflow di
img2enc.c yang muncul setelah ukuran chroma aman diganti dengan ukuran tak terbatas berbasis dimensi, masuk pada 2012
- CVE-2026-39217 adalah heap buffer overflow di VP9 decoder karena fungsi pembaruan ukuran hasil refactoring membuat tile thread buffer melewatkan realloc yang diperlukan, masuk sebagai regresi pada Maret 2025
- CVE-2026-39218 adalah heap buffer overflow di DASH demuxer karena nilai duration negatif tidak ditolak, sehingga indeks array fragmen menjadi negatif, masuk pada 2017
-
Kerentanan yang dirujuk dengan ID pelacakan internal
- DFVULN-127 adalah heap buffer overflow ketika
av1_handle_packet() pada RTP AV1 depacketizer melewati Temporal Delimiter OBU dan memajukan posisi output sebesar obu_size tanpa mengalokasikan ruang sebesar itu, sehingga OBU berikutnya ditulis di luar batas buffer
- DFVULN-126 adalah heap buffer overflow ketika
run_legacy_unscaled() di kode swscale graph salah menangani konversi interlaced YUV420P→NV12 dan menulis 576 byte melewati target Y-plane
- DFVULN-125 adalah stack buffer overflow ketika
jpeg_create_header() pada RTP JPEG depacketizer membangun bagian quantization-table dalam stack buffer 1024 byte, lalu AV_WB16 setelah paket qtable_len >= 1024 menulis 2 byte melewati ujung
- DFVULN-124 adalah heap buffer overflow ketika
istg_parse_tile_grid() di jalur AVIF overlay tidak menolak referensi dimg dengan 0 entri tile, menyebabkan out-of-bounds read pada alokasi heap 1 byte setelah unsigned wraparound
- DFVULN-123 adalah integer overflow ketika
latm_parse_packet() pada RTP LATM depacketizer melewati pemeriksaan batas melalui signed 32-bit addition overflow, sehingga memcpy membaca sekitar 1GB di belakang akhir heap buffer
- DFVULN-122 adalah heap buffer overflow ketika
aac_parse_packet() pada RTP MPEG-4 depacketizer menerima AU-headers-length 0, membuat alokasi 1 byte lalu membaca field 4 byte tanpa memastikan keberadaan header AU
- DFVULN-121 adalah heap buffer underflow ketika
read_seek() pada CAF demuxer tidak memeriksa nilai kembalian -1 dari av_index_search_timestamp() dan menggunakannya sebagai indeks array untuk mengakses index_entries[-1]
- DFVULN-120 adalah integer underflow ketika
ff_read_riff_info() pada AVI demuxer menerima size - 4 tanpa memastikan size >= 4, sehingga ukuran LIST chunk 0 mengalami underflow menjadi sekitar 4GB dan memicu alokasi sekitar 2GB
- DFVULN-119 adalah heap buffer overflow ketika penambahan yang tidak perlu di
opt_map() milik option parser membuat link-label salah diparsing sebagai file index dan menyimpan stream index -1, sehingga loop berikutnya membaca sebelum array AVStream**
- DFVULN-118 adalah heap buffer overflow ketika
rtsp_read_announce() pada jalur RTSP server memperlakukan Content-Length negatif sebagai valid, sehingga ANNOUNCE jarak jauh dengan Content-Length: -1 memicu penulisan out-of-bounds ke sdp[-1]
- DFVULN-117 adalah heap buffer overflow ketika
rtmp_calc_swfhash() pada klien RTMP hanya memeriksa in_size < 3 alih-alih in_size < 8, sehingga membaca 8 byte dari buffer minimal 3 byte
- DFVULN-116 adalah heap buffer overflow ketika
sdp_parse_line() pada parsing RTSP SDP menghitung strlen(control_url) - 1 pada string kosong, sehingga size_t wraparound menjadi SIZE_MAX dan menyebabkan pre-buffer read 1 byte
Dari marker frame yang dilewati hingga kontrol PC
- Dari 21 temuan, heap buffer overflow pada AV1 RTP depacketizer dapat dicapai dari jaringan tanpa flag khusus
- Korban hanya perlu menjalankan
ffmpeg -i rtsp://attacker/stream, dan satu paket 183 byte sudah cukup untuk mengubah alur eksekusi
- Saat FFmpeg mengambil stream RTSP, server mengirim video yang telah dienkode sebagai urutan paket RTP
- AV1 menyusun bitstream sebagai OBU (Open Bitstream Units), dan format payload RTP membagi OBU ini ke dalam beberapa paket
- Depacketizer FFmpeg bertugas menyusun kembali OBU yang terpecah menjadi elementary stream yang utuh
- Temporal Delimiter (TD) adalah penanda kecil yang membedakan satu temporal unit, yaitu sebuah frame, dari frame berikutnya
- Spesifikasi menyatakan bahwa TD di dalam payload harus “ignore and remove” oleh depacketizer
- Proses “ignore and remove” inilah yang menjadi titik masalah, dan agen berhasil menangkap bagian tersebut
Akar penyebab
- Depacketizer membangun paket output secara bertahap, dengan kursor
pktpos yang melacak posisi byte berikutnya untuk ditulis di dalam pkt->data
pktpos dimulai dari akhir paket saat ini
// libavformat/rtpdec_av1.c:199
pktpos = pkt->size;
- Ketika kode menelusuri elemen OBU di dalam paket, setiap byte yang benar-benar dikeluarkan selalu didahului oleh pemanggilan
av_grow_packet, yang memperbesar alokasi heap untuk pkt->data
- Invarian yang menjadi dasar seluruh rutin ini adalah bahwa
pktpos tidak boleh melampaui ukuran alokasi pkt->data
- Kode penanganan Temporal Delimiter melanggar invarian tersebut
// libavformat/rtpdec_av1.c:250
if ((obu_type == AV1_OBU_TEMPORAL_DELIMITER) ||
(obu_type == AV1_OBU_TILE_LIST)) {
pktpos += obu_size;
rem_pkt_size -= obu_size;
obu_cnt++;
continue;
}
- Saat TD dilewati,
pktpos maju sebesar obu_size yang dideklarasikan penyerang, tetapi memori pendukung untuk perpindahan itu tidak dialokasikan
- Pointer input
buf_ptr juga tidak digeser melewati byte TD
- Jika TD memiliki
obu_size = 148, maka pktpos menjadi 148, sementara pkt->data masih belum dialokasikan atau mungkin jauh lebih kecil dari 148 byte
- Iterasi berikutnya kembali mem-parsing byte TD itu sendiri, membaca ulang byte header TD sebagai panjang OBU baru, dan menggunakan payload sebagai isi OBU yang telah dimanipulasi
- Pada OBU normal berikutnya, paket hanya diperbesar sebesar ukuran OBU tersebut
// libavformat/rtpdec_av1.c:296
if ((result = av_grow_packet(pkt, output_size)) < 0)
return result;
// libavformat/rtpdec_av1.c:304 / 336
pkt->data[pktpos++] = *buf_ptr++ | AV1F_OBU_HAS_SIZE_FIELD;
memcpy(pkt->data + pktpos, buf_ptr, obu_payload_size);
- Jika OBU yang dimanipulasi berukuran 17 byte,
av_grow_packet akan mengalokasikan buffer 81 byte dengan menambahkan 17 byte dan input padding 64 byte milik FFmpeg
- Penulisan dimulai dari
pkt->data[148], sehingga terjadi 67 byte di belakang akhir alokasi
- Cacat ini menjadi heap buffer overflow dengan offset dan isi yang sama-sama dapat dikendalikan penyerang
Cara eksploitasi
- Agar overflow yang dapat dikendalikan berguna, harus ada target yang bisa ditimpa tepat setelah buffer, dan allocator FFmpeg menyediakan target itu
- Saat
av_grow_packet mengalokasikan buffer data paket, ia melewati av_buffer_alloc, yang mengalokasikan buffer data, struct bookkeeping AVBuffer, dan AVBufferRef secara berurutan di heap
- FFmpeg melakukan alokasi melalui
posix_memalign dengan alignment 64 byte, sehingga buffer data 81 byte menempati chunk 128 byte dan struct AVBuffer ditempatkan tepat setelahnya
- Struct
AVBuffer memiliki function pointer yang digunakan sebagai callback pembebasan
// libavutil/buffer_internal.h
struct AVBuffer {
uint8_t *data; // +0
size_t size; // +8
atomic_uint refcount; // +16
void (*free)(void *opaque, uint8_t *data); // +24
void *opaque; // +32
...
};
- Jika dihitung dari awal buffer data, pointer
AVBuffer.free berada pada offset 152
- Dengan
obu_size = 148 pada TD, penulisan dimulai dari pkt->data[148]
- Byte header TD
0x10 ditafsirkan ulang sebagai panjang 16, lalu header dan payload dari OBU 16 byte yang dimanipulasi ditulis mulai offset 148
AVBuffer.refcount berada pada offset 144–147, sehingga tetap berada sebelum titik awal penulisan 148 dan mempertahankan nilai aslinya yaitu 1- Eksploit menyisipkan OBU manipulasi ketiga di dalam payload TD untuk memicu
av_grow_packet sekali lagi
- Karena buffer dibuat oleh
av_buffer_alloc, bukan av_buffer_realloc, buffer itu tidak ditandai sebagai reallocatable, sehingga FFmpeg mengambil jalur yang mengalokasikan buffer baru lalu membebaskan buffer lama
// libavutil/buffer.c:209
if (!(buf->buffer->flags_internal & BUFFER_FLAG_REALLOCATABLE) || ...) {
ret = av_buffer_realloc(&new, size);
memcpy(new->data, buf->data, ...);
buffer_replace(pbuf, &new);
return 0;
}
buffer_replace menurunkan refcount buffer lama dari 1 menjadi 0, lalu memanggil callback pembebasan
// libavutil/buffer.c:129
if (atomic_fetch_sub_explicit(&b->refcount, 1, memory_order_acq_rel) == 1) {
b->free(b->opaque, b->data);
}
- Pada titik ini, pointer
free yang telah ditimpa dipanggil, sehingga kontrol instruction pointer menjadi mungkin
- Pada release build, satu paket RTP 183 byte membuat
rip menjadi 0xdeadbeef
#0 0x00000000deadbeef in ?? ()
rip 0xdeadbeef 0xdeadbeef
#1 buffer_replace (buffer.c:133)
#2 av_buffer_realloc (buffer.c:220)
#3 av_grow_packet (packet.c:151)
#4 av1_handle_packet (rtpdec_av1.c:296)
#5 rtp_parse_packet_internal (rtpdec.c:743)
Cakupan dampak dan PoC
- Lingkungan deployment yang membuat FFmpeg membuka URL RTSP yang dapat dipengaruhi penyerang terekspos pada kerentanan ini
- Media ingest pipeline yang mengambil stream URL dari pengguna termasuk dalam cakupan dampak
- Sistem surveillance dan CCTV yang mengambil feed RTSP termasuk dalam cakupan dampak
- Layanan transcoding yang memproses sumber AV1-over-RTP jarak jauh termasuk dalam cakupan dampak
- Tidak diperlukan autentikasi atau interaksi pengguna selain membuka stream, dan tidak diperlukan flag command-line yang tidak biasa
- Kerentanan dipicu pada tahap RTSP
PLAY biasa yang memang dilakukan klien-klien ini secara desain
- Kode PoC tersedia di ffmpeg-dfvuln127
1 komentar
Komentar Hacker News
FFmpeg punya rekam jejak yang sangat buruk dalam hal keamanan
Sudah lama sekali, setiap kali menjalankan fuzzer, bug korupsi memorinya seolah keluar tanpa habis, dan 10 tahun lalu bahkan ada pekerjaan dari karyawan Google: https://security.googleblog.com/2014/01/ffmpeg-and-thousand-...
Jadi, meski ini memang demo yang menunjukkan kemampuan LLM, ini bukan sesuatu yang mengejutkan. Jika menangani konten yang tidak tepercaya atau diberikan pengguna, FFmpeg tidak boleh dijalankan di luar sandbox, dan melakukan itu berarti mengambil risiko yang tidak masuk akal
Ada kerentanan pada codec yang sangat niche, yang mungkin cuma dipakai di satu video game tahun 90-an, dan pelapornya membesar-besarkan seolah itu masalah besar, padahal menurut mereka itu nyaris bukan apa-apa karena codec tersebut hampir tidak dipakai
Tetapi saya jadi bertanya-tanya apakah mereka tidak menyadari bahwa jika penyerang bisa menyediakan file video, mereka bisa memilih codec video mana pun yang mereka mau. Walaupun pengembang menganggap codec itu sama sekali tidak dipakai, kalau masih bisa digunakan, penyerang tetap bisa memakainya
Saya penasaran apakah ada sesuatu yang saya lewatkan, alasan yang benar-benar masuk akal mengapa kerentanan pada codec ini memang bukan masalah besar
Sampai baru-baru ini bahkan tidak ada konteks native virtio GPU, jadi mustahil menyandbox pemutar video tanpa kehilangan seluruh akselerasi perangkat keras. Setidaknya sulit jika dipaksakan dari luar; secara internal tetap bisa seperti Chromium, yaitu mengisolasi FFmpeg dan menguncinya ketat dengan seccomp
Ini bukan masalah FFmpeg saja. Apple juga punya tak terhitung banyaknya kerentanan decoder gambar dan video. Bidang ini sendiri memang sangat sulit, dan FFmpeg melakukan lebih banyak hal daripada siapa pun
Menurut saya industri sedang mengoptimalkan hal yang salah. Sangat mudah membuat ribuan laporan bug yang ditulis AI dengan sesuatu seperti Mythos preview 1 atau GPT-5.5. Yang sulit adalah benar-benar memperbaiki bugnya
Selama beberapa bulan terakhir saya sedang membangun sistem yang membuka PR alih-alih hanya mengirim laporan setelah menemukan isu keamanan kritis. Sejauh ini tingkat penerimaannya sekitar 94%. Sebagian besar kegagalan bukan karena salah menilai kerentanan, melainkan karena kill switch khusus proyek yang tidak terdokumentasi atau mekanisme internal tertentu
Para pengembang tampaknya jauh lebih menyukai pendekatan ini. Laporan bug menambah pekerjaan, PR yang bagus mengurangi pekerjaan. Kedengarannya jelas, tetapi banyak produk keamanan katanya masih berhenti di laporan saja
Sudah seperti itu sejak industri ini ada, dan baru sekarang kita mulai punya alat yang memadai untuk menilai dampaknya dan rapuhnya sistem secara keseluruhan
Bug ini serius karena jangkauan paparnya. Setiap deployment yang membuat FFmpeg mengakses URL RTSP yang dipengaruhi penyerang akan terekspos
Ini mencakup pipeline ingest media yang mengambil URL stream dari pengguna, sistem pengawasan/CCTV yang menarik feed RTSP, layanan transcoding yang memproses sumber AV1-over-RTP jarak jauh, dan sebagainya. Secara nyata ini cukup serius, sampai-sampai fakta bahwa ini dipublikasikan justru terasa mengejutkan. Saya langsung bisa membayangkan beberapa layanan yang tampaknya bisa dieksploitasi sekarang juga
Walaupun ini mungkin tidak sebesar kesannya dan terlihat seperti iklan perusahaan keamanan, ini mengingatkan bahwa di suatu tempat dalam setiap aplikasi yang Anda rilis selalu ada lubang keamanan, dan sekarang bahkan script kiddie pun bisa menemukannya 5 menit setelah rilis dengan kredit senilai 2 dolar
Jika Anda tidak memvalidasi kode dengan red team sebelum rilis, para peretas akan melakukannya untuk Anda setelah rilis
Istilah zero-day dipakai secara berlebihan. Dari kerentanan yang dijelaskan, sebenarnya tidak ada yang benar-benar zero-day, tetapi menyebutnya begitu terdengar keren dan bagus untuk klik
Kalimat “pada titik ini free pointer yang sudah rusak dipanggil, dan kendali instruction pointer ada pada kita” itu sangat serius
Hanya saja, dalam praktiknya tampaknya bug ini saja belum cukup untuk mencapai remote code execution arbitrer. Terutama jika ada ASLR, dan juga harus ada halaman memori yang writable sekaligus executable di suatu tempat
Tetap saja, untuk membobol ASLR masih dibutuhkan eksploit lain
Itu bukan arti dari “zero-day”
Struktur insentif dalam bidang riset keamanan rusak sampai ke akar
Mereka seperti manajer menengah di dunia FOSS. Mereka dipuji karena melempar lebih banyak pekerjaan ke sukarelawan, dan makin mendesak pekerjaannya, makin besar pujiannya. Mengakui dampak nyata sebuah isu atau implikasi praktisnya justru bertentangan dengan insentif mereka
Sulit untuk tidak melihat mereka sebagai petugas pembersih paling bawah di industri perangkat lunak, dan rasanya sudah saatnya mereka mulai diperlakukan seperti pihak yang dikucilkan. Kirim PR, atau diam saja katanya
Saya pribadi sudah sangat lama memakai FFmpeg, begitu juga di layanan yang saya buat. Fabrice Bellard adalah seorang jenius, dan para pengembang yang membawa FFmpeg sampai sejauh ini telah membuat dunia secara terukur menjadi lebih makmur
Tapi, jika dijalankan dengan input yang tidak tepercaya, saya sulit memikirkan program lain yang lebih layak di-sandbox selain FFmpeg. Alasannya, basis kode C yang sangat besar menangani codec video dan audio yang kompleks, yang memang terkenal sangat sulit dibuat sepenuhnya benar
Meski begitu, dalam praktiknya ini bukan masalah besar. Jalankan FFmpeg di dalam VM atau gVisor, dan hasil akhirnya biasanya berupa berkas video yang memang bersedia Anda putar di browser. Di browser pun berkas itu akan didekode lagi di dalam sandbox lain, jadi ini memang dari awal persoalan yang sulit
Sandbox yang aman sering kali menjadi peluang untuk memungkinkan penyalinan tanpa batas
Ini adalah kerentanan di kode depacketisasi balik RTP LATM, di mana
latm_parse_packet()melakukan penjumlahan 32-bit bertanda yang mengalami overflow lalu melewati pemeriksaan batasSekali lagi, kerentanan muncul karena penjumlahan tanpa pemeriksaan. Namun bahasa modern seperti Rust atau Go pun tidak melempar pengecualian saat overflow, dan arsitektur CPU modern seperti RISC-V juga tidak menyediakan overflow trap. Bahasa lama seperti C atau C++ jelas juga tidak punya pemeriksaan overflow
Konyol rasanya. Sudah jelas kita tidak bisa mempercayai manusia untuk selalu menulis kode aritmetika yang benar
Perilaku default integer overflow Rust di mode rilis juga terdefinisi; nilainya hanya akan wrapping. Jadi kemungkinannya lebih kecil berujung menjadi kerentanan. Tentu ceritanya berbeda jika mulai memakai unsafe Rust
Rust memang tidak melempar pengecualian overflow secara default, tetapi bisa ditulis seperti
123.checked_add(321). Hasilnya kode jadi lebih sulit dibaca, tetapi aman terhadap overflowSejujurnya, untuk cara saya menulis kode, bentuk seperti komentar di akhir baris akan lebih saya sukai. Misalnya
var x = y + z; # wrappedKemungkinan mencampur aritmetika wrapping, checked, dan saturating dalam satu baris itu sangat kecil. Di Zig, setiap baris harus bisa dikompilasi dengan sendirinya tanpa konteks kode lain, jadi status compiler seperti
doing(wrapped) { x + y }tidak dimungkinkan. Nama fungsi terlalu bertele-tele, dan type cast juga terlalu bertele-tele. Pengubah tingkat pernyataan mungkin bisa menjadi jalan tengah yang baik