पिछले 24 घंटों में सार्वजनिक हुए Linux kernel के 432 CVE

 (lore.kernel.org)
1 पॉइंट द्वारा GN⁺ 6 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Hacker News के शीर्षक के अनुसार पिछले 24 घंटों में Linux kernel CVE 432 मामले सार्वजनिक हुए, लेकिन फिलहाल सूचना पेज पर उनकी अलग-अलग जानकारी देखी नहीं जा सकती
  • सर्वर डाउन होने और संसाधनों तक पहुंच पर रोक जैसी समस्याओं को, बड़े पैमाने पर web scraping की वजह से, रोकने के लिए सूचना पेज पर Anubis bot-रोकथाम प्रक्रिया लागू की गई है
  • Hashcash-आधारित Proof-of-Work के जरिए सामान्य एक्सेस का बोझ कम रखा जाता है, जबकि बड़े पैमाने पर scraping की कुल लागत बढ़ाई जाती है
  • यह तरीका अस्थायी समाधान है, जिसे तब तक इस्तेमाल किया जा रहा है जब तक headless browser की पहचान करने वाली तकनीक तैयार नहीं हो जाती
  • इसके लिए आधुनिक JavaScript फीचर्स की जरूरत है, और JShelter जैसे इन्हें ब्लॉक करने वाले plugins को उस डोमेन पर बंद करना होगा तभी एक्सेस मिल सकेगा

CVE सूचना पेज की मौजूदा स्थिति

  • Hacker News का शीर्षक कहता है कि पिछले 24 घंटों में Linux kernel CVE 432 मामले सार्वजनिक हुए, लेकिन दिए गए पेज पर CVE सूची या विस्तृत जानकारी नहीं है
  • इसके बजाय केवल कठिनाई स्तर 4 की Proof-of-Work गणना स्क्रीन दिखाई देती है

Anubis कैसे काम करता है और उसकी सीमाएं

  • Hashcash-आधारित Proof-of-Work हर अलग एक्सेस पर नगण्य गणनात्मक बोझ डालता है, लेकिन बड़े पैमाने पर scraping के लिए कुल लागत पैदा करता है
  • आगे चलकर फ़ॉन्ट rendering जैसे तरीकों से headless browser की fingerprinting कर, सामान्य उपयोगकर्ताओं को Proof-of-Work पेज दिखाए बिना एक्सेस देने का लक्ष्य है
  • Anubis को जिन आधुनिक JavaScript फीचर्स की जरूरत है, उन्हें JShelter आदि ब्लॉक कर सकते हैं, इसलिए एक्सेस के लिए ऐसे plugins को बंद करना होगा

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

1 टिप्पणियां

 
GN⁺ 6 시간 전
Lobste.rs की राय

  • CVE खुद vulnerability नहीं, बल्कि identifier होता है, और असल में vulnerability मिलने पर इसे सौंपा जा सकता है

    • बाद में इरादा समझ आया; शायद मतलब यह था कि शीर्षक Linux kernel vulnerabilities 432 होना चाहिए था

  • Linux kernel project ने कई बार कहा है कि performance fixes, hardware bug fixes, file system corruption वगैरह को छोड़कर वह ज़्यादातर bugs को CVE candidates मानता है

    http://www.kroah.com/log/blog/2026/01/02/linux-kernel-security-work/

    http://www.kroah.com/log/blog/2026/02/16/linux-cve-assignment-process/

    • kernel security team यह नहीं जान सकती कि kernel कहाँ और कैसे इस्तेमाल हो रहा है, और यह Linux kernel के अपने आप CVE Naming Authority (CNA) बनने का एक अनोखा नतीजा भी है
      CVE framework मूल रूप से products के लिए बनाया गया था, इसलिए वह ऐसे operating system kernel के साथ अच्छी तरह फिट नहीं बैठता जो कई products का component होता है। आदर्श स्थिति में CachyOS, kernel-embedded camera maker, और Red Hat को अपने-अपने environments में स्वतंत्र रूप से तय करना चाहिए कि वही bug CVE candidate है या नहीं
      लेकिन ऐसा करने पर 300 camera models, USB लगाने पर अजीब व्यवहार करने वाले 300 file-server routers, और SD card इस्तेमाल करने वाले दर्जनों retro game emulation consoles के लिए अलग-अलग CVE बन सकते हैं; इसलिए structure भले अटपटा हो, ecosystem के लिए component level पर इसे manage करना बेहतर है
    • file system corruption bugs को भी CVE candidate माना जा सकता है

  • जिज्ञासा है कि इनमें कोई खास तौर पर दिलचस्प vulnerability है या नहीं

  • काफी entries “Linux kernel में निम्न vulnerability ठीक की गई” जैसे वाक्य से शुरू होती हैं

  • खुद को रोक नहीं पाया और LLM से हर CVE के लिए attention-grabbing नाम बनाने को कहा
    https://git.infradead.org/~rw/cvenames-2026-07-19.html

  • पहली XFS-related entry देखने पर कहा गया है कि समस्या केवल manipulated log में होती है
    असल exploitation के लिए file system को offline करना और जिस block device पर log stored है उस पर सीधे लिखना पड़ता दिखता है; अगर ऐसा है, तो root privileges या physical access और system shutdown करने की क्षमता चाहिए लगती है। सोच रहा हूँ कि क्या मैंने XFS log को गलत समझा है

    • USB drive या SD card को auto-mount न करने वाले और physical monitoring वाले server के लिए यह threat नहीं हो सकता, लेकिन दूसरे Linux environments पर असर पड़ सकता है
      उदाहरण के लिए कोई “photos” होने का कहकर SD card दे, उसमें malicious XFS file system हो, और घर पर connect करते ही vulnerability chain attack चल पड़े। file system mount करना भी image file खोलने की तरह safe operation होना चाहिए
    • संभावना कम होने से वह potential vulnerability नहीं रह जाती, ऐसा नहीं है; usage environment भी अहम है
      ऐसे kiosk-type devices हो सकते हैं जो storage device connect होते ही auto-mount करते हों, और जो समस्या आम तौर पर अवास्तविक लगती है वह कई flaws या किसी specific environment के मिल जाने पर practical attack बन सकती है
    • colocation hosting facility में server से USB या HDD जोड़ने वाला attack करीब 95% success rate वाला लगता है
      camera में रिकॉर्ड हो भी जाए, तो यह साफ-साफ verify करना मुश्किल होगा कि उसे उसी rack के किसी दूसरे server में नहीं लगाया गया था