क्या मैं अपने पर्यावरण चर पर भरोसा कर सकता हूं?

Question

मैं bash में उपयोगिता का संग्रह लिख रहा हूं जिसमें एक सामान्य पुस्तकालय है। मेरे द्वारा लिखे गए प्रत्येक स्क्रिप्ट में कोड का एक ब्लॉक होना चाहिए जो निष्पादन योग्य से संबंधित लाइब्रेरी का पथ निर्धारित करता है। नहीं वास्तविक कोड है, लेकिन एक उदाहरण:

#!/bin/bash 

DIR="$(cd -P "$(dirname "${BASH_SOURCE[0]}")" && pwd)" 
. $DIR/../lib/utilities/functions 

एक प्रस्तावना है कि पुस्तकालय के लिए खोज करने की कोशिश करता है के बजाय

, मैं उज्जवल विचार पुस्तकालयों स्थान इंगित करने के लिए एक वातावरण चर का उपयोग करने के लिए किया था।

#!/bin/bash 

. $TOOLS_LIBRARY_PATH 

मैं उस पर्यावरण चर सेट करने के लिए एक रैपर प्रोग्राम का उपयोग कर सकता हूं, या मैं इसे अपने पथ में सेट कर सकता हूं। bash टूलसेट को व्यवस्थित करने के बेहतर तरीके हो सकते हैं, लेकिन सवाल यह है:

क्या मैं अपने पर्यावरण चर पर भरोसा कर सकता हूं?

यह उन लोगों में से एक है, मैंने कभी-कभी-कभी-कभी-कभी-इस तरह के प्रश्नों के बारे में सोचा नहीं है। अन्य भाषाओं में प्रोग्रामिंग करते समय, पुस्तकालयों को खोजने के लिए पथ का उपयोग किया जाता है, (उदाहरण के लिए LD_LIBRARY_PATH, PYTHONPATH, PERLLIB, RUBYLIB, CLASSPATH, NODE_PATH), लेकिन मुझे कभी भी रोकना नहीं था और यह कैसे असुरक्षित हो सकता था इसके बारे में सोचना पड़ा।

वास्तव में, LD_LIBRARY_PATH में Why LD_LIBRARY_PATH is bad है जिसका उपयोग इसके उपयोग को हतोत्साहित करने के लिए किया गया है। रूबी और पर्ल लाइब्रेरी पथ पर्यावरण चर को अनदेखा किया जाता है यदि उनके सुरक्षा तंत्र का उपयोग किया जाता है, $SAFE और -T (taint mode) क्रमशः।

मेरे विचार अब तक ...

• उपयोगकर्ता अपनी पसंद के एक पुस्तकालय के लिए TOOLS_PATH_LIBRARY सेट कर सकते हैं, लेकिन उपयोगिता उनके यूआईडी के तहत चलाया जाएगा। वे आसानी से bash के साथ अपनी दुर्भावनापूर्ण लाइब्रेरी चला सकते थे।
• मेरे उपकरण sudo कुछ चीजें। कोई भी इसका TOOLS_PATH_LIBRARY सेट कर सकता है जो इसका लाभ उठाता है। लेकिन, उपकरण sudo के माध्यम से नहीं चलाए जाते हैं, वे केवल sudo को यहां और वहां आमंत्रित करते हैं। किसी भी मामले में उपयोगकर्ता को sudoer होना होगा, वे सीधे sudo पर कॉल कर सकते हैं।
• यदि मैं TOOLS_PATH_LIBRARY पर भरोसा नहीं कर सकता, तो मैं PATH पर भरोसा नहीं कर सकता। सभी प्रोग्राम आमंत्रणों को पूर्ण पथ का उपयोग करना चाहिए।
• मैंने शैल प्रोग्राम को पूर्ण प्रोग्राम के लिए उपनाम का उपयोग किया है, ताकि ls पर कॉल करने के बजाय, LS=/bin/ls जैसे चर का उपयोग करें। जो मैंने पढ़ा है, उससे यह उपयोगकर्ताओं के खिलाफ एलियास के रूप में प्रोग्राम डिफ़ॉल्ट को फिर से परिभाषित करने के खिलाफ है। देखें: PATH, functions and security. Bash scripting best practices. ।
• पर्ल का taint mode सभी पर्यावरण चरों को "दांतेदार" के रूप में मानता है, जो फोरबोडिंग है, यही कारण है कि मैं पर्यावरण के जोखिमों के बारे में तर्क करने की कोशिश कर रहा हूं।
• एक उपयोगकर्ता के लिए किसी और के पर्यावरण को बदलने के लिए यह संभव नहीं है, जब तक वह उपयोगकर्ता रूट न हो। इस प्रकार, मैं केवल विशेषाधिकारों को बढ़ाने के लिए अपने पर्यावरण को बदलने वाले उपयोगकर्ता के बारे में चिंतित हूं। देखें: Is there a way to change another process's environment variables?

