RegreSSHion: glibc-आधारित Linux OpenSSH सर्वर में रिमोट कोड execution (RCE)

 (qualys.com)
1 पॉइंट द्वारा GN⁺ 2024-07-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • OpenSSH सर्वर sshd में signal handler race condition के कारण, authentication से पहले की समय-सीमा LoginGraceTime के भीतर authenticate न करने वाला client default configuration वाले server पर remote code execution करा सकता है
  • यह vulnerability 2006 के CVE-2006-5051 की regression है, और अक्टूबर 2020 में OpenSSH 8.5p1 commit द्वारा sigdie() से safeguard हटाए जाने के बाद 8.5p1 और उससे ऊपर, लेकिन 9.8p1 से कम versions में फिर से आ गई
  • glibc-आधारित Linux में syslog() malloc()·free() जैसे async-signal-unsafe functions को call करता है, जिससे unsandboxed sshd के privileged code में authentication के बिना root RCE हो सकता है
  • प्रयोग i386 virtual machine और लगभग 10ms packet jitter वाले स्थिर network पर किए गए; Debian 12.5.0 OpenSSH 9.2p1 में औसतन लगभग 10,000 attempts लगे और MaxStartups=100, LoginGraceTime=120 conditions में root shell तक पहुँचने में लगभग 6–8 घंटे लगे
  • OpenSSH ने 6 जून 2024 को commit 81c1099 से इसे fix किया; यदि update या recompile करना कठिन हो, तो LoginGraceTime 0 से RCE रोका जा सकता है, लेकिन MaxStartups connection exhaustion DoS का जोखिम बना रहता है

vulnerability कहाँ पैदा होती है

  • OpenSSH sshd की समस्या authentication से पहले चलने वाले SIGALRM handler से शुरू होती है
    • यदि client LoginGraceTime के भीतर authenticate नहीं करता, तो SIGALRM handler asynchronously call होता है
    • यह handler syslog() जैसे ऐसे functions को call करता है जो async-signal-safe नहीं हैं
    • default value LoginGraceTime=120 seconds है, और पुराने OpenSSH versions में यह 600 seconds थी
  • यह vulnerability CVE-2006-5051 की regression है
    • CVE-2006-5051, 2006 में Mark Dowd द्वारा report की गई OpenSSH 4.4 से पहले की signal handler race condition है
    • अक्टूबर 2020 में OpenSSH 8.5p1 के commit 752250c ने गलती से sigdie() से #ifdef DO_LOG_SAFE_IN_SIGHAND हटा दिया
  • version के हिसाब से impact range साफ़ अलग-अलग है
    • OpenSSH 4.4p1 से कम: यदि CVE-2006-5051 या CVE-2008-4109 से जुड़े patches backport नहीं किए गए हैं, तो vulnerable
    • OpenSSH 4.4p1 और उससे ऊपर, लेकिन 8.5p1 से कम: sigdie() को safe _exit(1) call में बदल दिया गया था, इसलिए इस race condition के लिए vulnerable नहीं
    • OpenSSH 8.5p1 और उससे ऊपर, लेकिन 9.8p1 से कम: safeguard हटने से फिर vulnerable

प्रभावित environments और exceptions

  • remote exploitation का target glibc-आधारित Linux है
    • glibc का syslog() internally malloc() और free() जैसे async-signal-unsafe functions को call करता है
    • vulnerable code sshd के privileged code में है, sandboxed नहीं है और full privilege के साथ run होता है
    • नतीजतन authentication के बिना remote root code execution संभव है
  • अन्य libc या operating systems investigation में शामिल नहीं थे
  • OpenBSD vulnerable नहीं है
    • OpenBSD का SIGALRM handler syslog() के बजाय syslog_r() call करता है
    • syslog_r() OpenBSD द्वारा 2001 में बनाया गया async-signal-safer version है

remote exploitation research की assumptions

  • remote से इस race condition को exploit करने के लिए तीन समस्याएँ हल करनी होती हैं
    • ऐसा code path चाहिए जो SIGALRM के सही समय पर बीच में आने पर sshd को inconsistent state में छोड़ दे
    • उस code path तक पहुँचना और सही समय पर interruption होने की probability बढ़ानी होगी
    • remote network environment में भी वह timing match करनी होगी
  • research की शुरुआत सीधे modern protections से भिड़ने के बजाय पुराने OpenSSH के i386 environment से हुई और फिर recent versions तक expand की गई
  • experimental conditions की साफ़ limitations हैं
    • target bare-metal server नहीं, केवल virtual machines थे
    • network लगभग 10ms packet jitter वाला relatively stable link था
    • exploit के कई parts और बेहतर किए जा सकते हैं
    • amd64 exploit पर काम शुरू हुआ, लेकिन मजबूत ASLR की वजह से यह काफी कठिन है

