फ़ज़िंग लैब: tmux के लिए फ़ज़िंग को बेहतर बनाना

सॉफ़्टवेयर सुरक्षा @ EPFL, स्प्रिंग 2025

सारांश

इस लैब में, हमने Google के OSS-Fuzz इंफ्रास्ट्रक्चर में tmux टर्मिनल मल्टीप्लेक्सर के लिए फ़ज़िंग प्रयासों को बेहतर बनाया। हमने पहले मौजूदा input-fuzzer हार्नेस के लाइन कवरेज का मूल्यांकन करके एक बेसलाइन स्थापित की, उसके प्रदान किए गए सीड कॉर्पस के साथ और बिना, तुलनीय प्रारंभिक कवरेज को नोट करते हुए। इसके बाद, हमने tmux में दो महत्वपूर्ण कोड क्षेत्रों की पहचान की जो बेसलाइन फ़ज़र द्वारा कम उपयोग किए गए थे। इन कवरेज अंतरालों को संबोधित करने के लिए, हमने दो नए लक्षित फ़ज़िंग हार्नेस, cmd-fuzzer और argument-fuzzer विकसित और मूल्यांकन किए, जो इन पहले से कम-परीक्षित क्षेत्रों में कवरेज सुधारने की उनकी क्षमता प्रदर्शित करते हैं। चूंकि इन फ़ज़िंग सुधारों ने परियोजना की समयावधि के भीतर नई गंभीर कमजोरियों का पता नहीं लगाया, हमारा क्रैश विश्लेषण एक ज्ञात ऐतिहासिक कमजोरी पर केंद्रित था। हमने CVE-2020-27347 (एक स्टैक-आधारित बफर ओवरफ्लो) के लिए एक प्रूफ-ऑफ-कॉन्सेप्ट (PoC) विकसित किया, इसके मूल कारण का विश्लेषण किया, लागू किए गए फिक्स पर चर्चा की, और इसके सुरक्षा निहितार्थों का आकलन किया।

परियोजना अवलोकन और लक्ष्य

इस परियोजना का उद्देश्य OSS-Fuzz फ्रेमवर्क का उपयोग करके tmux ओपन-सोर्स टर्मिनल मल्टीप्लेक्सर पर फ़ज़िंग तकनीकों को लागू और बेहतर बनाना था। परियोजना में कई प्रमुख चरण शामिल थे:

1. बेसलाइन मूल्यांकन (भाग 1):

   • tmux के लिए मौजूदा input-fuzzer हार्नेस को समझना और मूल्यांकन करना।
   • इसके डिफ़ॉल्ट सीड कॉर्पस के साथ चलाने पर बनाम एक खाली सीड कॉर्पस के साथ इसके कोड कवरेज प्रदर्शन की तुलना करना।

2. कवरेज अंतराल विश्लेषण (भाग 2):

   • भाग 1 से कवरेज रिपोर्टों का विश्लेषण करके tmux में महत्वपूर्ण कोड क्षेत्रों की पहचान करना जो input-fuzzer द्वारा पर्याप्त रूप से उपयोग नहीं किए गए थे।
   • सुधार के प्रमुख क्षेत्रों के रूप में आर्गुमेंट पार्सिंग (arguments.c) और कमांड पार्सिंग/निष्पादन लॉजिक (cmd-parse.c, cmd-*.c मॉड्यूल) पर ध्यान केंद्रित करना।

3. फ़ज़र सुधार (भाग 3):

   • दो नए, लक्षित फ़ज़िंग हार्नेस विकसित करना:
     • argument-fuzzer: विशेष रूप से arguments.c में कमांड-लाइन आर्गुमेंट पार्सिंग लॉजिक का परीक्षण करने के लिए डिज़ाइन किया गया।
     • cmd-fuzzer: cmd-parse.c और विभिन्न cmd-*.c मॉड्यूल को लक्षित करते हुए कमांड पार्सिंग और निष्पादन पथों का परीक्षण करने के लिए डिज़ाइन किया गया।
   • इन नए हार्नेस की प्रभावशीलता का मूल्यांकन उनके प्राप्त कोड कवरेज को मापकर और बेसलाइन के विरुद्ध तुलना करके करना।

