Marimo GHSL-2026-226: टेस्ट-रिलीज़ workflow में TOCTOU दोष

एक ही सेकंड में timestamp race के कारण pull request का बदलाव maintainer की test-release मंज़ूरी पार करके TestPyPI और npm प्रकाशन jobs तक पहुँच सकता था। कमजोर workflow हटा दिया गया; कोई CVE नहीं दिया गया।

💡 आसान भाषा में (ELI5)

प्रयोगशाला प्रमुख एक नमूने को मंज़ूरी देता है, लेकिन प्रयोगशाला केवल घड़ी का सेकंड देखती है। उसी सेकंड नमूना बदलने पर बदला हुआ नमूना भी स्वीकृत लगता है। Marimo workflow ने pull request commit के साथ यही गलती की और बने हुए package को publishing jobs तक पहुँचा दिया।

इस पेज के मुख्य शब्द

TOCTOU: Time-of-check to time-of-use: सुरक्षा जाँच के बाद और उपयोग से पहले संसाधन बदल जाता है।
OIDC publishing: CI job GitHub Actions पहचान को package registry के अल्पकालिक credentials से बदलता है, बिना दीर्घकालिक password रखने के।
Workflow artifact: GitHub Actions jobs के बीच भेजी गई files का bundle। बाद के job को अविश्वसनीय workflow से मिले artifacts को अविश्वसनीय input मानना चाहिए।
GHSL-2026-226: Marimo workflow दोष के लिए GitHub Security Lab advisory पहचान। इस advisory में CVE नहीं दिया गया।
CWE-367 / CWE-829: Advisory जाँच-उपयोग समय-दौड़ और अविश्वसनीय नियंत्रण क्षेत्र की कार्यक्षमता चलाने की समस्या बताता है।

फ्रेमवर्क मैपिंग

इस गाइड में बताई गई कमजोरी के लिए CWE संदर्भ: CWE-367 CWE-829

हमले का चरण-दर-चरण प्रवाह

चरण 1

Maintainer test release की मंज़ूरी देता है

Maintainer pull request पर टिप्पणी करके Marimo test-release workflow शुरू करता है। मंज़ूरी उसी pull request स्थिति के लिए होनी चाहिए जिसकी समीक्षा की गई थी।

चरण 2

Pull request head उसी सेकंड बदलता है

Workflow pushed_at और टिप्पणी के created_at को पूर्ण सेकंड में बदलकर तुलना करता है। उसी सेकंड का push बराबर मान देता है।

चरण 3

कमजोर जाँच बराबरी स्वीकार करती है

हटाया गया workflow केवल तब रोकता था जब pushed_at टिप्पणी के समय से सख्ती से बाद का हो। बराबरी पार हो जाती थी और नया commit दर्ज होता था।

चरण 4

अविश्वसनीय code package artifacts बनाता है

Job उस commit को checkout करके repository-नियंत्रित actions और build scripts चलाता था। बने artifacts को upload किया जाता और विश्वसनीय commit से दोबारा build किए बिना publishing jobs में उपयोग किया जाता था।

चरण 5

Publishing अधिकार अविश्वसनीय output तक पहुँचते हैं

TestPyPI और npm jobs में OIDC publishing permissions थीं। Advisory कहता है कि artifact प्रकाशन तक पहुँच सकता था; किसी वास्तविक package compromise की रिपोर्ट नहीं है।

सोर्स कोड: कमज़ोर बनाम सुरक्षित कार्यान्वयन

GHSL-2026-226 बताता है कि कमजोर workflow PR #10765 में हटाया गया; यह दावा नहीं है कि project ने यहाँ दिखाया गया comparator परिवर्तन किया। पुराने check में -gt था, इसलिए बराबर पूर्ण-सेकंड timestamps पार हो जाते थे। उदाहरण का -ge बराबरी रोकता है, लेकिन मंज़ूरी को ठीक उसी reviewed commit से बाँधना बेहतर है। Untrusted builds को OIDC jobs से अलग रखें, approved SHA से rebuild करें और publication से पहले provenance जाँचें। कोई exploit payload शामिल नहीं है।

कमज़ोर कार्यान्वयन

# हटाया गया marimo-bot workflow: पूर्ण सेकंड की तुलना
if [[ $(date -d "$pushed_at" +%s) -gt $(date -d "$COMMENT_AT" +%s) ]]; then
    exit 1
fi
# प्राप्त head_sha checkout हुआ और artifacts अलग
# publishing jobs को भेजे गए।

सुरक्षित और सुदृढ़ फ़िक्स

# यह केवल उदाहरण नियंत्रण है; GHSL के अनुसार कमजोर workflow
# को वहीं patch करने के बजाय हटा दिया गया था।
if [[ $(date -d "$pushed_at" +%s) -ge $(date -d "$COMMENT_AT" +%s) ]]; then
    exit 1
fi
# बेहतर डिज़ाइन: समीक्षा किए गए immutable SHA को मंज़ूरी दें,
# trusted job में उसी से rebuild करें और verified output प्रकाशित करें।

इंजीनियरिंग और सिस्टम सुरक्षा चेकलिस्ट

✓हटाए गए marimo bot workflow की प्रभावित copies हटाएँ या बदलें और पुष्टि करें कि वर्तमान repository कमजोर publishing path सक्षम नहीं करता।
✓Maintainer approval को सटीक immutable pull-request SHA से बाँधें और checkout से पहले head बदलने पर fail बंद करें।
✓पूर्ण-सेकंड timestamps को यह साबित करने का एकमात्र आधार न बनाएँ कि mutable branch स्वीकृत संस्करण है।
✓Untrusted pull requests को publishing credentials के बिना build करें; id-token: write केवल अलग trusted publishing job को दें।
✓Untrusted code द्वारा बनाए artifacts को आगे बढ़ाने के बजाय trusted release path में approved commit से package दोबारा build करें।
✓TestPyPI या npm पर प्रकाशित करने से पहले artifact provenance, source revision, package contents और target जाँचें।
✓GHSL advisory को vulnerable path का प्रमाण मानें, वास्तविक package compromise या exploitation का प्रमाण नहीं।