FFmpeg के इक्कीस zero-day

 (depthfirst.com)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • दुनिया भर के browsers और streaming infrastructure में media को process करने वाला FFmpeg जटिल और अविश्वसनीय input को parse करता है, इसलिए यह security के लिहाज़ से एक महत्वपूर्ण attack surface बनता है
  • depthfirst के स्वायत्त security agent ने लगभग 15 लाख lines के optimized C code में 21 zero-day खोजे, और इसकी लागत लगभग $1k रही, जो Anthropic के Mythos उपयोग-खर्च $10k का लगभग 10% थी
  • खोजे गए मुद्दे TS demuxer, VP9 decoder, RTP/RTSP/RTMP processing paths समेत कई components में फैले हैं, और कुछ vulnerabilities 15–20 साल तक छिपी रहीं
  • AV1 RTP depacketizer vulnerability ने सिर्फ 183-byte RTP packet से function pointer overwrite करने वाले PoC तक पहुँच बनाई, और यह केवल ffmpeg -i rtsp://attacker/stream चलाने भर से trigger हो सकती है
  • वास्तविक security verification के लिए सिर्फ सैद्धांतिक warning नहीं, बल्कि reproducible input और execution confirmation तक ज़रूरी है; agentic analysis का उपयोग बड़े C codebase में छिपी vulnerabilities खोजने में सीधे किया जा सकता है

अवलोकन

  • FFmpeg एक व्यापक रूप से deploy किया गया software है, जो browsers और बड़े streaming platform infrastructure में media process करता है
  • क्योंकि यह लगातार जटिल और अविश्वसनीय media को parse करने वाली library है, इसलिए यह security के लिए महत्वपूर्ण है और zero-click attacks का प्रमुख target बनता है
  • FFmpeg repository लगभग 15 लाख lines के अत्यधिक optimized C code से बनी है और सैकड़ों जटिल media formats को parse करती है
  • FFmpeg पर 20 साल से अधिक समय से fuzzing और manual audit होते रहे हैं, और हाल में Google Big Sleep टीम ने FFmpeg में 13 vulnerabilities प्रकाशित कीं
  • Anthropic ने Mythos model से FFmpeg को scan करके कुछ security issues खोजे
  • ऐसे पूर्व कार्यों के बाद FFmpeg में नई vulnerabilities खोजना और कठिन हो गया, इसलिए यह बड़े codebase को गहराई से scan करने वाले agentic systems की क्षमता जाँचने का एक लक्ष्य बन गया

Depthfirst का security agent

  • coding agent और security agent एक ही base model का उपयोग कर सकते हैं, लेकिन उनके लक्ष्य काफी अलग होते हैं
  • coding agent आमतौर पर किसी व्यक्ति से task लेकर application code लिखने पर केंद्रित होता है
  • security agent बिना किसी ठोस निर्देश के मौजूदा system में वास्तव में exploitable security issues खोजने की संकीर्ण और लक्ष्य-उन्मुख भूमिका निभाता है
  • security agent को पहले codebase की architecture, exposed parsers और protocol handlers, तथा attacker-controlled input के entry points को समझना होता है
  • इसके बाद वह repository को files के सपाट समूह की तरह नहीं, बल्कि attack surface code से जुड़े components का पीछा करते हुए data flow ट्रैक करके देखता है
  • एक व्यावहारिक security agent के लिए ऐसे guardrails ज़रूरी हैं जो missing conditions गढ़ने, theoretical bug को बढ़ा-चढ़ाकर बताने, या बड़ी संख्या में false positives देने से रोकें
  • यह जाँचना ज़रूरी है कि क्या attacker वास्तव में सही input नियंत्रित कर सकता है, क्या vulnerable path तक पहुँचा जा सकता है, और क्या संदिग्ध defect reproducible है
  • ज़रूरत पड़ने पर target component के साथ interact करने वाला harness पहचानना या बनाना पड़ता है, ताकि hypothesis को ठोस रूप से परखा जा सके
  • depthfirst का विशेषीकृत security agent code का गहराई से analysis करता है और कई hypotheses को parallel branches में बाँटकर test करता है
  • इसका output कोई theoretical report या अस्पष्ट warning नहीं, बल्कि reproducible concrete input के साथ execution द्वारा verified security issues होते हैं

