त्यांनी फेडोरा एससीपी प्रोटोकॉलचा अवमूल्यन आणि काढून टाकण्याचा प्रस्ताव ठेवला आहे

जाकुब जेलेन (रेड हॅट सुरक्षा अभियंता) सुचवले की एससीपी प्रोटोकॉल अप्रचलित म्हणून वर्गीकृत केले जावे नंतर त्याचे निर्मूलन करण्यासाठी पुढे जाणे. म्हणून एससीपी वैचारिकदृष्ट्या आरसीपीच्या जवळ आहे आणि आर्किटेक्चरल समस्येचा वारसा आहे मूलभूत तत्त्वे जी संभाव्य असुरक्षांचे स्रोत आहेत.

विशेषतः, एससीपी आणि आरसीपीमध्ये सर्व्हर क्लायंटला कोणत्या फायली आणि निर्देशिका पाठवायच्या याचा निर्णय स्वीकारतो आणि क्लायंट सर्व्हरच्या सूचना पाळतो आणि परत आलेल्या ऑब्जेक्ट नावेची शुद्धता केवळ तपासतो.

आक्रमणकर्त्याद्वारे नियंत्रित सर्व्हरशी कनेक्ट करून, सर्व्हर अन्य फायली वितरीत करू शकतो, ज्यामुळे वारंवार असुरक्षा ओळखण्याची वेळ आली आहे.

उदाहरणार्थ, अलीकडे पर्यंत, क्लायंटने केवळ चालू निर्देशिका तपासली, परंतु सर्व्हरने वेगळ्या नावाची फाइल जारी केली आणि विनंती न केलेल्या फाइल्स अधिलिखित करू शकतील हे लक्षात घेतले नाही (उदाहरणार्थ, "test.txt" ऐवजी विनंती केली, सर्व्हर ». bashrc called नावाची फाईल पाठवू शकते आणि ती क्लायंटद्वारे लिहिली जाईल).

जकूब जेलन यांनी प्रकाशित केलेल्या पोस्टमध्ये आपण खालील वाचू शकता:

नमस्कार फेडोरा वापरकर्त्यांनो! अलिकडच्या वर्षांत, एससीपी प्रोटोकॉलमध्ये बर्‍याच समस्या उद्भवल्या आहेत, ज्यामुळे आम्हाला प्रारंभिक टप्प्यात यातून सुटका मिळू शकेल की नाही यावर चर्चा होऊ शकते.

बहुतेक व्हॉईस म्हणाले की ते एससीपीचा वापर प्रामुख्याने सोप्या अ‍ॅड-हॉक प्रतींसाठी करतात आणि कारण एसएफटीपी युटिलिटी एक किंवा दोन फाईल्स पुढे आणि पुढे कॉपी करण्यासाठी एक साधा इंटरफेस देत नाही आणि कारण लोक एसएफटीपीऐवजी फक्त एससीपी लिहिण्यासाठी वापरतात.

एससीपी प्रोटोकॉलमध्ये आणखी एक समस्या म्हणजे वितर्क प्रक्रिया वैशिष्ट्य.

त्याचा उल्लेख असल्याने बाह्य सर्व्हरवर फायली कॉपी करताना फाईल पथ scp कमांडच्या शेवटी जोडला जातो स्थानिक, उदाहरणार्थ, जेव्हा आपण सर्व्हरवर «scp / स्त्रोत फाईल रिमोट सर्व्हर: 'टच / tmp / exploit.sh` / targetfile' command कमांड चालवितो,» स्पर्श / tmp / exploit.sh command आदेश होते आणि फाइल / tmp होती /exploit.sh तयार केले, म्हणूनच scp मधे योग्य एस्केप अक्षरे वापरणे महत्वाचे आहे.

जेव्हा फाईल नावांमध्ये 'character' वर्ण स्वीकारणार्‍या फाईल सिस्टीममध्ये एससीपीचा डिरेक्टरी सामग्री ("-r" पर्याय) पुनरावृत्तीसाठी वापरली जाते, तेव्हा आक्रमणकर्ता अ‍ॅस्ट्रोटॉर्फसह एक फाईल तयार करू शकतो आणि त्यास चालविण्यासाठी कोड बनवू शकतो.

ओपनएसएचमध्ये ही समस्या अद्यापही दुरुस्त केलेली नाही, बॅकवर्ड सुसंगतता न सोडता त्याचे निराकरण करणे त्रासदायक आहे, उदाहरणार्थ निर्देशिका कॉपी करण्यापूर्वी कमांड्स अस्तित्त्वात आहेत का ते तपासण्यासाठी कमांड चालू करणे.

मागील चर्चा दर्शविते की scp सहसा एका सिस्टमवरून दुसर्‍या सिस्टमवर फायली कॉपी करण्यासाठी वापरली जाते.

तथापि, बरेच लोक सोप्या इंटरफेसमुळे एसएफटीपीऐवजी एसकेपी वापरतात आणि फायली कॉपी करणे अगदी स्पष्ट आहे किंवा सवयीशिवाय. जाकब एसपीपी युटिलिटीची डीफॉल्ट अंमलबजावणी, एसएफटीपी प्रोटोकॉल वापरण्यासाठी रूपांतरित (काही विशिष्ट प्रकरणांसाठी युटिलिटी "एसएमपी प्रोटोकॉलवर परत जाण्यासाठी" -M स्कॅप "पर्याय प्रदान करते) किंवा एसएफटीपी युटिलिटीमध्ये सुसंगतता मोड समाविष्ट करण्यास सूचविते. जे तुम्हाला एसकेपीचा एसपीपी वापरण्याची परवानगी देते.

काही महिन्यांपूर्वी मी एसपीटीपी आंतरिकरित्या वापरण्यासाठी स्कॅपसाठी एक पॅच लिहिले (एम-स्कॅप वापरुन ते परत बदलण्याची शक्यता आहे) आणि काही चाचण्यांमध्ये यशस्वीरित्या चालविली.

एकूणच अपस्ट्रीम अभिप्राय देखील खूप सकारात्मक होता, म्हणून मला आमच्या वापरकर्त्यांकडून देखील ऐकायला आवडेल. त्यास अद्याप काही मर्यादा आहेत (समर्थन गहाळ आहे, सर्व्हर एसएफटीपी उपप्रणाली न चालवल्यास हे कार्य करणार नाही,…), परंतु बहुतेक सामान्य वापर प्रकरणांमध्ये ते चांगले असावे.

मर्यादा दरम्यान प्रस्तावित पध्दतीचा, एसएफटीपी सबसिस्टम सुरू न करणार्‍या सर्व्हर्ससह डेटाची देवाणघेवाण अशक्यतेचा उल्लेख केला आहे, आणि स्थानिक होस्ट ("-3" मोड) द्वारे संक्रमण असलेल्या दोन बाह्य यजमानांमधील स्थानांतर मोडची अनुपस्थिती. काही वापरकर्त्यांनी हे देखील लक्षात ठेवले आहे की बँडविड्थच्या बाबतीत एसएफटीपी एससीपीच्या तुलनेत किंचित मागे आहे, जे उच्च विलंब असलेल्या खराब कनेक्शनवर अधिक लक्षणीय बनते.

चाचणीसाठी, एसपीटीपी प्रोटोकॉलवर स्कॅप युटिलिटीच्या अंमलबजावणीसह पॅचिंग करुन, कॉपर रेपॉजिटरीमध्ये आधीपासूनच वैकल्पिक ओपनशॅश पॅकेज ठेवलेले आहे.

स्त्रोत: https://lists.fedoraproject.org/