पुराने OpenSSH targets पर experiments

  • Debian 3.0r6, OpenSSH 3.4p1

    • target SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3 है, जो Debian 3.0r6 का 2005 का environment है
    • यह Debian version privilege separation को default रूप से enable करने वाला पहला Debian version था, और उस समय के major vulnerability patches लागू थे
    • exploitation free() interruption और heap inconsistent state का उपयोग करता है
      • public key parsing code के अंदर free() call को SIGALRM से interrupt किया जाता है
      • इसके बाद packet_close() के अंदर एक और free() में inconsistent heap state का उपयोग किया जाता है
    • glibc 2.2.5 में Solar Designer की unlink() technique के खिलाफ hardening नहीं थी
    • attack __free_hook को overwrite कर execution flow को heap में shellcode address पर बदलता है
    • इस Debian version में न ASLR है, न NX
    • timing improvements के बाद औसतन लगभग 10,000 attempts की जरूरत पड़ी
    • MaxStartups=10, LoginGraceTime=600 conditions में remote root shell तक पहुँचने में औसतन लगभग 1 सप्ताह लगा

  • Ubuntu 6.06.1, OpenSSH 4.2p1

    • target SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu3 है, जो Ubuntu 6.06.1 का 2006 का environment है
    • यह आखिरी Ubuntu version है जो अभी भी CVE-2006-5051 के लिए vulnerable है
    • glibc 2.3.6 malloc-family functions में प्रवेश करते समय mandatory lock लेता है, इसलिए malloc interruption के बाद दूसरे malloc call को exploit करने का तरीका deadlock में बदल जाता है
    • अंतिम exploitation path PAM का उपयोग करता है
      • pam_start() sshd का global sshpam_handle pointer set करता है
      • यदि _pam_add_handler() interrupt हो जाए, तो uninitialized next field रह सकता है
      • जब pam_end() SIGALRM handler में call होता है, तो arbitrary pointer को free() में pass किया जा सकता है
    • glibc की पुरानी unlink() technique blocked थी, इसलिए Malloc Maleficarum के House of Mind fastbin version का उपयोग किया गया
    • fake arena को sshd के .got.plt की ओर point कराया गया और _exit() entry को heap shellcode address से overwrite किया गया
    • इस Ubuntu का heap default रूप से executable है
    • औसतन लगभग 10,000 attempts की जरूरत पड़ी
    • MaxStartups=10, LoginGraceTime=120 conditions में remote root shell तक पहुँचने में औसतन लगभग 1–2 दिन लगे
    • बदकिस्मत attacker root shell पाने से पहले सभी 10 MaxStartups connections को deadlock करा सकता है

