CVE-2024-5452

01. RCE और pytorch-lightning अवलोकन

• 1) RCE और pytorch-lightning अवलोकन

  RCE (Remote Code Execution, दूरस्थ कोड निष्पादन) एक भेद्यता है जो हमलावर को दूरस्थ रूप से सिस्टम या एप्लिकेशन के भीतर मनमाना कोड निष्पादित करने की अनुमति देती है, और यह CWE-94: Improper Control of Generation of Code ('Code Injection') है।

  PyTorch Lightning एक लाइब्रेरी है जो PyTorch-आधारित डीप लर्निंग मॉडल प्रशिक्षण को आसानी से प्रबंधित करने में मदद करती है, और DeepDiff एक लाइब्रेरी है जो दो Python ऑब्जेक्ट्स की तुलना करके अंतर का विश्लेषण करती है।

  CVE-2024-5452 एक भेद्यता है जो Lightning के AI मॉडल वज़न संबंधी वेब एप्लिकेशन फीचर में DeepDiff और Lightning का उपयोग करने की प्रक्रिया के दौरान DeepDiff के कमजोर हेडर सत्यापन और डेल्टा विशेषता प्रदूषण के माध्यम से डिसीरियलाइज़ेशन (deserialization) के समय RCE उत्पन्न करती है।

  इसके माध्यम से हम उस कोड प्रवाह को देखेंगे जिसमें हमलावर मनमाना ऑब्जेक्ट इंजेक्ट कर सकता है या रिमोट कोड एक्ज़ीक्यूशन (RCE) कर सकता है, और इसके समाधान के उपायों पर विचार करेंगे।

02. pytorch-lightning वातावरण में डिसीरियलाइज़ेशन भेद्यता का विश्लेषण

• 2.1 DeepDiff में Delta प्रदूषण का उपयोग करके हमले का विश्लेषण

  pytorch-lightning में वेब एप्लिकेशन स्रोत के DeepDiff एंडपॉइंट्स में से /api/v1/delta पर delta की विशेषताओं को प्रदूषित करके भेजकर हमला किया जा सकता है।
  उदाहरण देखकर हम जानेंगे कि delta के dunder गुणों को प्रदूषित करके ऑब्जेक्ट डिसीरियलाइज़ेशन भेद्यता कैसे उत्पन्न होती है।

  1) DeepDiff में Delta प्रदूषण का उपयोग करके हमले का प्रवाह

  पहला अनुरोध क्लाइंट हमला उदाहरण, प्रदूषण सेटिंग -> Deepdiff के /api/v1/delta में कमजोर हेडर सत्यापन -> प्रदूषण सेटिंग के माध्यम से स्थिति सहेजना है।

  

  [चित्र 1] POC - Endpoint हमला

  

  [चित्र 2] POC - Vuln Injection / संपूर्ण प्रदूषण सेटिंग सामग्री

  

  [चित्र 3] lightning/api/core/api.py / कमजोर हेडर जांच लॉजिक भाग

  

  [चित्र 4] lightning/api/core/app.py / सेटिंग अनुभाग

  

  [चित्र 5] lightning/api/core/app.py / सेटिंग सहेजने का अनुभाग

  पहला अनुरोध [चित्र 3] के /api/v1/delta के हेडर सत्यापन को [चित्र 1] के माध्यम से बायपास करके छेड़छाड़ की गई प्रदूषण सेटिंग (delta) [चित्र 2] इंजेक्ट करता है, और [चित्र 4], [चित्र 5] के माध्यम से सेटिंग सहेजता है। अब दूसरे अनुरोध में देखेंगे कि ये छेड़छाड़ किए गए डेल्टा की सेटिंग्स कैसे काम करती हैं।

  

  [चित्र 6] lightning/api/core/app.py / प्रारंभिक पथ प्रवाह

  [चित्र 6] डेल्टा सेट होने के बाद दूसरे अनुरोध का प्रवाह है: run_once() -> maybe_apply_change() -> _collect_deltas_from_ui_and_work_queues()
  

  

  [चित्र 7] isinstance प्रदूषण मामला

  [चित्र 7] _collect_deltas_from_ui_and_work_queues() में isinstance जांच को प्रदूषित सेटिंग के माध्यम से पास (isinstance(delta, _DeltaRequest) == False) कराके else में भेज दिया जाता है।

  

  [चित्र 8] isinstance प्रदूषण मामला 1

  [चित्र 8] समझने के लिए isinstance(delta, _DeltaRequest), delta, _DeltaRequest(टाइप) के परिणाम आउटपुट किए गए हैं; पहला अनुरोध सेटिंग के लिए है जिसमें परिवर्तन सेट किया जा रहा है, इसलिए यह सामान्य है, और अगले अनुरोध में _DeltaRequest टाइप को str से प्रदूषित करके शर्त को बायपास किया जा रहा है। प्रवाह के अनुसार अगला लक्ष्य _process_requests का उदाहरण देखते हैं।

  

  [चित्र 9] isinstance प्रदूषण मामला 2

  [चित्र 9] में देखा जा सकता है कि ऊपर जैसी ही स्थिति में _process_requests, दाईं ओर क्लाइंट POC कोड की सेटिंग द्वारा isinstance(request, _APIRequest) की जांच को प्रदूषित सेटिंग से पास कर लेता है; यह प्रदूषण ऐसा मामला है जिसमें str के लिए OrderSet इंस्टेंस पर isinstance कॉल सही (True) लौटाता है। अब तक हमने दो प्रकार के isinstance प्रदूषण देखे हैं, आगे की स्थिति में प्रदूषण के माध्यम से विशेषताओं को कॉल करने योग्य बनाने के लिए सेटिंग तैयार की जाती है।

  

  

  

  [चित्र 10] isinstance प्रदूषण मामला 3

  [चित्र 10] में isinstance बायपास और फ़ंक्शन सेटिंग समाप्त होने के बाद, [चित्र 10] की "आंतरिक स्थिति निर्धारण" (_INTERNAL_STATE_VARS: () को खाली छोड़ना) सेट करके [चित्र 11] में आंतरिक सेटिंग स्थिति की जांच को असंभव बना दिया जाता है।

  

  [चित्र 11_1] /lightning/app/core/flow.py का _INTERNAL_STATE_VARS जांच फ़ंक्शन

  

  [चित्र 11_2] /lightning/app/core/flow.py का __setattr__

  [चित्र 11] को अंतिम मानते हुए, समग्र प्रदूषण और सेटिंग समाप्त हो गई है।

  

  [चित्र 12] RCE Commnad

  

  

  [चित्र 13] RCE Response

  अंततः [चित्र 13] में root विशेषाधिकार के साथ exec को कॉल करके [चित्र 12] का कमांड निष्पादित करके प्रक्रिया समाप्त होती है।