खोज के नतीजे

  • agent ने कुल 21 zero-day खोजे, जिनकी range TS demuxer से VP9 decoder तक फैली हुई है
  • कुल लागत लगभग $1k रही, जो Anthropic द्वारा Mythos पर किए गए खर्च का लगभग 10% है
  • लागत तुलना: {b:1,10}

  • CVE आवंटित vulnerabilities

    • CVE-2026-39210 TS demuxer में heap buffer overflow है, जहाँ दो bytes पढ़ने से पहले length boundary check नहीं था; यह 2010 में आया
    • CVE-2026-39211 swscale refactoring के दौरान upper bound के बिना size coefficient formula से पैदा हुआ integer overflow है, जहाँ user-controlled parameter मनमाने बड़े scaling को trigger कर सकता था; यह 2010 में आया
    • CVE-2026-39212 ffmpeg_opt.c में stack overflow है, जहाँ preset file गहराई की सीमा के बिना recursive option parsing trigger कर सकती थी; यह July 2025 regression से आया
    • CVE-2026-39213 yuv4mpegenc rawvideo input path में heap buffer overflow है, जहाँ packet size के लिए dimension validation नहीं था; यह 2023 में आया
    • CVE-2026-39214 मूल SDT implementation में stack buffer overflow है, जहाँ remaining space track किए बिना service entries लिखी जाती थीं; यह 2003 में आया और 23 साल तक latent रहा
    • CVE-2026-39215 update_mb_info() के अंदर logic error से पैदा हुआ heap buffer overflow है, जहाँ बाद का call allocated buffer के बाद 12 bytes लिखता है; यह 2012 में आया
    • CVE-2026-39216 img2enc.c में heap buffer overflow है, जो safe chroma size को dimension-based unbounded size से बदलने से पैदा हुआ; यह 2012 में आया
    • CVE-2026-39217 VP9 decoder में heap buffer overflow है, जहाँ refactored size update function के कारण tile thread buffer आवश्यक reallocation चूक जाता है; यह March 2025 regression से आया
    • CVE-2026-39218 DASH demuxer में heap buffer overflow है, जहाँ negative duration value को reject नहीं किया गया और fragment array index negative हो गया; यह 2017 में आया

  • आंतरिक tracking ID से संदर्भित vulnerabilities

    • DFVULN-127 RTP AV1 depacketizer में av1_handle_packet() से जुड़ा heap buffer overflow है, जहाँ Temporal Delimiter OBU को skip करते समय obu_size के बराबर output position आगे बढ़ाई जाती है लेकिन उतनी space allocate नहीं की जाती, जिससे अगला OBU buffer boundary के बाहर लिखा जाता है
    • DFVULN-126 swscale graph code के run_legacy_unscaled() में heap buffer overflow है, जो interlaced YUV420P→NV12 conversion को गलत handle करके target Y-plane से 576 bytes आगे लिखता है
    • DFVULN-125 RTP JPEG depacketizer के jpeg_create_header() में stack buffer overflow है, जहाँ 1024-byte stack buffer में quantization-table section बनाते समय qtable_len >= 1024 packet के बाद AV_WB16 अंत से 2 bytes आगे लिख देता है
    • DFVULN-124 AVIF overlay path के istg_parse_tile_grid() में heap buffer overflow है, जहाँ zero tile entries वाले dimg reference को reject नहीं किया जाता, जिससे unsigned wraparound के बाद 1-byte heap allocation पर out-of-bounds read होता है
    • DFVULN-123 RTP LATM depacketizer के latm_parse_packet() में integer overflow है, जहाँ signed 32-bit addition overflow boundary check को bypass कर देता है और memcpy heap buffer के अंत से लगभग 1GB आगे पढ़ता है
    • DFVULN-122 RTP MPEG-4 depacketizer के aac_parse_packet() में heap buffer overflow है, जहाँ AU-headers-length 0 स्वीकार करके 1-byte allocation बनती है, फिर AU header मौजूद है या नहीं इसकी जाँच किए बिना 4-byte field पढ़ी जाती है
    • DFVULN-121 CAF demuxer के read_seek() में heap buffer underflow है, जहाँ av_index_search_timestamp() का return value -1 जाँचे बिना array index की तरह उपयोग किया जाता है और index_entries[-1] access होता है
    • DFVULN-120 AVI demuxer के ff_read_riff_info() में integer underflow है, जहाँ size >= 4 की जाँच के बिना size - 4 लिया जाता है, जिससे LIST chunk size 0 पर लगभग 4GB का underflow और लगभग 2GB allocation trigger होती है
    • DFVULN-119 option parser के opt_map() में अनावश्यक increment के कारण heap buffer overflow होता है, जो link-label को file index की तरह गलत parse करता है और stream index -1 store करता है, जिससे बाद का loop AVStream** array के पहले पढ़ता है
    • DFVULN-118 RTSP server path के rtsp_read_announce() में heap buffer overflow है, जहाँ negative Content-Length को valid माना जाता है और remote ANNOUNCE के साथ Content-Length: -1 भेजकर sdp[-1] पर out-of-bounds write कराया जा सकता है
    • DFVULN-117 RTMP client के rtmp_calc_swfhash() में heap buffer overflow है, जहाँ in_size < 8 की जगह केवल in_size < 3 जाँचा जाता है, जिससे न्यूनतम 3-byte buffer से 8 bytes पढ़े जाते हैं
    • DFVULN-116 RTSP SDP parsing के sdp_parse_line() में heap buffer overflow है, जहाँ empty string पर strlen(control_url) - 1 की गणना से size_t SIZE_MAX में wrap हो जाता है और 1-byte pre-buffer read होता है

