एक PHP/अपाचे/लिनक्स संदर्भ में, chmod 777 खतरनाक क्यों है?

Question

this question में चर्चा से प्रेरित हो सकता है, शायद एक बेवकूफ सवाल।

हमें सभी को सिखाया गया है कि 777 के अनुमति स्तर के साथ लिनक्स आधारित वेब होस्टिंग पर निर्देशिका या फ़ाइलों को छोड़ना एक बुरी चीज है, और हमेशा आवश्यकतानुसार छोटी अनुमतियों को सेट करने के लिए।

अब मैं उत्सुक हूं कि बिल्कुल विशेष रूप से एक PHP/अपाचे संदर्भ में शोषण का खतरा है।

आखिरकार, एक PHP स्क्रिप्ट फ़ाइल को बाहर से निष्पादित किया जा सकता है (यानी वेब सर्वर पर कॉल के माध्यम से, और बाद में दुभाषिया के लिए) इससे कोई फर्क नहीं पड़ता कि इसे "निष्पादन योग्य" के रूप में चिह्नित किया गया है, है ना? और यह कमांड लाइन php दुभाषिया के माध्यम से बुलाए गए फ़ाइलों पर लागू होता है, है ना?

तो 777 के साथ भेद्यता वास्तव में कहां है? क्या यह तथ्य है कि एक ही मशीन पर अन्य उपयोगकर्ता ऐसी फाइलों तक पहुंच सकते हैं जो दुनिया को लिखने योग्य बनाते हैं?

Answer 1

यहाँ एक परिदृश्य है:

1. आप एक असुरक्षित निर्देशिका है कि उपयोगकर्ताओं को अपलोड कर सकते हैं है।
2. वे दो फाइलें अपलोड करते हैं: एक शेल स्क्रिप्ट, और एक PHP फ़ाइल जिसमें system() शेल स्क्रिप्ट में कॉल करता है।
3. वे अपने ब्राउज़र में यूआरएल पर जाकर अपलोड की गई PHP स्क्रिप्ट तक पहुंचते हैं, जिससे शेल स्क्रिप्ट निष्पादित होती है।

यदि यह निर्देशिका 777 है, तो इसका मतलब है कि कोई भी (उपयोगकर्ता अपाचे सहित, जो php स्क्रिप्ट निष्पादित करेगा) इसे निष्पादित कर सकता है! यदि निष्पादन बिट उस निर्देशिका पर सेट नहीं है और संभावित रूप से निर्देशिका के अंदर फ़ाइलों को सेट किया गया है, तो ऊपर चरण 3 कुछ भी नहीं करेगा।

टिप्पणियों से संपादित करें: यह PHP फ़ाइल की अनुमतियों की कि कोई फर्क नहीं है, यह PHP फ़ाइल कि लिनक्स उपयोगकर्ता अपाचे द्वारा एक लिनक्स सिस्टम कॉल के रूप में क्रियान्वित की जाएगी अंदर system() कॉल है (या जो भी आप के रूप में चलाने के लिए सेट अपाचे है), और यह सटीक है जहां निष्पादन थोड़ा मायने रखता है।

Answer 2

यह आपकी वेबसाइट की दुर्भावनापूर्ण प्रोफ़ाइल को दुर्भावनापूर्ण गतिविधि में बहुत बढ़ा देता है क्योंकि केवल एक खाते में तोड़ना आवश्यक है।

कोई भी जो आपके सिस्टम में किसी भी लॉगिन के साथ पहुंच प्राप्त कर लेता है, वह जो भी वे आपके पृष्ठों को करना चाहते हैं, उन्हें पढ़ने के लिए बदलकर, "यह वेबसाइट वास्तव में असुरक्षित है इसलिए कृपया मुझे अपनी क्रेडिट कार्ड जानकारी दें।"

संपादित करें: (स्पष्ट करने के लिए और पता टिप्पणियां)

कई सर्वरों जीवन में एक से अधिक उद्देश्य है। वे कई सेवाएं चलाते हैं। यदि आप प्रत्येक अद्वितीय उपयोगकर्ता को निर्दिष्ट करके फ़ाइल फ़ाइलों को प्रबंधित करके एक दूसरे से सावधानीपूर्वक अलग करते हैं, तो हाँ, यदि आप किसी खाते के लिए क्रेडेंशियल्स से समझौता करते हैं तो आप अभी भी गर्म पानी में हैं, लेकिन वे जो नुकसान कर सकते हैं वह उस सेवा तक ही सीमित है । यदि आपके पास सिर्फ एक सामान्य खाता है और पूरे फ़ाइल सिस्टम को 777 पर सेट किया गया है, तो एक समझौता खाता मशीन पर सब कुछ खतरे में डाल देता है।