2) DeepDiff में Delta प्रदूषण का उपयोग करके हमले का संक्षिप्त उदाहरण (बाएं: lightning App server, दाएं: Client)

03. समाधान के उपाय

अब तक हमने lightning वातावरण में ऑब्जेक्ट डिसीरियलाइज़ेशन (CVE-2024-5452) के माध्यम से RCE भेद्यता के निष्पादन का प्रवाह देखा है। चूंकि यह हमले की वह विधि है जिसमें सर्वर ही छीन लिया जाता है, इसलिए समाधान के उपाय महत्वपूर्ण हैं। इसके लिए हम नवीनतम संस्करण में अपडेट का सुझाव देना चाहते हैं।

• lightning अपडेट

  यदि lightning <= 2.2.1 है, तो कृपया lightning > 2.3.3 या उससे ऊपर के संस्करण में अपडेट करें।

• lightning लाइब्रेरी का संक्षिप्त संशोधन

  यह विधि केवल मजबूरी के मामले में अस्थायी रूप से रोकने का तरीका है, कृपया इसे केवल संदर्भ के लिए लें। /api/v1/delta एंडपॉइंट में एक सरल लॉजिक जोड़ें (पथ /lightning/app/core/api) या ऊपर सत्र जांच भाग को मजबूत करें।

• IPS के माध्यम से पहचान और अवरोधन

  हमले का परीक्षण post man के माध्यम से json में dunder गुण निर्दिष्ट करके किया जाता है।

04. निष्कर्ष

अब तक हमने Lightning और Deepdiff के माध्यम से Dunder गुणों को प्रदूषित करके RCE उत्पन्न करने वाली भेद्यता के बारे में जाना है। यह भेद्यता पहले कमजोर हेडर सत्यापन और फिर delta के कमजोर गुण जांच के माध्यम से ऑब्जेक्ट डिसीरियलाइज़ेशन में घटित होने वाली भेद्यता थी।

05. संदर्भ सामग्री

(poc) https://security.snyk.io/vuln/SNYK-PYTHON-PYTORCHLIGHTNING-7218866
(nist) https://nvd.nist.gov/vuln/detail/CVE-2024-5452