Debian 12.5.0, OpenSSH 9.2p1 experiment

  • syslog() और glibc malloc path

    • target SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u2 है, जो Debian 12.5.0 का 2024 current stable environment है
    • यह environment CVE-2006-5051 regression के लिए vulnerable है
    • इस version का SIGALRM handler packet_close() या pam_end() call नहीं करता, बल्कि syslog() path की ओर जाता है
      • grace_alarm_handler() sigdie() call करता है
      • sigdie() sshlogv() और do_log() से होकर syslog() call करता है
    • Debian glibc 2.36 का syslog() पहली call पर malloc call करता है
      • __localtime64_r() path में __tzfile_read() call होता है
      • fopen() FILE structure के लिए malloc(304) call करता है
      • internal read buffer के लिए malloc(4096) भी call करता है
    • glibc malloc अक्टूबर 2017 के बाद single-threaded situations में mandatory lock नहीं लेता
    • sshd जैसे single-threaded process में malloc race exploitation की संभावना बनती है

  • ASLR conditions और i386 constraints

    • Debian 12.5.0 i386 environment में ASLR weakness है
    • sshd का PIE, heap, अधिकांश libraries और stack आम तौर पर randomized होते हैं
    • glibc खुद हमेशा 0xb7200000 या 0xb7400000 पर mapped होता है
    • glibc address को 50% probability से hit किया जा सकता है
    • exploit assume करता है कि glibc 0xb7400000 पर mapped है
    • क्योंकि यह address 0xb7200000 से थोड़ा ज्यादा common था

  • heap inconsistency और FILE structure exploitation

    • चुना गया malloc path एक बड़े free chunk को दो हिस्सों में बाँटने वाला split path है
    • एक returned chunk और remainder chunk बनता है
    • यदि SIGALRM remainder chunk के unsorted list में जुड़ने के बाद, लेकिन size field initialization से पहले बीच में आ जाए, तो heap inconsistency पैदा होती है
    • attacker पिछले heap allocation के residual data के जरिए remainder chunk के size field को control करता है
    • remainder chunk को वास्तविक से बड़ा बनाकर दूसरे heap chunk से overlap कराया जाता है
    • SIGALRM handler के अंदर malloc इस chunk का उपयोग करता है और heap memory corrupt होती है
    • target __tzfile_read() के अंदर fopen() द्वारा heap पर allocate किया गया FILE structure है
      • limited heap corruption से FILE structure के _vtable_offset का 1 byte overwrite किया जाता है
      • glibc libio function vtable pointer को default location के बजाय किसी और offset पर ढूँढता है
      • attacker उस location के fake vtable pointer और _codecvt pointer को पिछले heap allocation के residual data से control करता है
    • i386 glibc में इस technique से __fread_unlocked() के दौरान arbitrary function pointer __fct call किया जा सकता है
    • amd64 glibc में _vtable_offset इस्तेमाल नहीं होता प्रतीत होता है

  • heap layout और 27 race windows

    • केवल एक small race window से race condition जीतना कठिन होने के कारण, 27 pairs of large hole and small hole बनाए गए
    • 28 pairs PACKET_MAX_SIZE 256KB से ज्यादा हो जाते हैं
    • final packet malloc(~4KB), malloc(304), malloc(~4KB), malloc(304) sequence को force करता है
    • यदि हर large hole split सही moment पर interrupt हो, तो SIGALRM handler का fopen() corresponding small hole को FILE structure के रूप में allocate करता है
    • heap layout बनाने के लिए sshd के public key parsing code का उपयोग किया गया
      • cert_parse() और cert_free() paths से लगभग arbitrary malloc() और free() sequence perform किया गया
      • memory leak न मिलने के कारण tcache chunk को temporary barrier chunk के रूप में इस्तेमाल किया गया
    • पाँच तरह के public key packets भेजे गए
      • a/ uncontrollable heap allocation को tcache chunk में जाने दिया
      • b/ 27 pairs of large/small holes और barrier chunk बनाए
      • c/ fake header, fake footer, fake vtable, _codecvt pointer लिखे
      • d/ लगभग 256KB की बड़ी string allocate और free कर holes को unsorted list से संबंधित malloc bins में move किया
      • e/ final malloc sequence force कर 27 small race windows खोले

  • modern version के लिए timing strategy

    • पुराने versions में इस्तेमाल की गई feedback-based timing strategy OpenSSH 9.2p1 target पर काम नहीं आई
    • पाँचवें public key parsing में लगभग 10ms लगते हैं, जिससे large race window बहुत बड़ा हो जाता है
    • OpenSSH 7.8p1 में introduce किया गया user_specific_delay() response को अधिकतम लगभग 9ms delay करता है, जिससे पुराने feedback खराब हो जाते हैं
    • नई strategy दो तरह के intentional error response times की तुलना करती है
      • public key parsing से ठीक पहले error trigger करने वाला packet भेजा जाता है
      • public key parsing के ठीक बाद error trigger करने वाला packet भेजा जाता है
      • दोनों response times के अंतर से final public key parsing time measure किया जाता है
    • इस strategy से औसतन लगभग 10,000 attempts में race condition जीती गई
    • MaxStartups=100, LoginGraceTime=120 conditions में race condition जीतने तक औसतन लगभग 3–4 घंटे लगे
    • ASLR की वजह से remote root shell तक पहुँचने में औसतन लगभग 6–8 घंटे चाहिए

