WorstFit: Windows ANSI के छिपे ट्रांसफॉर्मर का खुलासा

 (blog.orange.tw)
2 पॉइंट द्वारा GN⁺ 2025-01-10 | 1 टिप्पणियां | WhatsApp पर शेयर करें

WorstFit: Windows ANSI के छिपे ट्रांसफॉर्मर का खुलासा

TL;DR

  • Windows के इनबिल्ट चरित्र सेट कन्वर्ज़न फीचर Best-Fit का दुरुपयोग करके एक नया attack surface खोजा गया।
  • इसे वास्तविक attacks में बदला गया, जैसे कि path traversal, argument injection और remote code execution (RCE)।
  • समस्या की जड़ में compiler behavior, C/C++ runtime और डेवलपर की गलती है।
  • ओपन सोर्स इकोसिस्टम में patches को लागू करने की कठिनाइयों पर भी चर्चा की गई है।

Windows एन्कोडिंग डिकोड करना

शुरुआत: ANSI और कोड पेज

  • Windows ने शुरुआत में ANSI एन्कोडिंग का इस्तेमाल किया, जो किसी एक भाषा के लिए प्रभावी था लेकिन मिश्रित character sets को संभाल नहीं पाता था।
  • कई अलग-अलग code pages मौजूद थे, और प्रत्येक code page किसी विशेष भाषा को सपोर्ट करता था।

यूनिकोड युग: UTF-16

  • Windows ने 1990 के मध्य में यूनिकोड अपनाकर लगभग सभी भाषाओं के अक्षरों को एकल मानक में निरूपित करने की क्षमता हासिल की।
  • शुरुआत में UCS-2 का उपयोग हुआ, लेकिन जल्दी ही UTF-16 पर अपग्रेड कर दिया गया।

डुअल-एन्कोडिंग युग

  • Windows ने पुराने ANSI code pages को सपोर्ट करने के लिए दो API versions implement कीं।
  • ANSI API और Unicode API उपलब्ध हैं, जिससे डेवलपर को वांछित data format आसानी से मिल जाता है।

Best-Fit के फायदे

  • Windows का "Best-Fit" character conversion UTF-16 से ANSI में बदलते समय target code page में न मौजूद character को हैंडल करने का तरीका है।
  • उदाहरण के लिए, ∞ symbol Windows-1252 code page में मौजूद नहीं होने के कारण Microsoft इसे 8 पर map करता है।

WorstFit: Windows का नया attack surface

🔥 पूर्वी एशिया का दुःस्वप्न - CVE-2024-4577

  • CVE-2024-4577 एक vulnerability है जो Chinese या Japanese code page पर सेट PHP-CGI server को सिर्फ़ एक simple ?%ADs request से compromise कर सकता है।
  • Best-Fit behavior के कारण U+00AD (soft hyphen) dash (-) में map होता है, जिससे bypass संभव हो जाता है।

🔥 फाइल नाम स्मगलिंग

  • फाइल नाम processing में WorstFit का उपयोग करके path traversal payload में बदला जा सकता है।
  • उदाहरण के लिए, Chrome V8 के Developer Shell (d8.exe) में वर्तमान working directory पाने के लिए ANSI API का उपयोग किया जाता है।

🔥 आर्ग्युमेंट विभाजन

  • GetCommandLineA आउटपुट को manipulate करके WorstFit behavior को command line parsing में exploit किया जा सकता है।
  • उदाहरण के लिए, ＂ --use-askpass=calc ＂ इनपुट सिस्टम में calc.exe चलाने का कारण बन सकता है।

