Skip to content
KitploitKITPLOIT
उपकरणएक्सप्लॉइटब्लॉग
Log in
जमा करें
उपकरणएक्सप्लॉइटब्लॉग
जमा करें

हैकिंग, पेनटेस्ट और साइबर सुरक्षा उपकरण आपके सुरक्षा शस्त्रागार के लिए!

Kitploit हैकिंग, साइबर सुरक्षा और पेंटेस्टिंग टूल्स की एक निर्देशिका है। कमजोरियों को खोजने, सिस्टम का विश्लेषण करने, परीक्षण को स्वचालित करने और अपनी सुरक्षा को मजबूत करने के लिए नवीनतम प्रोजेक्ट अपडेट खोजें।

फ़ीडसंपर्कगोपनीयता© 2026 Kitploit

टूल निर्देशिका

श्रेणियाँ

सभी श्रेणियाँ देखें
Loading categories
cve-2026-19445-sni-uaf — CVE-2026-19445 के लिए प्रूफ-ऑफ-कॉन्सेप्ट लैब, एक CPython ssl SNI SSLContext use-after-free जहाँ एक रिमोट TLS क्लाइंट हैंडशेक के दौरान सर्वर का dispatch context फ्री कर देता है। | Kitploit
उपकरण/GitHubGitHub/abraxas/cve-2026-19445-sni-uaf
गतिशील विश्लेषण (सैंडबॉक्सिंग)मेमोरी फोरेंसिकभेद्यता विश्लेषणशोषणक्रिप्टोग्राफीपेपर और शोधलैब और अभ्यास
GitHubabraxas/cve-2026-19445-sni-uaf

सबसे लोकप्रिय

सभी देखें →

हमारे समुदाय द्वारा सबसे अधिक उपयोग किए जाने वाले उपकरण खोजें।

सभी उपकरण खोजें

हमारे उपकरणों का संग्रह ब्राउज़ करें

सभी उपकरण देखें →

cve-2026-19445-sni-uaf

CVE-2026-19445 के लिए प्रूफ-ऑफ-कॉन्सेप्ट लैब, एक CPython ssl SNI SSLContext use-after-free जहाँ एक रिमोट TLS क्लाइंट हैंडशेक के दौरान सर्वर का dispatch context फ्री कर देता है।

रिपॉजिटरी देखें
1 दिन पहलेअभी तक समीक्षित नहीं
साझा करें

Abraxas Labs - cve-2026-19445-sni-uaf

abraxaslabs.tech  ·  github.com/abraxas  ·  @abraxas_null  ·  [email protected]  ·  cve-2026-19445-sni-uaf

cve-2026-19445-sni-uaf

CPython ssl - Python Software Foundation

एक TLS सर्वर जो प्रत्येक कनेक्शन के लिए एक SSLContext बनाता है, sni_callback सेट करता है, और sslobj.context = other_ctx असाइन करता है, मूल कॉन्टेक्स्ट के अंतिम Python रेफरेंस को गिरा सकता है, जबकि OpenSSL अभी भी उसके लिए एक उधार लिया गया पॉइंटर रखता है। अगला ClientHello (TLS 1.3 HelloRetryRequest पर्याप्त है) उस पॉइंटर से परामर्श करता है। हैंडशेक जारी रहता है। प्रोसेस बाद में क्रैश हो सकता है। क्लाइंट प्रभावित नहीं होते। लिसनिंग सॉकेट के लंबे समय तक चलने वाले रैप पर कोई प्रभाव नहीं पड़ता।

एक रिमोट TLS क्लाइंट सर्वर के डिस्पैच SSLContext को मुक्त कर सकता है, जबकि C SNI कॉलबैक अभी भी उसकी ओर इशारा करता है। हैंडशेक अभी भी पूरा होता है। क्रैश और मेमोरी-करप्शन विंडो। इस लैब में कोई RCE नहीं।

IDCVE-2026-19445
CWECWE-416
CVSSCritical: 9.2 CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:L
ProductCPython ssl
Affected< 3.12.15, 3.13.0–3.13.15, 3.14.0–3.14.7, 3.15.0a1 3.15.0 से पहले
Authअनऑथेंटिकेटेड TLS क्लाइंट, सर्वर को SNI-स्विच करना और मूल कॉन्टेक्स्ट को गिराना होगा
LicenseGNU Affero GPL v3.0
Labकेवल 127.0.0.1

हमलावर क्या कर सकता है

एक Python सर्वर से TLS बात करें जो कनेक्शन के लिए एक नया SSLContext बनाता है, sni_callback इंस्टॉल करता है, और उस कॉलबैक में एक अलग कॉन्टेक्स्ट असाइन करता है और फिर मूल को मरने देता है। SNI भेजें। दूसरा ClientHello बाध्य करें (सर्वर कर्व को P-384 तक सीमित करें ताकि एक डिफ़ॉल्ट X25519 क्लाइंट को HelloRetryRequest मिले)। GC के बाद, Python ऑब्जेक्ट चला गया है। C tlsext_servername कॉलबैक के पास अभी भी SSL_CTX_set_tlsext_servername_arg से उधार लिया गया args पॉइंटर है। हैंडशेक इस पिन पर पूरा होता है। ASan के तहत यह एक use-after-free है। प्रोडक्शन में यह एक क्रैश / करप्शन विंडो है जब अगली बार उस मेमोरी का पुनः उपयोग किया जाता है।