amd64 exploit की progress

  • amd64 target Rocky Linux 9 रखा गया
    • target image Rocky-9.4-x86_64-minimal.iso है
    • OpenSSH 8.7p1 इस signal handler race condition के लिए vulnerable है
    • ASLR weakness के कारण glibc 2MB multiples पर mapped होती है, जिससे partial pointer overwrite और ज्यादा शक्तिशाली हो जाता है
  • Rocky Linux 9 का glibc 2.34 syslog() internally __open_memstream() call करता है
    • heap पर FILE structure को malloc() करता है
    • calloc(), realloc(), free() भी call करता है, जिससे extra room मिलता है
  • heap corruption primitive, heap पर allocate होने वाले दो FILE structures और glibc address के 21 fixed bits के आधार पर amd64 पर भी exploitation संभव माना गया
    • estimated time i386 के 6–8 hours से लंबा है, लेकिन एक सप्ताह से कम की उम्मीद बताई गई
  • Ubuntu 24.04 के बारे में अलग observation भी है
    • Ubuntu 24.04 sshd child की ASLR को re-randomize नहीं करता, बल्कि boot के समय केवल एक बार randomize करता है
    • कारण rexec_flag को बंद करने वाले systemd-socket-activation.patch तक traced है
    • आम तौर पर यह अच्छा विकल्प नहीं है, लेकिन इस vulnerability में SIGALRM handler के अंदर syslog() पहला syslog() call नहीं है, इसलिए malloc functions call नहीं होते और exploitation रुकता है
    • संबंधित patch: https://git.launchpad.net/ubuntu/+source/…

patch और mitigations

  • OpenSSH ने 6 जून 2024 को commit 81c1099 से इस race condition को fix किया
    • 81c1099: sshd(8) में problematic client behavior को penalise करने वाली functionality जोड़ी
    • async-signal-unsafe code को sshd के SIGALRM handler से listener process में ले जाकर synchronously handle किया गया
  • यह fix बड़े commit 81c1099 और उससे भी बड़े defense-in-depth commit 03e3de4 पर आधारित है, इसलिए backport करना कठिन हो सकता है
  • यदि backport कठिन हो, तो sshsigdie() से async-signal-unsafe code हटाया या comment out किया जा सकता है ताकि केवल _exit(1) call हो
  • यदि update या recompile संभव नहीं है, तो configuration file में LoginGraceTime को 0 set किया जा सकता है
    • यह setting इस advisory के remote code execution को रोकती है
    • लेकिन सभी MaxStartups connections exhaust होने वाले DoS के लिए vulnerable बना देती है

disclosure timeline

  • 2024-05-19: OpenSSH developers से संपर्क किया गया, और उसके बाद patches व reviews का दौर चला
  • 2024-06-20: distros@openwall से संपर्क किया गया
  • 2024-07-01: coordinated release date के रूप में public किया गया

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

