फ़ज़िंग लैब: 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 और विभिन्न मॉड्यूल को लक्षित करते हुए कमांड पार्सिंग और निष्पादन पथों का परीक्षण करने के लिए डिज़ाइन किया गया।

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

अंतिम सबमिशन निम्नानुसार व्यवस्थित है (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)

• सुधार 1 (argument-fuzzer): arguments.c को लक्षित करता है।

  root@kitploit:~

  # From the project root directory:
  ./submission/part_3/improve1/run.improve1.sh
  

• सुधार 2 (cmd-fuzzer): cmd-parse.c और कमांड निष्पादन को लक्षित करता है।

  root@kitploit:~

  # From the project root directory:
  ./submission/part_3/improve2/run.improve2.sh
  

प्रत्येक run.improveX.sh स्क्रिप्ट अपने स्थानीय oss-fuzz.diff को लागू करती है और PROJECT_PATCH_FILE को अपने स्थानीय project.diff पर सेट करती है (जो tmux में नया फ़ज़र कोड जोड़ता है और Makefile.am को अपडेट करता है)। कवरेज रिपोर्ट क्रमशः submission/part_3/improveX/coverage_improveX/ निर्देशिकाओं में निर्यात की जाती हैं। submission/part_3/coverage_noimprove/ निर्देशिका में तुलना के लिए भाग 1 से बेसलाइन कवरेज होती है।

3. भाग 4: CVE-2020-27347 PoC पुनरुत्पादन

# From the project root directory:
./submission/part_4/run.poc.sh

यह स्क्रिप्ट एक समर्पित Docker इमेज बनाती है (submission/part_4/environment/Dockerfile से) और पैच किए गए कमिट a868bac के विरुद्ध tmux 3.1b (असुरक्षित) का परीक्षण करती है।

प्रमुख निष्कर्ष और परिणाम

(विस्तृत स्पष्टीकरण, आंकड़े और तालिकाएँ पूर्ण report.pdf में पाई जा सकती हैं)

भाग 1 (बेसलाइन - input-fuzzer)

• डिफ़ॉल्ट सीड कॉर्पस के साथ: 14.00% लाइन कवरेज (7281/51997 लाइनें), 24.44% फ़ंक्शन कवरेज।
• सीड कॉर्पस के बिना: 13.94% लाइन कवरेज (7248/51997 लाइनें), 24.31% फ़ंक्शन कवरेज।
• मौजूदा input-fuzzer के लिए प्रारंभिक सीड कॉर्पस का प्रभाव न्यूनतम था।
• tmux के महत्वपूर्ण हिस्से, विशेष रूप से आर्गुमेंट पार्सिंग (arguments.c), कमांड पार्सिंग/निष्पादन (cmd-parse.c, cmd-*.c), और क्लाइंट/सर्वर लॉजिक (client.c, server.c), बड़े पैमाने पर अप्रयुक्त थे (उदाहरण के लिए, arguments.c ~5.8% लाइन कवरेज पर)।

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

• argument-fuzzer (arguments.c को लक्षित करते हुए): arguments.c के लिए 66.62% लाइन कवरेज प्राप्त की, जो ~5.8% बेसलाइन से एक महत्वपूर्ण वृद्धि है।
• cmd-fuzzer (कमांड पार्सिंग और निष्पादन को लक्षित करते हुए): cmd-parse.c के लिए लाइन कवरेज बढ़ाकर 42.58% (~27% से) और फ़ंक्शन कवरेज 77.78% कर दी।
• इस फ़ज़र के माध्यम से arguments.c कवरेज भी बढ़कर 45.54% हो गई।
• cmd.c ने 39.14% लाइन कवरेज हासिल की।
• विभिन्न cmd-*.c मॉड्यूल (उदाहरण के लिए, cmd-bind-key.c, cmd-set-options.c 50% फ़ंक्शन कवरेज तक) और कुंजी-प्रबंधन रूटीन (key-string.c 30% लाइन कवरेज तक, key-bindings.c 6.05% लाइन कवरेज तक) में नई या काफी बेहतर कवरेज प्राप्त की।

भाग 4 (CVE-2020-27347 विश्लेषण)

• पेलोड \033[::::::7::1:2:3::5:6:7:m का उपयोग करके tmux 3.1b (कमिट 6a33a12) पर CVE-2020-27347 (SGR एस्केप अनुक्रम पार्सिंग में स्टैक बफर ओवरफ्लो) को सफलतापूर्वक पुन: उत्पन्न किया।
• पुष्टि की कि tmux कमिट a868bac (जिसमें फिक्स शामिल है और संस्करण 3.1c की ओर ले जाता है) क्रैश के लिए संवेदनशील नहीं था।
• यह कमजोरी, एक पेन TTY पर एक क्राफ्टेड अनुक्रम लिखकर शोषणीय, सेवा से वंचित (Denial of Service) की ओर ले जाती है और इसमें मनमाना कोड निष्पादन (Arbitrary Code Execution) की संभावना है। इसे उच्च गंभीरता (CVSS 7.8) रेट किया गया है।

सामना की गई चुनौतियाँ

• एक स्क्रिप्टेड Docker वातावरण में सही tmux स्टार्टअप सुनिश्चित करना, विशेष रूप से "not a terminal" त्रुटियों से बचना, के लिए CVE PoC हेतु डिटैच्ड सत्रों का उपयोग करना आवश्यक था।
• विभिन्न परीक्षण परिदृश्यों में git स्थिति का प्रबंधन (पैच लगाने से पहले पूर्ण क्लोन, साफ रीसेट सुनिश्चित करना) विशिष्ट tmux संस्करणों के प्रतिलिपि-योग्य बिल्ड के लिए महत्वपूर्ण था।
• प्रभावी नए फ़ज़िंग हार्नेस (argument-fuzzer, cmd-fuzzer) विकसित करने के लिए विशिष्ट अप्रयुक्त कोड पथों को लक्षित करने हेतु tmux की आंतरिक आर्गुमेंट और कमांड प्रोसेसिंग लॉजिक की अच्छी समझ आवश्यक थी।

भविष्य के कार्य

• विंडो, लेआउट, या पेन मैनिपुलेशन जैसे जटिल स्टेट इंटरैक्शन से निपटने वाले मॉड्यूल सहित, व्यापक cmd-*.c मॉड्यूल को कवर करने के लिए cmd-fuzzer को और बेहतर बनाना।
• tmux क्लाइंट-सर्वर संचार प्रोटोकॉल के लिए फ़ज़िंग रणनीतियों की जांच करना, संभावित रूप से अधिक जटिल पर्यावरण मॉकिंग शामिल करना।
• tmux कमांड भाषा के लिए संरचना-जागरूक फ़ज़िंग के उपयोग का पता लगाना, संभवतः अधिक वाक्य-विन्यास रूप से मान्य और जटिल कमांड अनुक्रम उत्पन्न करने के लिए cmd-parse.y से व्याकरण परिभाषाओं का लाभ उठाना।

उपयोगी लिंक

• tmux प्रोजेक्ट
• OSS-Fuzz
• CVE-2020-27347
• परियोजना रिपोर्ट PDF (परियोजना रूट के सापेक्ष पथ)