जो सर्वर लिसनिंग सॉकेट को एक बार प्रोसेस-लाइफटाइम कॉन्टेक्स्ट के साथ रैप करते हैं, वे रेफरेंस बनाए रखते हैं। वे इस बग से बाहर हैं। wrap_socket क्लाइंट इस बग से बाहर हैं।

एक ही उत्पाद, सहोदर अवशेष: wrap_bio होस्टनेम सत्यापन को छोड़ देता है। विपरीत TLS पक्ष। वे एक साथ नहीं मिलते।

मैंने इसे कैसे खोजा

PSF ने CVE-2026-19445 पोस्ट किया। आरक्षण मुद्दा python/cpython#156293 है। वास्तविक मानचित्र PR 158504 / commit 0f63c2aa है। _servername_callback ने उधार लिए गए OpenSSL arg का उपयोग किया। SNI द्वारा sslobj.context स्विच करने और मूल SSLContext के GC होने के बाद, दूसरा ClientHello अभी भी उसमें कॉल करता है। पैच SSL_get_app_data → ssl->ctx से कॉन्टेक्स्ट को देखता है और context_dealloc में कॉलबैक को साफ़ करता है।

मैंने CPython के अपने टेस्ट को python:3.14.7-slim-bookworm (3.14.7 प्रभावित रेंज में है; 3.14.8 फिक्स है) के विरुद्ध एक लैब के रूप में चलाया। MemoryBIO, UAF पथ के लिए कोई TCP नहीं।

dispatch_ctx.set_ecdh_curve("secp384r1"), क्लाइंट डिफ़ॉल्ट X25519। sni_callback sslobj.context = leaf_ctx असाइन करता है। पहले SNI के बाद, तीन gc.collect() कॉल, weakref.ref(dispatch_ctx) None है। हैंडशेक अभी भी पूरा होता है (TLS_AES_256_GCM_SHA384)। HRR _msg_callback में है (ServerHello रैंडम ऑफ़सेट 6 पर)। sni_calls=1: दूसरा ClientHello कभी किसी जीवित Python कॉलबैक तक नहीं पहुंचा।

द्वितीयक पथ (कॉलबैक स्विच, del ctx, LookupError उठाता है) ने 3.14.7 को निरस्त नहीं किया। SSLError: CALLBACK_FAILED, unraisable LookupError। नकारात्मक: 127.0.0.1:18500 पर लिसन सॉकेट को रैप करने वाला प्रोसेस-लाइफटाइम कॉन्टेक्स्ट। हैंडशेक काम करता है। Weakref जीवित रहता है।

पहले से दर्ज गलत मोड़: leaf के साथ-साथ dispatch पर भी P-384 पिन करना, और क्लाइंट को केवल X25519 तक लॉक करना, HRR के बजाय NO_SUITABLE_KEY_SHARE उत्पन्न करता है। CPython केवल dispatch कॉन्टेक्स्ट को पिन करता है। HRR मैजिक ServerHello ऑफ़सेट 6 पर है, 2 पर नहीं। पहली प्रोब ने HRR को मिस किया भले ही वह सक्रिय हुआ। dispatch_ctx wrap_bio के ठीक बाद अभी भी जीवित है क्योंकि server.context इसे रखता है। यह केवल SNI स्विच के बाद संग्रहणीय हो जाता है। नाटक: एक रिवर्स शेल। ओरेकल dispatch_ref is None प्लस एक पूर्ण हैंडशेक है।

लैब

cd lab
./run.sh

इमेज python:3.14.7-slim-bookworm। Compose प्रोजेक्ट cve-2026-19445। लूपबैक 127.0.0.1:18500 नकारात्मक लिसन रैप है। प्राथमिक/द्वितीयक ओरेकल इन-मेमोरी MemoryBIO में हैं।

primary_dispatch_ref_after_sni_gc='none'
primary_hrr='yes'
primary_handshake='complete'
SUCCESS CVE-2026-19445 dispatch_ctx_gc=yes handshake=complete hrr=yes secondary_crash=no CVE-2026-19445-SNI-UAF-WITNESS

फिक्स

सर्वर के जीवनकाल के लिए sni_callback सेट करने वाले प्रत्येक SSLContext का रेफरेंस रखें। 3.12.15 / 3.13.16 / 3.14.8 / 3.15.0 में अपग्रेड करें। C पैच उधार लिए गए OpenSSL arg का उपयोग करना बंद कर देता है।

संदर्भ

  • CVE-2026-19445
  • python/cpython#156293
  • PR 158504
  • commit 0f63c2aa
  • PSF security-announce
टूल डाउनलोड करें