skipped frame marker से PC control तक

  • 21 खोजों में से AV1 RTP depacketizer का heap buffer overflow network से बिना किसी विशेष flag के पहुँचा जा सकता है
  • victim को बस ffmpeg -i rtsp://attacker/stream चलाना होता है, और एक single 183-byte packet execution flow बदल सकता है
  • जब FFmpeg RTSP stream fetch करता है, तो server encoded video को RTP packet sequence के रूप में भेजता है
  • AV1 bitstream को OBU (Open Bitstream Units) में व्यवस्थित करता है, और RTP payload format इन OBU को कई packets में बाँटता है
  • FFmpeg का depacketizer विभाजित OBU को फिर से एक साफ elementary stream में जोड़ने का काम करता है
  • Temporal Delimiter (TD) एक छोटा marker है, जो एक temporal unit यानी एक frame और अगले frame के बीच अंतर बताता है
  • specification कहती है कि payload के अंदर मौजूद TD को depacketizer को “ignore and remove” करना चाहिए
  • यही “ignore and remove” handling समस्या का बिंदु बनी, और agent ने इसी जगह को पकड़ा

मूल कारण

  • depacketizer output packet को धीरे-धीरे बनाता है, और pktpos cursor pkt->data में अगला byte कहाँ लिखा जाएगा, इसका track रखता है
  • pktpos packet के मौजूदा अंत से शुरू होता है
// libavformat/rtpdec_av1.c:199
pktpos = pkt->size;
  • जब code packet के अंदर OBU elements पर iterate करता है, तब वास्तव में output होने वाले हर byte से पहले av_grow_packet call होता है, और यही call pkt->data की heap allocation बढ़ाता है
  • पूरे routine का invariant यह है कि pktpos कभी भी pkt->data की allocated size से आगे नहीं जाना चाहिए
  • Temporal Delimiter handling code इस invariant को तोड़ देता है
// 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;
}
  • TD को skip करते समय pktpos attacker द्वारा घोषित obu_size जितना आगे बढ़ जाता है, लेकिन उस movement को support करने वाली memory allocate नहीं होती
  • input pointer buf_ptr भी TD bytes के बाद आगे नहीं बढ़ता
  • यदि TD का obu_size = 148 हो, तो pktpos 148 हो जाता है, लेकिन pkt->data अब भी unallocated हो सकता है या 148 bytes से बहुत छोटा हो सकता है
  • अगला iteration TD के bytes को फिर parse करता है, TD header byte को नए OBU length की तरह फिर पढ़ता है, और payload को manipulated OBU content की तरह इस्तेमाल करता है
  • अगले normal OBU पर packet केवल उस OBU size के बराबर बढ़ता है
