abhinavagarwal07/gdcm-security-pocछह GDCM निष्कर्षों के लिए निजी एंड-टू-एंड सैनिटाइज़र प्रतिकृति पैकेज
GDCM में छह पार्सर/कोडेक दोष, v3.2.6 पर सैनिटाइज़र विफलताओं या सीमित प्रसार जाँचों के रूप में पुनरुत्पादित। प्रत्येक स्वचालित ट्रिगर का एक निकट-वैध नियंत्रण है जो संवेदनशील सिग्नल उत्पन्न नहीं करता। निष्कर्ष 1 में एक इंस्ट्रुमेंटेड कंट्रोल-फ़्लो प्रिमिटिव भी शामिल है।
रखरखावकर्ता और भेद्यता-समन्वयक समीक्षा के लिए अभिप्रेत। कुछ भी चलाने से पहले SAFETY.md पढ़ें।
manifest/targets.env:
| नाम | रिवीज़न | यह क्या है |
|---|
vulnerable | 9c71b163 | टैग v3.2.6 |
master | 2cd05d13 | अपस्ट्रीम master स्नैपशॉट स्थिर रूप से समीक्षित; रनटाइम मैट्रिक्स लंबित |
fixed | unset | केवल तब भरें जब कोई समीक्षित उपचार कमिट मौजूद हो |
master एक दिनांकित स्नैपशॉट है, चलती शाखा नहीं। दोनों रिवीज़न सार्वजनिक रिपॉज़िटरी से पहुँच योग्य हैं, इसलिए bootstrap.sh किसी भी निजी स्रोत के बिना किसी को भी तैयार कर सकता है।
इस रिपॉज़िटरी में रनटाइम साक्ष्य v3.2.6 के लिए है। नीचे दी गई व्यापक श्रेणियाँ स्रोत-इतिहास निरीक्षण से आती हैं; संबंधित पैटर्न पिन किए गए master स्नैपशॉट में भी बने हुए हैं।
| # | CWE | स्रोत-निरीक्षित श्रेणी | आवश्यक पथ |
|---|---|---|---|
| 1 | CWE-787 | v3.0.4 से v3.2.7 तक | मल्टी-फ़्रेम RLE YBR_FULL_422 रीड |
| 2 | CWE-787 | v2.0.16 से v3.2.7 तक | JPEG2000 एन्कोडिंग/ट्रांसकोडिंग |
| 3 | CWE-125 | v2.0.5 से v3.2.7 तक | सेगमेंटेड पैलेट पार्सिंग; LUT अनुप्रयोग प्रसारित मानों को उजागर करता है |
| 4 | CWE-787 | v2.0.8 से v3.2.7 तक | ImageRegionReader::ReadIntoBuffer; CVE-2024-22373 के बाद अपूर्ण परिशुद्धता सत्यापन से संबंधित |
| 5 | CWE-674 | v2.0.4 या पहले से v3.2.7 तक | सामान्य नेस्टेड-सीक्वेंस पार्सिंग |
| 6 | CWE-369 | v2.0.4 या पहले से v3.2.7 तक | NumSegments=0 के साथ सामान्य RLE पार्सिंग |
fixtures/ - निष्क्रिय DICOM इनपुट, manifest/expectations.json में SHA-256-पिन किए गए और प्रत्येक ट्रिगर रन से पहले सत्यापितgenerators/ - प्रत्येक फ़िक्स्चर के लिए नियतात्मक, निर्भरता-मुक्त स्रोत जनरेटरharnesses/ - न्यूनतम रीड/एन्कोड/डिकोड हार्नेस; निष्कर्ष 2 को gdcmconv CLI और लाइब्रेरी ट्रांसकोड API दोनों के माध्यम से दिखाया गया है जिसे कोई सर्वर कॉल करेगाmanifest/expectations.json - fixed लक्ष्य के लिए मशीन-पठनीय कमांड, निर्णायक सिग्नल, और स्वीकृति मानदंडscripts/ - पिन किए गए स्रोत की तैयारी, सैनिटाइज़र बिल्ड, सीमित निष्पादन, सफ़ाईevidence/ - पहले से देखे गए संक्षिप्त परिणाम, अपरीक्षित लक्ष्यों को स्पष्ट रूप से बताया गयाLICENSE - MIT लाइसेंसGit, Python 3, CMake 3.20+, Ninja, और C++11 टूलचेन (Clang या GCC) के साथ एक डिस्पोज़ेबल Linux या macOS बिल्ड वातावरण। Ubuntu पर: git python3 cmake ninja-build clang zlib1g-dev। GCC का उपयोग करने के लिए CC/CXX सेट करें।
स्रोत तैयारी HTTPS के माध्यम से क्लोन करती है जब तक कि GDCM_SOURCE_REPO किसी मौजूदा स्थानीय क्लोन की ओर इंगित न करे। कोई SSH होस्ट उपयोग नहीं किया जाता।
ये कमांड केवल स्रोत और बिल्ड आर्टिफ़ैक्ट तैयार करते हैं; वे कोई फ़िक्स्चर नहीं खोलते।
./scripts/build-target.sh vulnerable asan debug
./scripts/build-target.sh vulnerable ubsan debug
./scripts/build-target.sh master asan debug
./scripts/build-target.sh master ubsan debug
तीसरा तर्क प्रोफ़ाइल है। debug -O0 -g है; release -O2 -g -DNDEBUG है, जो GDCM के gdcm_debug_assert()s को हटा देता है और यह दर्शाता है कि वितरण लाइब्रेरी को कैसे बनाते हैं। दोनों के अंतर्गत मैट्रिक्स चलाना उस पहले प्रश्न का उत्तर देता है जो एक रखरखावकर्ता पूछता है, कि क्या रिपोर्टें assertion-सक्षम बिल्ड का एक आर्टिफ़ैक्ट हैं।
GDCM_SUPPORT_BROKEN_IMPLEMENTATION=ON GDCM का अपना डिफ़ॉल्ट है और इसे वैसे ही छोड़ दिया गया है। रूढ़िवादी समानांतरता को JOBS=8 से ओवरराइड करें।
प्रत्येक बिल्ड अपने GDCM बिल्ड ट्री में build-info.json (रिवीज़न, कंपाइलर, फ़्लैग, प्लेटफ़ॉर्म) लिखता है, और प्रत्येक रन सारांश इसे एम्बेड करता है, इसलिए संग्रहीत साक्ष्य स्व-वर्णनात्मक है।
export GDCM_REPRO_ACK=I_UNDERSTAND_THIS_CRASHES_A_LOCAL_PROCESS
./scripts/run-matrix.sh vulnerable master --profile debug # all automated cases
./scripts/run-one.sh vulnerable f1 # one trigger
./scripts/run-one.sh vulnerable f1 --control # its control
run-matrix.sh प्रत्येक लक्ष्य के लिए प्रत्येक स्वचालित केस चलाता है, पहली विफलता पर नहीं रुकता, और _runs/matrix-<stamp>.json के साथ-साथ एक रेंडर किया गया _runs/matrix-<stamp>.md लिखता है। दो-चरणीय f1-exploit केस मैनुअल रहता है और इसे विफल स्वचालित केस के रूप में गलत वर्गीकृत करने के बजाय वैसा ही रिपोर्ट किया जाता है।
प्रत्येक चाइल्ड में कोर डंप अक्षम और 15-सेकंड का टाइमआउट होता है; निष्कर्ष 5 को अतिरिक्त रूप से एक सीमित स्टैक सीमा मिलती है। आउटपुट _runs/ के अंतर्गत रहते हैं। क्लासिफायर सैनिटाइज़र क्लास और संबंधित फ़ंक्शन से मेल खाता है, कभी भी एड्रेस, PID, या स्रोत पंक्ति संख्याओं से नहीं।
vulnerable के लिए, एक केस तब पास होता है जब निर्णायक सिग्नल प्रकट होता है और उसका नियंत्रण साफ़ रहता है। master के लिए, रनर पूर्व-घोषित निर्णय के बजाय अवलोकन रिकॉर्ड करता है। fixed के लिए, एक केस तभी पास होता है जब सिग्नल अनुपस्थित हो, कोई अन्य सैनिटाइज़र या घातक सिग्नल प्रकट न हो, और हार्नेस एक अनुमत स्वच्छ परिणाम लौटाए। ये नियम तब तक अनंतिम हैं जब तक FIXED_REV किसी वास्तविक पैच का नाम न दे; उन्हें उस पैच के इच्छित reject-or-process व्यवहार के विरुद्ध समीक्षित किया जाना चाहिए।
| केस | निष्कर्ष | यह क्या दिखाता है |
|---|---|---|
f1 | 1 | RLECodec::DecodeFragment में ASan हीप राइट |
f1-exploit | 1 | इंस्ट्रुमेंटेड आसन्न-ऑब्जेक्ट ओवरराइट और इनडायरेक्ट-ब्रांच कंट्रोल (Linux x86-64) |
f2 | 2 | gdcmconv --j2k के माध्यम से opj_write_from_memory में ASan हीप राइट |
f2-lib | 2 | ImageChangeTransferSyntax::Change के माध्यम से वही राइट |
f3 | 3 | सेगमेंटेड पैलेट विस्तार में ASan हीप रीड |
f3-propagation | 3 | आउट-ऑफ़-बाउंड बाइट्स डिकोड किए गए पिक्सल तक पहुँचते हैं, एक गणना के रूप में रिपोर्ट किए गए |
f3-sentinel | 3 | एक सीमित ज्ञात गार्ड वर्ड तार्किक LUT सीमा को पार करता है |
f4 | 4 | JPEG2000 रीजन डिकोड में ASan हीप राइट |
f5 | 5 | नेस्टेड सीक्वेंस आइटम पर ASan स्टैक एक्सहॉशन |
f6 | 6 | RLE डिकोड में UBSan डिवीज़न बाय ज़ीरो; x86 पर SIGFPE |
दो और हार्नेस पुनरुत्पादन केस के बजाय शोषणीयता अनुसंधान हैं, और केवल Linux x86-64 पर अनसैनिटाइज़्ड प्रोफ़ाइल में बनते हैं:
| हार्नेस | निष्कर्ष | यह क्या स्थापित करता है |
|---|---|---|
finding01_groom | 1 | परीक्षित glibc आसन्नता, एलोकेशन-रिकॉर्डिंग हुक के माध्यम से देखी गई |
finding03_leak | 3 | एक 131070-बाइट ओवररीड एक बिल्ड-विशिष्ट लाइब्रेरी पॉइंटर को उजागर कर सकता है |
evidence/v3.2.6-macos-arm64-debug.md पूर्ण v3.2.6 डिबग मैट्रिक्स रिकॉर्ड करता है, जिसमें प्रत्येक नियंत्रण और दोनों सीमित निष्कर्ष 3 प्रसार जाँचें शामिल हैं।
evidence/v3.2.6-linux-x86_64-finding01-groom.md और evidence/v3.2.6-linux-x86_64-finding03-leak.md नीचे दिए गए दो शोषणीयता परिणामों को रिकॉर्ड करते हैं। वर्तमान-master, पूर्ण रिलीज़-प्रोफ़ाइल मैट्रिक्स, और f1-exploit परिणामों का दावा तब तक नहीं किया जाता जब तक उनके ट्रांसक्रिप्ट संग्रहीत न हों।
./scripts/clean.sh
सफ़ाई पैकेज मार्कर के बिना चलने से इनकार करती है और इस रिपॉज़िटरी के अंतर्गत केवल _work, _build, _generated, _runs, और Python बाइटकोड कैश को हटाती है। evidence/ के अंतर्गत संग्रहीत साक्ष्य नहीं हटाया जाता।
f1-exploit केवल Linux-x86_64 है और इसे हाथ से चलाया जाता है; manifest/expectations.json में सटीक कमांड अनुक्रम है। हार्नेस के नियतात्मक एलोकेशन लेआउट के अंतर्गत यह तीन अलग तथ्यों का परीक्षण करता है, प्रत्येक में एक मिलान किया गया नकारात्मक केस है:
f1 फ़िक्स्चर का उपयोग करना, भ्रष्टाचार की रिपोर्ट करता है लेकिन स्पष्ट रूप से नहीं सामग्री नियंत्रण, इसलिए जाँच मिथ्यापनीय है;12288-बाइट ओवरफ़्लो के भीतर 8-बाइट विंडो में से लगभग आधे एक मनमाना मान स्वीकार करते हैं। बाकी युग्मित हैं, क्योंकि DoYBRFull422 एक स्रोत बाइट को दो आउटपुट स्थितियों में डुप्लिकेट करता है; ऑफ़सेट 6144 मुक्त विंडो में से एक है। फ़्रेम 1 का डिकोड अंत में चलता है, इसलिए यह फ़्रेम 1 की सामग्री है जो एलोकेशन के बाद बनी रहती है।
हार्नेस रिकॉर्ड करता है कि क्या ImageReader::Read() true लौटाता है जबकि आसन्न ऑब्जेक्ट संशोधित होता है। उस परिणाम को देखे गए साक्ष्य के रूप में वर्णित करने से पहले एक सफल Linux x86-64 ट्रांसक्रिप्ट संग्रहीत किया जाना चाहिए।
f1-exploit अपना स्वयं का विक्टिम लेआउट आपूर्ति करता है, इसलिए यह उत्तर नहीं दे सकता कि क्या एक असंशोधित प्रक्रिया में वह लेआउट है। finding01_groom स्टॉक glibc, डिफ़ॉल्ट PIE, और ASLR का उपयोग करता है, वैश्विक एलोकेशन हुक के साथ जो एलोकेशन रिकॉर्ड करते हैं लेकिन स्थानांतरित नहीं करते। संग्रहीत परीक्षणों में:
finding01 हार्नेस बिना किसी इंस्ट्रुमेंटेशन के उसी तरह मर जाता है।परीक्षित glibc बिल्ड पर, निष्कर्ष 1 ने विश्वसनीय रूप से सेवा-अस्वीकृति का कारण बना; कोई कोड-निष्पादन पथ नहीं पाया गया। परीक्षित ज्यामिति निश्चित थी, और अन्य एलोकेटर या प्लेटफ़ॉर्म हीप को अलग तरह से बिछा सकते हैं।
finding03_leak अधिक मजबूत परिणाम है। परीक्षित बिल्ड में, आउट-ऑफ़-बाउंड रीड 131070 बाइट्स तक पहुँचता है, एक gdcm::ByteValue vtable पॉइंटर डिकोड किए गए पिक्सल में प्रवेश करता है, और हार्नेस उस बिल्ड के ज्ञात vtable ऑफ़सेट का उपयोग करके लाइब्रेरी लोड बेस प्राप्त करता है। यह एक स्थानीय API-स्तरीय प्रकटीकरण परिणाम है: इसके लिए LUT अनुप्रयोग और डिकोड किए गए पिक्सल बफ़र तक पहुँच की आवश्यकता होती है। यह नहीं दिखाता कि कोई नेटवर्क सेवा उन पिक्सल को लौटाती है।
यहाँ दोनों को कोड निष्पादन में श्रृंखलाबद्ध नहीं किया जा सकता, और केवल इसलिए नहीं कि कोई विक्टिम नहीं मिला: उन्हें अलग PhotometricInterpretation मानों की आवश्यकता होती है, इसलिए उन्हें दो फ़ाइलों की आवश्यकता होती है, और एक लीक किया गया बेस तभी उपयोगी होता है जब तक लीक करने वाली प्रक्रिया जीवित है।
एक सैनिटाइज़र रिपोर्ट परीक्षित प्रक्रिया और रिवीज़न में बताई गई मेमोरी-सुरक्षा या अपरिभाषित-व्यवहार घटना को सिद्ध करती है। f1-exploit एक इंस्ट्रुमेंटेड एलोकेटर के अंतर्गत बाइट नियंत्रण और एक आसन्न फ़ंक्शन-पॉइंटर ओवरराइट का परीक्षण करता है जो जानबूझकर लक्ष्य लेआउट आपूर्ति करता है। यह एक असंशोधित उपभोक्ता में उस लेआउट को स्थापित नहीं करता। संग्रहीत finding01_groom परीक्षणों ने परीक्षित ज्यामिति और glibc बिल्ड के लिए वह लेआउट नहीं देखा।
इनमें से कोई भी किसी विशेष उत्पाद में दूरस्थ पहुँच, दृढ़ता, या डाउनस्ट्रीम प्रयोज्यता सिद्ध नहीं करता। किसी दिए गए परिनियोजन के लिए पहुँच-योग्यता तर्क एक अलग दावा है, जो प्रकटीकरण पाठ में किया गया है और इस पैकेज द्वारा नहीं।