मैं rubber ducked इस तरह की है एक जवाब में, लेकिन मैं अभी भी है क्योंकि यह एक पैट जवाब नहीं है, यह पोस्ट करने के लिए, जा रहा हूँ।

अद्यतन: पुस्तकालयों और निष्पादन योग्य पथों को निर्दिष्ट करने के लिए पर्यावरण चर के उपयोग के आसपास सुरक्षा समस्याएं क्या हैं?

Answer 1

लघु जवाब:

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

---

लंबे समय तक जवाब:

कम से कम दो अलग-अलग मुद्दों पर विचार करने के हैं सुरक्षा की समस्याओं के संदर्भ में:

• क्या और जिसे हम से सुरक्षा के लिए की जरूरत है?
  • (बारीकी से संबंधित सवाल: क्या हमारे कार्यक्रम वास्तव में क्या कर सकते हैं और यह संभावित रूप से क्या तोड़ सकता है?)
• हम ऐसा कैसे कर सकता हूँ?

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

इस स्थिति में, उपयोगकर्ता प्रोग्राम को करने में कुछ भी कर सकता है, वे उपकरण की सहायता के बिना भी कर सकते हैं, इसलिए इस उपयोगकर्ता द्वारा हमलों के खिलाफ "सुरक्षा" करने की कोशिश कर रहा है। आपका विवरण इस तरह नहीं पढ़ता है कि आपको वास्तव में हमलों के खिलाफ किसी भी सुरक्षा की आवश्यकता होगी।

मान लिया जाये कि आप सुरक्षा की जरूरत है, तो आप बस वातावरण चर पर भरोसा नहीं कर सकते हैं - और अगर आप LD_LIBRARY_PATH और LD_PRELOAD, यहां तक ​​कि /bin/id या /bin/ls की तरह निरपेक्ष पथ के साथ उपकरण बुला तरह बातें पुनर्स्थापित करने के लिए असफल आप एक विश्वसनीय जवाब नहीं देंगे , जब तक कि उपकरण स्थिर रूप से संकलित नहीं होता है। यही कारण है कि sudo में env_reset डिफ़ॉल्ट रूप से सक्षम है और क्यों चल रहे शुष्क कार्यक्रमों को कुछ पर्यावरण चर को अनदेखा करना है। ध्यान दें कि इसका मतलब है कि TOOLS_PATH_LIBRARY और PATH आपकी स्थिति में भी भरोसेमंद हो सकता है, लेकिन अन्य परिस्थितियों के सीमा मामलों में यह सच नहीं है: sudo उपयोग के लिए रीसेट कर सकता है, लेकिन गैर-मानक पर्यावरण चर के माध्यम से।

जैसा ऊपर बताया गया है, argv[0] (या इसके बैश समकक्ष ${BASH_SOURCE[0]}) पर्यावरण चर से अधिक विश्वसनीय नहीं है। न केवल उपयोगकर्ता आपकी मूल फ़ाइल की प्रतिलिपि या सिमलिंक बना सकता है; execve या bash's exec -a foo barargv[0] में कुछ भी डालने की अनुमति देता है।

Answer 2

जबकि पर्यावरण चर के संशोधन को रोकने के लिए विभिन्न कार्यक्रमों में तंत्र मौजूद हैं, नीचे की रेखा है, नहीं, आप पर्यावरण चर पर भरोसा नहीं कर सकते हैं। सुरक्षा चिंता बहुत बुनियादी है:

जब भी कोई उपयोगकर्ता निष्पादित होने की अपेक्षा की जा सकती है, तो किसी भी समय शोषण करने की भेद्यता की संभावना उत्पन्न होती है।

