glibc के `qsort()` में out-of-bounds read और write
हाल ही में पहचाना गया glibc के `qsort()` में out-of-bounds read/write तब होता है जब programs उसे एक “bad” comparison function देते हैं, जैसे वह जो integer subtraction पर overflow कर जाए या floats और NaNs के साथ ordering rules तोड़े। Commenters इस पर बहस करते हैं कि क्या यह glibc में वास्तव में security vulnerability है या केवल caller code की गलतियों से उत्पन्न undefined behavior, और क्या इसकी दुर्लभता तथा exploit कठिनाई को देखते हुए यह CVE का पात्र है। यह thread आगे C/C++ और Rust जैसी languages की safety cultures की तुलना करता है, और इस बात पर बहस करता है कि libraries को misuse से बचाव के लिए कितना जिम्मेदार होना चाहिए बनाम performance और simplicity बनाए रखना चाहिए.
qsort बग की प्रकृति
- यह बग glibc के
qsortमें out-of-bounds read/write है, जब caller एक non-transitive (buggy) comparison function प्रदान करता है। - कई लोग इसे “user error” (अमान्य parameter) मानते हैं,
memcpyको खराब pointers के साथ कॉल करने के समान, लेकिन फिर भी मानते हैं कि bounds checks ठीक करना अच्छी defensive practice है। - अन्य लोग ज़ोर देते हैं कि “obvious” comparator implementation (
a - b) integer overflow के कारण सूक्ष्म रूप से गलत है, इसलिए यह केवल कोई exotic edge case नहीं है।
“Holding it wrong” बनाम security vulnerability
- एक पक्ष तर्क देता है कि यह मुख्यतः application code की बग है, क्योंकि standards स्पष्ट रूप से total ordering की मांग करते हैं; undefined behavior caller पर निर्भर है।
- दूसरा पक्ष कहता है कि यदि एक सामान्य misuse memory corruption करा सकता है, तो यह एक वैध safety issue है और library implementation के लिए भी CVE का योग्य है।
- C/C++ culture में “यह UB है, इसलिए कुछ भी हो सकता है” वाले रवैये की आलोचना की जाती है, और इसके मुकाबले अन्य जगहों की अधिक defensive norms का उल्लेख होता है।
Comparators, NaNs, और floating point
- NaNs या खराब तरीके से संभाले गए infinities के साथ floats को sort करने से comparator requirements टूट सकती हैं, जिससे crashes या गलत behavior हो सकता है।
- उदाहरण दिखाते हैं कि NaNs reflexivity और transitivity को कैसे तोड़ते हैं, जिससे sort algorithms भ्रमित हो जाते हैं। कुछ लोग सुझाव देते हैं कि NaNs को sort करने की कोशिश करना स्वयं आमतौर पर एक logic bug है।
Language safety cultures और integer overflow
- Rust का उदाहरण दिया जाता है कि वह “आप इसे गलत तरीके से इस्तेमाल कर रहे हैं” मामलों को safety issues मानता है: bad comparators गलत परिणाम दे सकते हैं, लेकिन UB नहीं;
Ordजैसे traits safe होते हैं, जबकि अलग “unsafe traits” उन invariants के लिए होते हैं जिन्हें तोड़ने पर UB हो सकता है। - overflow handling पर चर्चा:
- Rust के checked/saturating/wrapping operations और debug-vs-release behavior।
- C/C++ में signed overflow को UB माना जाता है; unsigned wraparound अक्सर वह नहीं होता जो programmers चाहते हैं।
- Ada, Pascal, और WUFFS को ऐसे languages या DSLs के उदाहरण के रूप में लिया जाता है जो extra safety के लिए ranges/refinements encode करते हैं।
Performance और qsort के विकल्प
qsortको अपेक्षाकृत धीमा बताया गया है; high-performance code के लिए लोग C++std::sortया specialized libraries की सलाह देते हैं, कभी-कभी C से callable एक thin C++ wrapper के माध्यम से।- कुछ लोग extra safety checks की performance cost को लेकर चिंतित हैं; अन्य तर्क देते हैं कि cost आमतौर पर नगण्य होती है।
Exploitability, CVEs, और scoring
- Exploitability पर बहस है: इसके लिए पहले से buggy comparator चाहिए और अक्सर privileged (जैसे setuid-root) context भी चाहिए; thread में किसी in-the-wild exploit के ज्ञात होने की बात नहीं है।
- इस पर मिश्रित राय है कि CVE जारी होना चाहिए या नहीं:
- पक्ष में: यह users को comparators audit करने और update करने के लिए प्रेरित करता है।
- विरोध में: CVEs regulated environments के लिए महंगे होते हैं और उन्हें केवल स्पष्ट रूप से exploitable issues के लिए आरक्षित होना चाहिए।
- CVSS scores पर व्यापक निराशा भी है: कुछ गंभीर, आसानी से exploitable bugs को कम score मिलता है, जबकि अव्यावहारिक DoS-शैली bugs को उच्च score मिल जाता है, जिससे prioritization कठिन हो जाती है.