// 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);
  • यदि manipulated OBU 17 bytes का हो, तो av_grow_packet 17 bytes और FFmpeg की 64-byte input padding जोड़कर 81-byte buffer allocate करता है
  • write pkt->data[148] से शुरू होती है और allocation के अंत से 67 bytes आगे होती है
  • यह defect ऐसा heap buffer overflow बन जाता है जिसमें attacker offset और content दोनों नियंत्रित कर सकता है

exploitation कैसे होता है

  • किसी controllable overflow के उपयोगी होने के लिए buffer के ठीक बाद कोई overwrite करने योग्य target होना चाहिए, और FFmpeg का allocator ऐसा target प्रदान करता है
  • जब av_grow_packet packet data buffer allocate करता है, तो वह av_buffer_alloc से होकर गुजरता है, और यह function data buffer, AVBuffer bookkeeping struct, और AVBufferRef को क्रम से heap पर allocate करती है
  • FFmpeg 64-byte aligned posix_memalign allocation उपयोग करता है, इसलिए 81-byte data buffer 128-byte chunk लेता है और AVBuffer struct उसके ठीक बाद रखा जाता है
  • AVBuffer struct में एक function pointer होता है, जो free callback के रूप में उपयोग होता है
// 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
    ...
};
  • data buffer की शुरुआत के आधार पर AVBuffer.free pointer offset 152 पर स्थित है
  • यदि TD का obu_size = 148 हो, तो write pkt->data[148] से शुरू होती है
  • TD header byte 0x10 को फिर length 16 की तरह interpret किया जाता है, और manipulated 16-byte OBU का header और payload offset 148 से लिखा जाता है
  • AVBuffer.refcount offset 144–147 पर है, इसलिए write start point 148 से पहले बचा रहता है और इसका मूल value 1 बना रहता है
  • exploit TD payload के अंदर तीसरा manipulated OBU रखता है ताकि एक और av_grow_packet trigger हो
  • क्योंकि buffer av_buffer_realloc की बजाय av_buffer_alloc से बना था, इसलिए वह reallocatable के रूप में mark नहीं होता, और FFmpeg नया buffer allocate करके पुराने buffer को free करने वाला path चुनता है
// 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 पुराने buffer का refcount 1 से 0 तक घटाता है और free callback call करता है
// libavutil/buffer.c:129
if (atomic_fetch_sub_explicit(&b->refcount, 1, memory_order_acq_rel) == 1) {
    b->free(b->opaque, b->data);
}
  • इस बिंदु पर overwrite किया गया free pointer call होता है, और instruction pointer पर control संभव हो जाता है
  • release build में एक single 183-byte RTP packet ने rip को 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)