केस-इन-पॉइंट, CVE-2010-3847 पर एक नज़र डालें। इसके साथ, एक सेटविइड या सेटजीड बाइनरी वाली फ़ाइल सिस्टम में लेखन पहुंच के साथ एक वंचित हमलावर अपने अधिकारों को बढ़ाने के लिए इस दोष का उपयोग कर सकता है। इसमें उपयोगकर्ता द्वारा संशोधित वातावरण चर शामिल है।

CVE-2011-1095 एक और उदाहरण है, और इसमें SUID बाइनरी शामिल नहीं है। लोगों को पर्यावरण परिवर्तनीय संशोधनों के साथ करने में सक्षम थे कि सामान के प्रकार देखने के लिए "glibc cve पर्यावरण" के लिए एक Google खोज करें। बहुत चालाक

आपका चिंताओं वास्तव में के अपने बयान के लिए नीचे उबाल:

उपयोगकर्ता अपनी पसंद के एक पुस्तकालय के लिए TOOLS_PATH_LIBRARY सेट कर सकते हैं, लेकिन उपयोगिता उनके यूआईडी के तहत चलाया जाएगा। वे आसानी से बैश के साथ अपनी दुर्भावनापूर्ण लाइब्रेरी चला सकते थे।

यहां मुख्य वाक्यांश - अपनी दुर्भावनापूर्ण लाइब्रेरी चलाएं। यह मानता है कि उनकी लाइब्रेरी का स्वामित्व उनके यूआईडी के पास भी है।

यह वह जगह है जहां एक सुरक्षा ढांचा आपको बहुत अच्छा करेगा। एक यह है कि मैं लिखा है कि इस समस्या पर विशेष रूप से केंद्रित है तुम यहाँ पा सकते हैं:

https://github.com/cormander/tpe-lkm

मॉड्यूल बंद हो जाता है execve/mmap/mprotect फ़ाइलों को लिखने योग्य, या एक विश्वसनीय उपयोगकर्ता (रूट) के स्वामित्व में नहीं हैं पर कॉल । जब तक वे विश्वसनीय उपयोगकर्ता द्वारा स्वामित्व वाली फ़ाइल/निर्देशिका में दुर्भावनापूर्ण कोड डालने में सक्षम नहीं होते हैं, तब तक वे इस तरह से सिस्टम का फायदा नहीं उठा सकते हैं।

यदि आप SUID बाइनरी या सूडो का उपयोग कर रहे हैं जिसमें वे चर शामिल हैं, तो आप गैर-मूल स्वामित्व वाली बाइनरी पर भरोसा करने से भी रूट को रोकने के लिए "परावर्तक" और "सख्त" विकल्पों को सक्षम करने पर विचार करना चाहेंगे।

मुझे यह उल्लेख करना चाहिए कि यह विश्वसनीय पथ निष्पादन विधि द्विआधारी और साझा पुस्तकालयों के साथ प्रत्यक्ष निष्पादन की रक्षा करती है। यह व्याख्या की गई भाषाओं के खिलाफ बहुत कम (यदि कुछ भी) करता है, क्योंकि वे बाइटकोड का विश्लेषण करते हैं और इसे सीधे निष्पादित नहीं करते हैं। तो आपको अभी भी PYTHONPATH, PERLLIB, CLASSPATH आदि के साथ कुछ डिग्री की देखभाल की आवश्यकता है और आपके द्वारा उल्लिखित भाषा की सुरक्षा तंत्र का उपयोग करें।

Answer 3

आप किसी और के पर्यावरण पर कभी भरोसा नहीं कर सकते।

क्यों न केवल एक नया उपयोगकर्ता बनाएं जिसमें यह सभी महत्वपूर्ण कोड शामिल है। फिर, आप या तो सीधे /etc/passwd से जानकारी प्राप्त कर सकते हैं या उपयोगकर्ता की होम निर्देशिका खोजने के लिए ~foo वाक्यविन्यास का उपयोग कर सकते हैं।

# One way to get home directory of util_user 
DIR=$(/usr/bin/awk -F: '$1 == "util_user" {print $6}' /etc/passwd) 

# Another way which works in BASH and Kornshell 
[ -d ~util_dir ] && DIR=~util_dir 


# Make sure DIR is set! 
if [ -z "$DIR" ] 
then 
    echo "Something's wrong!" 
    exit 
fi