4. क्रैश विश्लेषण (भाग 4):

   • चूंकि परियोजना की समयावधि के भीतर बेहतर फ़ज़र्स द्वारा कोई नई गंभीर कमजोरी नहीं खोजी गई, tmux में एक ज्ञात, पहले से मौजूद कमजोरी (CVE-2020-27347) को गहन विश्लेषण के लिए चुना गया।
   • इसमें क्रैश को पुन: उत्पन्न करने के लिए एक प्रूफ ऑफ कॉन्सेप्ट (PoC) विकसित करना, इसके मूल कारण का विश्लेषण करना, लागू किए गए फिक्स को समझना, और इसके सुरक्षा निहितार्थों का आकलन करना शामिल था।

रिपॉजिटरी संरचना

अंतिम सबमिशन निम्नानुसार व्यवस्थित है (submission/ निर्देशिका के भीतर):

submission/
├── README.md                   # This file
├── part_1/                     # Files for Part 1: Baseline Evaluation
│   ├── oss-fuzz.diff           # Diff for removing seed corpus for input-fuzzer
│   ├── project.diff            # (Likely empty or minor for Part 1)
│   ├── remove_seed_corpus.patch # The actual patch file used
│   ├── report/                 # HTML Coverage reports for input-fuzzer
│   │   ├── w_corpus/
│   │   └── wo_corpus/
│   ├── run.w_corpus.sh         # Script to run input-fuzzer with corpus
│   └── run.wo_corpus.sh        # Script to run input-fuzzer without corpus
├── part_3/                     # Files for Part 3: Fuzzer Improvements
│   ├── coverage_noimprove/     # Baseline coverage (e.g., from input-fuzzer without corpus)
│   │   └── ...
│   ├── improve1/               # Improvement 1: argument-fuzzer
│   │   ├── coverage_improve1/  # Coverage report for argument-fuzzer
│   │   ├── oss-fuzz.diff       # OSS-Fuzz config changes for argument-fuzzer
│   │   ├── project.diff        # Tmux changes for argument-fuzzer (e.g., new .cc, Makefile.am)
│   │   └── run.improve1.sh     # Script to run argument-fuzzer
│   └── improve2/               # Improvement 2: cmd-fuzzer
│       ├── coverage_improve2/  # Coverage report for cmd-fuzzer
│       ├── oss-fuzz.diff       # OSS-Fuzz config changes for cmd-fuzzer
│       ├── project.diff        # Tmux changes for cmd-fuzzer
│       └── run.improve2.sh     # Script to run cmd-fuzzer
├── part_4/                     # Files for Part 4: Crash Analysis (CVE-2020-27347)
│   ├── environment/            # Docker environment for PoC
│   │   ├── Dockerfile
│   │   ├── run_tmux_cve_test.sh # Core PoC test logic
│   │   ├── test_fixed.sh
│   │   └── test_vulnerable.sh
│   └── run.poc.sh              # Script to build Docker image and run PoC tests
└── report.pdf                  # The comprehensive project report

(नोट: scripts/ निर्देशिका जिसमें _run_fuzz_core.sh है, एक सहायक है और यदि यह README submission/ के साथ वास्तविक परियोजना रूट पर स्थित है तो यह रूट का हिस्सा होगा)

सेटअप और उपयोग

सभी फ़ज़िंग अभियान और CVE PoC पुनरुत्पादन शेल स्क्रिप्ट द्वारा व्यवस्थित Docker वातावरण के भीतर चलाने के लिए डिज़ाइन किए गए हैं।

सेटअप और उपयोग

सभी फ़ज़िंग अभियान और CVE PoC पुनरुत्पादन शेल स्क्रिप्ट द्वारा व्यवस्थित Docker वातावरण के भीतर चलाने के लिए डिज़ाइन किए गए हैं।

पूर्वापेक्षाएँ:

• एक यूनिक्स-जैसी प्रणाली पर Docker स्थापित और चालू।
• bash शेल और git क्लाइंट।
• यदि स्क्रिप्ट को oss-fuzz क्लोन करने की आवश्यकता हो तो [email protected] के लिए SSH कुंजियाँ कॉन्फ़िगर की गई हों (यदि oss-fuzz/ परियोजना रूट में नहीं मिलता है तो वे क्लोन करने का प्रयास करती हैं)। वैकल्पिक रूप से, आप https://github.com/google/oss-fuzz.git को परियोजना रूट में पहले से क्लोन कर सकते हैं।

सामान्य स्क्रिप्टिंग आर्किटेक्चर: परियोजना एक केंद्रीकृत कोर स्क्रिप्ट, scripts/_run_fuzz_core.sh का उपयोग करती है (जो submission/ निर्देशिका में शामिल नहीं है लेकिन समग्र परियोजना संरचना का हिस्सा है जिसे यह README मानता है)। submission/part_1/, submission/part_3/improve1/, submission/part_3/improve2/, और submission/part_4/ में स्थित व्यक्तिगत रनर स्क्रिप्ट इसके लिए जिम्मेदार हैं:

1. oss-fuzz रिपॉजिटरी की एक स्वच्छ चेकआउट पर रन-विशिष्ट oss-fuzz.diff पैच लागू करके विशिष्ट परीक्षण वातावरण स्थापित करना (अधिकांश रनर स्क्रिप्ट के सापेक्ष ../../oss-fuzz पर होने की उम्मीद है)।
2. कॉन्फ़िगरेशन चर निर्यात करना (जैसे PROJECT, HARNESS, LABEL, परियोजना-विशिष्ट पैच के पथ, और आउटपुट निर्देशिकाएँ)।
3. _run_fuzz_core.sh स्क्रिप्ट को लागू करना, जो फिर निम्न को संभालती है:
   • एक वैकल्पिक परियोजना-स्तरीय पैच लागू करना (उदाहरण के लिए, tmux में नए फ़ज़र स्रोत जोड़ने के लिए)।
   • OSS-Fuzz Docker इमेज बनाना (यदि फ़्लैग किया गया हो)।
   • चुने गए सैनिटाइज़र के साथ निर्दिष्ट फ़ज़र(s) बनाना।
   • कॉन्फ़िगर की गई अवधि के लिए फ़ज़र निष्पादित करना (आमतौर पर 4 घंटे)।
   • submission/ निर्देशिका संरचना के भीतर निर्दिष्ट स्थानों पर कॉर्पस और HTML कवरेज रिपोर्ट उत्पन्न और निर्यात करना।

स्क्रिप्ट चलाना: आम तौर पर oss-fuzz/ और आउटपुट निर्देशिकाओं के लिए सही सापेक्ष पथ समाधान सुनिश्चित करने के लिए रनर स्क्रिप्ट को परियोजना की रूट निर्देशिका से चलाने की अनुशंसा की जाती है।

1. भाग 1: बेसलाइन मूल्यांकन (input-fuzzer) ये स्क्रिप्ट tmux के लिए मौजूदा input-fuzzer का मूल्यांकन करती हैं।

# From the project root directory:
./submission/part_1/run.w_corpus.sh  # Run input-fuzzer with default seed corpus
./submission/part_1/run.wo_corpus.sh # Run input-fuzzer without seed corpus

run.w_corpus.sh सीड के संबंध में डिफ़ॉल्ट tmux बिल्ड व्यवहार का उपयोग करता है। run.wo_corpus.sh यह सुनिश्चित करने के लिए oss-fuzz/projects/tmux/build.sh पर submission/part_1/remove_seed_corpus.patch (अपने स्थानीय oss-fuzz.diff के माध्यम से जो इस पैच को इंगित करेगा या इसके परिवर्तनों को एकीकृत करेगा) लागू करता है कि कोई प्रारंभिक सीड कॉर्पस उपयोग न हो। कवरेज रिपोर्ट क्रमशः submission/part_1/report/w_corpus/ और submission/part_1/report/wo_corpus/ में निर्यात की जाती हैं।

2. भाग 3: फ़ज़र सुधार (input-fuzzer)