यदि आपका सर्वर केवल अपाचे/PHP चलाने के लिए समर्पित है और जीवन में कोई अन्य उद्देश्य नहीं देता है, और केवल एक खाता है जिसके तहत अपाचे/PHP चलाया जा रहा है, तो वह खाता समझौता करने के समान है आपके आवेदन के बिंदु से समझौता मशीन (हालांकि आपको अभी भी सिस्टम फ़ाइलों को संरक्षित और PHP को चलाने के लिए उपयोग किए गए खाते द्वारा गैर-लिखने योग्य होना चाहिए ... जो अभी भी एक व्यवस्थापक खाते/रूट के लिए संभव होना चाहिए)।

यदि वे एक फ़ाइल लिख सकते हैं, और यह निष्पादन योग्य है, तो वे इसे आपके मशीन (निष्पादन योग्य या स्क्रिप्ट) पर निष्पादित करने वाले किसी भी चीज़ में बदल सकते हैं और उसके बाद निष्पादन योग्य चलाने के लिए PHP के shell_exec का उपयोग कर सकते हैं। आप shell_exec अनुमति देने के लिए कॉन्फ़िगर नहीं कर रहे हैं, वे आपके कॉन्फ़िगरेशन को बदल सकते हैं और साथ ही

Answer 3

वहाँ कई अच्छा सामान्य कारणों के चलते अतिसूक्ष्मवाद का पालन करने के हैं, जब यह अनुरोधों पर है, लेकिन एक दीप webhost के संदर्भ में, कुछ है कि मन के लिए आसानी से आ

• एक साझा होस्टिंग मंच पर, अन्य उपयोगकर्ताओं रहे हैं अपने मेजबान को साझा करना अब आपकी लिपियों को पढ़ और लिख सकता है।
• समर्पित मेजबान पर, रूज प्रक्रियाएं पढ़ने/लिखने और गलती से आपकी फ़ाइलों को हटा सकती हैं। आइए कहें कि पृष्ठभूमि में एक कस्टम लॉगिंग प्रक्रिया चल रही है क्योंकि उपयोगकर्ता के पास कोई भी बग नहीं है जिसके परिणामस्वरूप यह rm -rf / पर आ रहा है। अब आम तौर पर यह हानिरहित होगा क्योंकि वहां कोई भी फाइल नहीं होगी जिसमें किसी को भी लिखने की अनुमति नहीं होनी चाहिए लेकिन यह रूज प्रक्रिया अब आपकी फाइलें इसके साथ ले जाएगी।
• अपनी वेबसाइट को खराब करने के लिए, किसी को भी किसी भी उपयोगकर्ता के रूप में पहुंच प्राप्त करने की आवश्यकता होती है, यहां तक ​​कि कोई भी या कुछ ऐसा डमी खाता नहीं कहता है। आम तौर पर, हमलावर को उस स्थान पर जाने के लिए आगे उपयोगकर्ता स्तर वृद्धि वृद्धि करना पड़ता है जहां वह कुछ नुकसान कर सकता है। यह एक असली खतरा है। कुछ गैर-महत्वपूर्ण सेवाएं डमी खातों के तहत चल रही हो सकती हैं और उनमें भेद्यता हो सकती है।

Answer 4

के आप एक सॉफ्टवेयर पैकेज अपने सर्वर में स्थापित किया है और वहाँ इसे में एक शून्य डे समस्या है लगता है, अपने व्यवस्थापक नियंत्रण कक्ष हमलावर एक्सेस का लाभ लेने, फ़ाइलें क्षमताओं को अपलोड आप 777 के लिए सब कुछ सेट करता है, तो यह होगा साथ उनके लिए कहीं भी एक शेल स्क्रिप्ट अपलोड करने के लिए तुच्छ। हालांकि, अगर आप अनुमतियों को सही तरीके से सेट करते हैं तो वह ऐसा नहीं कर सकता क्योंकि किसी भी/www-data/etc में लिखने की अनुमति नहीं होगी।