1 टिप्पणियां

 
GN⁺ 2024-07-02
Hacker News की राय

  • दिलचस्प है कि RCE fix लगभग एक महीने पहले सार्वजनिक रूप से “मिला-जुला” कर डाला गया लगता है
    जब PerSourcePenalties चालू होता है, तो sshd(8) authentication से पहले वाले child session process के exit status पर नज़र रखता है, और बार-बार authentication failure या sshd crash जैसी conditions को client address के लिए कुछ समय की penalty के रूप में record करता है
    https://github.com/openssh/openssh-portable/commit/81c1099d2...
    यह attacker को कुछ बता देने वाला reverse-engineer किया जा सकने वाला patch होने के बजाय, binary structure बदलकर किसी खास vulnerability को हटाने और उस पूरे exploit family को भी mitigate करने का side effect रखता दिखता है, इसलिए काफी clever लगता है

    • वह RCE fix नहीं है; असली RCE fix यह है: https://news.ycombinator.com/item?id=40843865
      ऊपर वाला बदलाव garbage connections से निपटने के लिए पहले से घोषित feature था, और बस race condition जीतना कठिन बनाकर इस vulnerability को भी mitigate करता है
      पिछली चर्चा: https://news.ycombinator.com/item?id=40610621
    • सोच रहा हूं कि यह fix पहले ही distributions में शामिल या backport हो चुका है या नहीं
    • दिलचस्प है कि यह comment गलत था और ठीक नीचे correct भी कर दिया गया, फिर भी 2 दिनों तक सबसे ऊपर बना रहा
      सोचता हूं कि क्या लोग thread का पहला comment ही पढ़कर upvote कर देते हैं और गलत impression लेकर चले जाते हैं

  • OpenSSH release notes का एक हिस्सा दिलचस्प है
    “ASLR चालू होने वाले 32-bit Linux/glibc systems पर successful exploitation demonstrate किया गया है। lab conditions में attack के लिए server द्वारा allowed maximum तक लगातार connections को औसतन 6–8 घंटे बनाए रखना पड़ता है। माना जाता है कि 64-bit systems पर भी यह possible है, लेकिन अभी demonstrate नहीं हुआ है। ऐसे attacks के improve होने की काफी संभावना है।”
    https://www.openssh.com/releasenotes.html

  • जिस diff [1] से bug आया, उसे देखने पर analysis के हिसाब से problem यह है कि sigdie() पहले #ifdef DO_LOG_SAFE_IN_SIGHAND से wrapped था, लेकिन refactor होकर sshsigdie() के सीधे sshlogv() call करने वाले रूप में जाते समय #ifdef छूट गया
    इसे क्या रोक सकता था? क्या pull requests को और ज्यादा लोगों ने देखना चाहिए था? यह हैरान करने वाला है कि जिस software पर पूरी दुनिया secure access के लिए निर्भर है, उसे effectively दो लोग [2] maintain करते दिखते हैं
    [1] https://github.com/openssh/openssh-portable/commit/752250caa...
    [2] https://github.com/openssh/openssh-portable/graphs/contribut...

    • hindsight में यह कहना आसान है कि इसे रोकने के लिए क्या किया जा सकता था
      इस मामले में अगर comment होता कि #ifdef क्यों जरूरी है, तो मदद मिल सकती थी। जैसे: “यहां का code async-signal-safe होना चाहिए, और lock state अनिश्चित हो सकती है”
      हालांकि ईमानदारी से कहें तो getrlimit भी इस list में नहीं है: https://man7.org/linux/man-pages/man7/signal-safety.7.html
      फिर भी अगर async-signal-safety से जुड़ा comment लगा code हटाया या बदला गया होता, तो review में ध्यान जाने की संभावना थी। उद्धृत code में SAFE_IN_SIGHAND जैसा नाम ही बस यह संकेत देता है कि इस code को signal handler के अंदर safe होना चाहिए
    • क्योंकि OpenBSD ने system को async-signal-safe reentrant syslog function इस्तेमाल करने के लिए refactor कर दिया था, संभव है कि इस code के लेखक ने सरलता से मान लिया हो कि change safe है
      वे भूल गए होंगे या उन्हें पता नहीं रहा होगा कि OpenBSD ssh developers जिन दूसरे platforms को वास्तव में support करने का दावा नहीं करते, उन पर अभी भी async-signal-unsafe functions इस्तेमाल होते हैं
    • यह open source है। अगर आपको लगता है कि आप बेहतर कर सकते हैं, तो कभी भी fork कर सकते हैं
      open source developers से कुछ पाने का कोई अधिकार नहीं है। वे भी गलतियां कर सकते हैं, और कितने maintainers या reviewers रखने हैं, यह वे खुद तय कर सकते हैं
      https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...
    • “जिस software पर पूरी दुनिया secure access के लिए निर्भर है, उसे effectively दो लोग maintain करते हैं” वाली बात पर अनिवार्य रूप से यह xkcd याद आता है: https://xkcd.com/2347/
    • रोकने के कुछ तरीके थे
      1. ऐसी proper programming language इस्तेमाल करना जो arbitrary functions को signal handler के रूप में set न करने दे। सामान्य libc में यह साफ तौर पर unsafe है, और safe Rust या Java में आप ऐसा नहीं कर सकते
      2. ऐसी अच्छी तरह implemented libc इस्तेमाल करना जिसमें async-signal-unsafe function call करने पर memory corruption नहीं, बल्कि ज्यादा से ज्यादा deadlock जैसी स्थिति बने। signal के अंदर चलने वाले code को thread-local storage access के नजरिए से अलग thread जैसा treat किया जाए तो यह अपेक्षाकृत आसानी से संभव है, और global mutex न हों या mutex पकड़कर रुके हुए code को resume किया जा सके तो deadlock भी टाला जा सकता है
      3. code change और approval के समय सोच-विचार करना। [1] की तरह बिना आधार #ifdef हटाने वालों जैसा न करना
      4. OpenSSH के बजाय अच्छे programmers द्वारा लिखा गया simple और well-designed software इस्तेमाल करना

  • रिलीज़ नोट्स भी पढ़ने लायक हैं: https://www.openssh.com/releasenotes.html
    यह असल में एक दिलचस्प signal race condition bug का variant है। vulnerability report के मुताबिक, “OpenBSD खास तौर पर vulnerable नहीं है, क्योंकि SIGALRM handler syslog() के async-signal-safe version syslog_r() को call करता है, जिसे OpenBSD ने 2001 में बनाया था”
    यानी signal-safety mitigation ने OpenBSD developers को signal handler के अंदर non-trivial code डालने के लिए प्रेरित किया, और वही code दूसरे systems में port होने पर unsafe हो गया। अगर सामान्य समझ और Unix code conventions के मुताबिक signal handler के अंदर code को न्यूनतम रखने के लिए refactoring की गई होती, तो यह bug टल जाता

    • Theo de Raadt ने इस bug और मिलते-जुलते bugs की रोकथाम पर काफी वाजिब observation किया: कोई भी signal handler signal-safe system call न होने वाले functions को call नहीं करना चाहिए
      क्योंकि समय के साथ transitive calls में कहीं न कहीं async-signal-unsafe call मिल जाना बहुत आसान है, और यह भी हमेशा स्पष्ट नहीं होता कि वह path signal context से reachable है
    • काफी संभावना है कि जिन युवा system administrators या interns को इस vulnerability को patch करना होगा, उनमें से कुछ लोग तब पैदा भी नहीं हुए थे जब OpenBSD ने यह समाधान implement किया था

  • अपने OpenSSH instances को upgrade करने के बाद, मैंने देखा कि वे glibc के बजाय musl से linked हैं, इसलिए मैंने जांचा कि musl का syslog(3) भी allocation करता है या नहीं, और इसलिए क्या उसी तरह आसानी से exploit हो सकता है
    देखने में ऐसा नहीं लगता: https://github.com/bminor/musl/blob/master/src/misc/syslog.c
    वहां सब कुछ stack पर है या lock के साथ re-entry रोकने वाले static variables हैं। {d,sn,vsn}printf() calls भी musl में allocation नहीं करते, लेकिन glibc में कर सकते हैं। क्या मैं कुछ miss कर रहा हूं?

    • Rich की पुष्टि: https://fosstodon.org/@musl/112711796005712271
    • अगर allocation पर मेरा आकलन सही है, तो worst case शायद इतना ही होगा कि lock recursive नहीं है, इसलिए deadlock हो जाए
      फिर भी अगर sigalrm के अंदर deadlock हो जाए तो connection cleanup रुक सकता है, जिससे denial of service हो सकता है

  • FreeBSD के लिए patch आ गया है
    प्रभावित है या नहीं, यह स्पष्ट नहीं है। ज्ञात exploit सिर्फ glibc पर संभव था और FreeBSD glibc इस्तेमाल नहीं करता, लेकिन safe side पर रहना बेहतर है
    https://www.freebsd.org/security/advisories/FreeBSD-SA-24:04...

  • report के मुताबिक, अगर आप sshd को update या recompile नहीं कर सकते, तो config file में LoginGraceTime को 0 set करने भर से यह signal handler race condition ठीक हो सकता है
    इस case में sshd सभी MaxStartups connections खत्म हो जाने वाले denial of service के लिए vulnerable हो जाएगा, लेकिन इस advisory में बताए गए remote code execution से सुरक्षित रहेगा
    इसलिए sshd_config में LoginGraceTime 0 set करना mitigation लगता है

    • रुकिए, https://www.man7.org/linux/man-pages/man5/sshd_config.5.html में लिखा है कि value 0 होने पर कोई time limit नहीं होती
      तो क्या यह और भी खराब नहीं है?
    • अधिक practical workaround यह हो सकता है कि grace time को काफी लंबा कर दिया जाए, या उलटे maximum connections को adjust किया जाए ताकि successful attack की probability कोशिश करने लायक timeframe से बहुत दूर चली जाए
    • क्या sshd को हर घंटे cold restart करने से exploit की संभावना कम हो सकती है या इसे और मुश्किल बनाया जा सकता है?

  • Debian 12 के लिए patch आ गया है, और Debian 11 प्रभावित नहीं है
    https://security-tracker.debian.org/tracker/CVE-2024-6387

    • Focal(20.04) प्रभावित version नहीं लगता, और Jammy(22.04) प्रभावित लगता है
    • Debian 12 server पर अभी apt update और upgrade चलाया, और upgrade सिर्फ OpenSSH packages का हुआ
    • पुष्टि की कि Pi OS bullseye में भी updated openssh आ गया है

  • वाकई शानदार खोज है
    मैं खुद सीधे इस काम में नहीं हूँ, लेकिन security research में अक्सर ऐसा माहौल महसूस होता है कि “जीतने” के लिए किसी एक समस्या को ढूँढकर ठीक करवाना या reward पाना काफी नहीं, बल्कि remote access तक पहुँचने वाली पूरी chain ढूँढनी पड़ती है
    लगता है कि एक single hole, जैसे memory corruption का एक मामला या sandbox escape का एक मामला भी काफी होना चाहिए। आजकल छोटी-छोटी समस्याएँ इतनी ज्यादा हैं कि शायद लोगों से उन्हें सच में गंभीरता से लेने या bug bounty दिलवाने के लिए अंत तक जाने वाला hack दिखाना पड़ता है

    • कई aspiring security researchers ऐसे issues ढूँढ लेते हैं जो exploitable नहीं होते, और फिर CVE number या recognition, यहाँ तक कि reward भी माँगते हैं
      उदाहरण के लिए, अगर कोई app गलत trusted input मिलने पर crash हो जाता है, लेकिन उस app की प्रकृति ऐसी है कि उसे किसी adversary के सामने expose करने का इरादा ही नहीं है और व्यवहार में ऐसा होने की संभावना भी नहीं है, तो ज्यादातर लोग इसे बस bug मानेंगे, security bug नहीं। इसे ठीक करना अच्छा होगा, लेकिन यह उसी स्तर की बात नहीं है, और ऐसी चीजें ढूँढना भी बहुत मुश्किल नहीं होता
      इसलिए इस case जैसे “असली” security bug और security impact न रखने वाले bugs में फर्क करना जरूरी है, और यह साबित करना कि issue exploitable है बहुत महत्वपूर्ण है
      security impact न रखने वाले bugs तो अंतहीन होंगे, इसलिए ऐसा proof माँगना जल्द खत्म होता नहीं दिखता
    • एक अलग नज़रिया देखें: मान लीजिए मैंने ऐसी serialization/deserialization library बनाई है जो untrusted data डालने पर vulnerable हो जाती है
      यह design से ही ऐसा है, और users lambda functions सहित कुछ भी serialize और deserialize कर सकते हैं। मेरी library का इरादा सिर्फ trusted sources के data को process करने का है
      मेरी जानकारी में कोई भी इस library को untrusted data process करने के लिए इस्तेमाल नहीं करता। एक लोकप्रिय library config files पढ़ने के लिए मेरी library इस्तेमाल करती है, लेकिन वे config files को trusted data मानते हैं। और दूसरे लोग मेरी library कैसे इस्तेमाल करते हैं, इसे police करना मेरा काम नहीं है
      ऐसी स्थिति में क्या मेरे project में remote code execution vulnerability है कहकर highest-priority CVE register करना सही होगा?
    • मैं reporting वाली भूमिका में रहा हूँ, और “exploitable vulnerability” और “security weakness जो कभी exploitable vulnerability तक ले जा सकती है” बहुत अलग चीजें हैं
      reward हमेशा पहली category को मिलता है। दूसरी category की reports, अगर proof of concept या exploitability proof न हो, तो उल्टा reputation या signal को नुकसान पहुँचा सकती हैं
      जब तक कुछ खास conditions पूरी न हों, तब तक exploitable न बनने वाली weaknesses लगभग हमेशा मौजूद रहती हैं। Pwn2Own जैसी competitions में भी कई vulnerabilities को जोड़कर आखिर device takeover किया जाता है, और वे अक्सर सालों तक patch न होकर रह जाती हैं। researchers impact maximize करने के लिए ऐसी weaknesses को लंबे समय तक जमा करके भी रखते हैं
      दुख की बात है, लेकिन reality यही है
    • security कहावत के हिसाब से: POC || GTFO
    • खरीदार result के लिए पैसे देते हैं। vendors chain की अलग-अलग links के लिए भी पैसे देते हैं

  • OpenSSH release notes: https://www.openssh.com/txt/release-9.8
    जो लोग upgrade नहीं कर सकते या नहीं करना चाहते, उनके लिए minimal patch: https://marc.info/?l=oss-security&m=171982317624594&w=2

    • “64-bit systems पर exploitation भी संभव माना जाता है, लेकिन इस समय तक prove नहीं हुआ है”