प्रभाव का दायरा और PoC

  • वे deployment environments, जहाँ FFmpeg को attacker-influenced RTSP URL खोलना पड़ता है, इस vulnerability के संपर्क में हैं
  • media ingest pipeline जो user-provided stream URL fetch करती है, प्रभाव क्षेत्र में आती है
  • RTSP feed fetch करने वाली surveillance और CCTV systems प्रभाव क्षेत्र में आती हैं
  • remote AV1-over-RTP source process करने वाली transcoding services प्रभाव क्षेत्र में आती हैं
  • authentication या stream खोलने से अधिक किसी user interaction की आवश्यकता नहीं है, और कोई असामान्य command-line flag भी नहीं चाहिए
  • vulnerability इन्हीं clients के सामान्य RTSP PLAY चरण में trigger होती है, जो वे design के अनुसार वैसे भी करते हैं
  • PoC code ffmpeg-dfvuln127 पर उपलब्ध है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News की राय

  • FFmpeg का सुरक्षा के मामले में रिकॉर्ड असामान्य रूप से खराब रहा है
    बहुत पहले से, जब भी fuzzer चलाया जाता था, लगभग अंतहीन memory corruption bugs निकलते थे, और 10 साल पहले Google कर्मचारियों का काम भी था: https://security.googleblog.com/2014/01/ffmpeg-and-thousand-...
    इसलिए यह LLM की क्षमता दिखाने वाला एक demo तो है, लेकिन चौंकाने वाली बात नहीं है। अगर आप untrusted या user-provided content हैंडल कर रहे हैं, तो FFmpeg को sandbox के बाहर run नहीं करना चाहिए, और ऐसा करना बेवजह का जोखिम लेना है

    • FFmpeg पक्ष ने लगातार यह शिकायत जताई है कि project vulnerabilities को सार्वजनिक करने वाले लोग बहुत हैं, लेकिन उन्हें ठीक करने के लिए patch work करने वाले लोग उसकी तुलना में बहुत कम हैं
    • हाल ही में Lex Fridman podcast में FFmpeg developers आए थे और security की बात भी हुई थी
      90 के दशक के किसी video game में ही इस्तेमाल होने वाले एक बेहद niche codec में vulnerability थी, और रिपोर्ट करने वाला इसे बहुत बड़ा मुद्दा बता रहा था, लेकिन उनकी बात कुछ ऐसी थी कि यह वास्तव में लगभग इस्तेमाल ही नहीं होता, इसलिए बड़ी बात नहीं है
      लेकिन अगर attacker video file दे सकता है, तो वह कोई भी video codec मनचाहा चुन सकता है। भले ही developer सोचें कि वह codec बिल्कुल इस्तेमाल नहीं होता, अगर वह अब भी उपलब्ध है, तो attacker उसे इस्तेमाल कर सकता है
      सोच रहा था कि कहीं मैं कुछ मिस तो नहीं कर रहा, या क्या कोई वाजिब वजह है कि इस codec की vulnerability सच में बड़ी बात न हो
    • बिल्कुल। क्योंकि सबको FFmpeg की जगह इस्तेमाल करने के लिए स्पष्ट विकल्प पता है
    • FFmpeg को खुद sandbox करना मुश्किल नहीं है, लेकिन MPV/VLC जैसे FFmpeg इस्तेमाल करने वाले मामलों में यह ज्यादा पेचीदा है
      हाल तक virtio GPU native context नहीं था, इसलिए hardware acceleration पूरी तरह खोए बिना video player को sandbox करना भी संभव नहीं था। कम से कम बाहर से मजबूर करके करना मुश्किल था; अंदरूनी तौर पर Chromium की तरह FFmpeg को isolate करके seccomp से सख्ती से बाँधा जा सकता था
    • FFmpeg एक बेहद जटिल क्षेत्र में काम करता है, और यह बहुत जटिल software है जिसे performance पर अत्यधिक ध्यान देना पड़ता है
      यह सिर्फ FFmpeg की समस्या नहीं है। Apple में भी image और video decoder vulnerabilities की गिनती करना मुश्किल रहा है। यह पूरा क्षेत्र ही बहुत कठिन है, और FFmpeg सबसे ज्यादा काम करने वालों में है

  • मुझे लगता है कि industry गलत चीज़ को optimize कर रही है। Mythos preview 1 या GPT-5.5 जैसी किसी चीज़ से AI-written bug reports हज़ारों में बनाना आसान है। मुश्किल काम है bugs को सच में ठीक करना
    कुछ महीनों से मैं ऐसा system बना रहा हूँ जो सिर्फ critical security issues ढूँढ़कर report करने के बजाय PR खोलता है। अभी तक acceptance rate लगभग 94% है। ज़्यादातर failures vulnerability का गलत आकलन नहीं थे, बल्कि undocumented project-specific kill switches या internal mechanisms की वजह से थे
    लगता है developers को यह तरीका ज़्यादा पसंद आता है। Bug reports काम बढ़ाती हैं, और अच्छे PR काम घटाते हैं। यह साफ़ बात लगती है, लेकिन बहुत से security products अब भी report देकर ही रुक जाते हैं

    • industry असल में speed, release time, और features को optimize करती है, और security considerations, accessibility, vendor lock-in, interoperability जैसी चीज़ों पर, जो short-term revenue नहीं लातीं, शुतुरमुर्ग जैसा मॉडल लागू करती है
      industry की शुरुआत से ऐसा ही रहा है, और अब जाकर हमारे पास उसके नुकसान और पूरे तंत्र की कमजोरी को आँकने के लिए सही tools बनने लगे हैं
    • लगता है यहाँ कुछ छूट रहा है। Apple software का open-source code तो है नहीं, फिर fixes सुझाने की बात कैसे की जा रही है, समझ नहीं आता

  • यह bug अपनी reach की वजह से गंभीर है। FFmpeg को attacker-affected RTSP URL की ओर देखने वाली हर deployment exposed है
    user-provided stream URL लेने वाली media ingestion pipelines, RTSP feeds लेने वाले surveillance/CCTV systems, और remote AV1-over-RTP sources प्रोसेस करने वाली transcoding services—सब इसमें आते हैं। वास्तव में यह काफी गंभीर है, और इसका public होना ही उल्टा हैरान करने वाला है। अभी इसी समय exploit हो सकने वाली कई services दिमाग में आती हैं

    • अगर आपको किसी गंभीर vulnerability का पता है, तो उसे public करना महत्वपूर्ण माना जा सकता है। क्योंकि software को vulnerable तरीके से इस्तेमाल करने वाले लोग risk कम करने के लिए कदम उठा सकते हैं
    • actual exploitation तक पहुँचने के लिए ASLR leak जैसी किसी अतिरिक्त चीज़ की ज़रूरत होगी
    • FFmpeg कई बार साफ़ कह चुका है कि उसे bugs या security reports की परवाह नहीं है

  • भले ही यह security company के विज्ञापन जैसा लगे और उतना बड़ा मामला न हो, फिर भी यह याद दिलाता है कि आपके हर shipped application में कहीं न कहीं security holes हैं, और अब script kiddies भी release के 5 मिनट बाद 2 डॉलर credit से उन्हें ढूँढ़ सकते हैं
    अगर आप release से पहले red team से code validate नहीं कराते, तो hackers release के बाद वह काम आपके लिए कर देंगे

  • zero-day शब्द को बढ़ा-चढ़ाकर इस्तेमाल किया जा रहा है। बताई गई vulnerabilities में असली zero-day एक भी नहीं है, लेकिन ऐसा कहने से बात असरदार लगती है और clicks अच्छे आते हैं

  • “इस point पर corrupted free pointer call होता है, और command pointer का control हमारे पास है” — यह बहुत गंभीर बात है
    लेकिन व्यवहार में सिर्फ इस bug से arbitrary remote code execution तक पहुँचना संभव नहीं लगता। खासकर ASLR होने पर, और कहीं writable तथा executable memory pages भी होने चाहिए

    • लेख में इस हिस्से को जल्दी पार कर लिया गया है, लेकिन structure का अगला variable संयोग से function का पहला argument है, इसलिए system() जैसी किसी चीज़ से arbitrary code execution संभव लगती है
      फिर भी ASLR तोड़ने के लिए एक अलग exploit चाहिए होगा

  • वह “zero-day” का मतलब नहीं है

    • लगता है Stuxnet की reporting के बाद यह शब्द popular तो हुआ, लेकिन अपना मतलब खो बैठा
    • अगर ऐसा कह रहे हैं, तो मतलब भी साथ में समझा देते। हो सकता है मैं भी इसकी definition गलत समझ रहा हूँ

  • security research क्षेत्र की incentive structure गहराई से टूटी हुई है
    ये लोग FOSS दुनिया के middle managers जैसे हैं। volunteers पर और ज़्यादा काम लादकर तारीफ़ पाते हैं, और काम जितना urgent हो, उतनी ज़्यादा तारीफ़ मिलती है। किसी issue के वास्तविक प्रभाव या व्यावहारिक निहितार्थ को स्वीकार करना उनकी incentives से टकराता है
    इन्हें software industry के bottom-feeders की तरह न देखना मुश्किल है, और अब समय आ गया है कि इनके साथ बहिष्कृत लोगों जैसा व्यवहार शुरू हो। PR भेजो, नहीं तो चुप रहो

  • मैंने FFmpeg को व्यक्तिगत रूप से भी, और अपनी बनाई सेवाओं में भी बहुत लंबे समय से इस्तेमाल किया है। Fabrice Bellard जीनियस हैं, और FFmpeg को यहां तक लाने वाले डेवलपर्स ने दुनिया को मापने लायक हद तक अधिक समृद्ध बनाया है
    लेकिन जब इसे अविश्वसनीय इनपुट के साथ चलाया जाता है, तो FFmpeg जितना sandboxing के लायक प्रोग्राम कोई और याद नहीं आता। वजह यह है कि बेहद जटिल video·audio codecs, जिन्हें पूरी तरह सही बनाना बदनाम रूप से कठिन है, एक विशाल C codebase में संभाले जाते हैं
    फिर भी व्यवहार में यह इतना बड़ा मुद्दा नहीं है। FFmpeg को VM या gVisor के अंदर चलाया जा सकता है, और अंतिम आउटपुट आमतौर पर ऐसी video file होती है जिसे आप browser में चलाने को तैयार हों। browser में भी decoding एक और sandbox के अंदर होती है, इसलिए यह मूल रूप से कठिन काम है

    • एक उदास करने वाला अनुमान है कि DRM, “trusted platforms”, regulatory capture वगैरह चाहने वाली copyright-holding companies यहां नुकसान के कुछ हिस्से को बढ़ा-चढ़ाकर पेश करेंगी
      सुरक्षित sandboxing अक्सर unrestricted copying को संभव बनाने का अवसर बन जाती है
    • “ऐसी video file जिसे browser में चलाने को तैयार हों” से क्या मतलब है, यह समझ नहीं आया। क्या यह मान लेने पर कि कोई भी video file browser decoding sandbox से बाहर नहीं निकल सकती, वह सुरक्षित नहीं मानी जाएगी?
    • लेकिन encoding में अक्सर hardware accelerators की ज़रूरत पड़ती है, इसलिए आखिरकार फिर से C का इस्तेमाल करना पड़ता है

  • यह RTP LATM depacketization code में एक vulnerability है, जहां latm_parse_packet() signed 32-bit addition करते समय overflow कर देता है और boundary check को bypass कर जाता है
    फिर एक बार unchecked addition की वजह से vulnerability बनी, और इसके बावजूद Rust या Go जैसी modern languages overflow पर exception नहीं फेंकतीं, और RISC-V जैसी modern CPU architectures भी overflow trap नहीं देतीं। C या C++ जैसी पुरानी भाषाओं में तो overflow checks हैं ही नहीं
    यह हास्यास्पद है। यह साफ है कि इंसानों पर सही arithmetic code लिखने के लिए भरोसा नहीं किया जा सकता

    • Rust debug mode में overflow checks चालू करता है, और release mode में भी उन्हें चालू किया जा सकता है। लोग वास्तव में ऐसा करते भी हैं
      Rust के release mode में default integer overflow behavior भी defined है; वह बस wrapping करता है। इसलिए उसके vulnerability बनने की संभावना कम हो जाती है। बेशक, unsafe Rust इस्तेमाल करना शुरू करें तो बात अलग है
    • Zig overflow पर exception फेंकता है। saturating addition और wrapping addition के लिए +|=, +%= operators होते हैं
      Rust default रूप से overflow exception नहीं फेंकता, लेकिन 123.checked_add(321) जैसा लिखकर यह किया जा सकता है। तब code पढ़ना मुश्किल हो जाता है, लेकिन overflow के लिहाज से यह सुरक्षित रहता है
      सच कहूं तो, मैं जिस तरह code लिखता हूं, उसमें line-end comment जैसा रूप बेहतर लगेगा। जैसे var x = y + z; # wrapped
      एक ही line में wrapping·checked·saturating arithmetic को मिलाने की संभावना बहुत कम है। Zig में हर line बिना किसी दूसरे code context के अपने-आप compile हो सकनी चाहिए, इसलिए doing(wrapped) { x + y } जैसी compiler state नहीं हो सकती। function names बहुत लंबे हो जाते हैं, और type conversions भी बहुत लंबे हो जाते हैं। statement-level modifier एक अच्छा समझौता हो सकता है