निष्कर्ष

  • Best-Fit behavior सिस्टम-स्तरीय conversion प्रोसेस में attack surface प्रदान करता है, जो कई tools में vulnerabilities का कारण बन सकता है।
  • इन attacks को standard libraries या programming language functions से पूरी तरह रोकना संभव नहीं है।

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-01-10
Hacker News टिप्पणी

  • माइक्रोसॉफ्ट को यह समस्या कम से कम एक साल पहले से पता थी। CA2101 नाम के एक विशेष कोड-एनालिसिस नियम के जरिए best-fit mapping का उपयोग न करने की सलाह दी। उन्होंने सुरक्षा vulnerability का उल्लेख तो किया था, लेकिन विवरण स्पष्ट नहीं थे।

  • यह एक सिस्टम-स्तरीय समस्या है। माइक्रोसॉफ्ट यूनिकोड को ASCII में बदलने के लिए "best fit" कोड मैपिंग देता है। यह मैपिंग कई जगहों पर उपयोग होती है और माइक्रोसॉफ्ट के लिए backward compatibility ज़रूरी होने के कारण इसे हटाने की कोई गुंजाइश नहीं है। मूल रूप से यह लगभग हर जगह जुड़ी हुई है।

    • यह अक्सर गलत/असामान्य code point को slash, hyphen, quote जैसे characters में बदलने के लिए दुरुपयोग होता है। आधुनिक programming languages में सही तरीके से evaluate हो सकता है, लेकिन जब इसे shell command या Win32 API में भेजते हैं तो समस्या होती है।

    • curl maintainer ने कहा कि "curl पीड़ित है", लेकिन वास्तविक कारण कहीं और था। जब server user input validate करने पर और सिस्टम लाइब्रेरी पर लागू करने पर अलग व्यवहार होता है, तब issue सामने आता है।

    • Win32 ecosystem में "best fit" conversion को selectively disable करना शायद समाधान हो सकता है। ओपन सोर्स योगदानकर्ता इसे best practice के रूप में जोड़ सकते हैं।

  • Windows कई features के साथ ऐसा काम करता है जैसे Munchkin card game में random cards मिलकर बड़ी vulnerability बना दें। ANSI subsystem को UTF-8 में बदलना शायद इस समस्या को कम कर सकता है।

  • Microsoft ने NT 3.5 से ANSI को धीरे-धीरे हटाना शुरू किया और Wide Character API को बेहतर विकल्प बताया। लेकिन Microsoft की C/C++ runtime library implementation ही मुख्य बाधा है।

    • मानक functions A-variant का उपयोग करते हुए Unicode conversion failure की रिपोर्ट नहीं करते और best-fit approach अपनाते हैं।

  • Microsoft के सभी Windows editions में UTF-8 को डिफ़ॉल्ट रूप से enable करने की संभावना कम है, क्योंकि पुराने applications अभी भी specific code page या 1-byte characters पर निर्भर हैं।

    • win32 xxxA API से Best-Fit logic हटाना शायद कम समस्याएँ पैदा करेगा।

  • applications में "Ansi" code page को UTF-8 पर force सेट करने के दो तरीके हैं। एक Manifest file, दूसरा "App Locale" tool।

  • मेरे personal Windows PC पर UTF-8 mode सेट करने से मैं इस bug से सुरक्षित रहा। एक पुराने foreign game में text टूटा हुआ दिख रहा था, इसलिए मैंने यह सेटिंग की थी।

  • समस्या केवल main() को wide-character संस्करण से बदल देने से ठीक नहीं होगी। सभी variables को wchar_t * में बदलना पड़ेगा और यह बहुत झंझटीला व त्रुटि-प्रवण काम है।

    • इसके बजाय प्राप्त wide characters को UTF-8 में बदलकर "char" का उपयोग जारी रख सकते हैं। ANSI या OEMCP strings और UTF-8 strings को mix नहीं करना चाहिए।

  • मैं Windows API में best-fit conversion उपलब्ध होने से परिचित था, लेकिन यह पता नहीं था कि यह default behavior है। यह feature हटाया जाना चाहिए।

  • सोचा था कि Beta checkbox शायद ActiveCodePage को UTF-8 सेट करने के बराबर है। GDI process-specific code page नहीं follow करती, केवल global code page पर काम करती है। UTF-8 को पूर्ण रूप से चुन पाने की अनुमति न होना खलता है।