क्या आप वास्तव में एक छवि फ़ाइल में ट्रोजन प्राप्त कर सकते हैं और यदि ऐसा है तो इसे कैसे निष्पादित किया जाएगा?

Question

मैंने सिर्फ एलपी के एक जोड़े को डिजीटल किया है और कुछ कवर आर्ट की जरूरत है। मेरा स्कैनर एल्बम को स्कैन करने के लिए पर्याप्त बड़ा नहीं है इसलिए मैंने नेट से छवियों को खोजा और डाउनलोड किया।

जब मैंने ऐसा किया तो अवास्ट ने बताया कि उनमें से एक में "Win32: Hupigon-ONX" ट्रोजन है और इसे तुरंत रद्द कर दिया। कोई भी चांस लेने की इच्छा न करते हुए मैंने एक अलग कॉपी डाउनलोड की, जो साफ बताई।

अब यह अवास्ट से सिर्फ एक सकारात्मक था या क्या वास्तव में jpg में ट्रोजन हो सकता है?

यदि वहाँ था तो इसे कैसे निष्पादित किया जाएगा?

मुझे यह स्वीकार करना चाहिए कि ट्रोजन और वायरस के इस पहलू ने मुझे हमेशा प्रभावित किया है। एक सॉफ्टवेयर डेवलपर के रूप में मैंने हमेशा सरणियों की लंबाई आदि की जांच की है, इसलिए मैं नहीं देखता कि बफर ओवररन जैसी चीजें क्यों होनी चाहिए। मैं समझता हूं कि लोग कोनों को काटते हैं और गलतियां करते हैं और यदि सॉफ्टवेयर जटिल है तो ये त्रुटियां खिसक सकती हैं।

Answer 1

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

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

आधुनिक सीपीयू में एक सुरक्षा है जो कोड का समर्थन करने पर इनमें से अधिकांश कारनामों को रोक देता है। यह प्रोग्राम / लाइब्रेरी द्वारा यह स्पष्ट रूप से चिह्नित करता है कि इसके कौन से पृष्ठ डेटा हैं और कौन से कोड हैं - CPU तब एक अपवाद बढ़ाएगा यदि डेटा (जैसे छवि डेटा) में कुछ भी कोड के रूप में निष्पादित करने का प्रयास करता है। IIRC विस्टा और इसके बाद के संस्करण और .Net के सभी संस्करणों ने अपने सभी पुस्तकालयों को इस सुरक्षा का समर्थन करने के लिए फिर से जिग किया है, और यह अन्य ओएस द्वारा भी समर्थित है, लेकिन यह ऐसे सभी कारनामों को नहीं रोकता है और केवल तभी काम करता है यदि स्पष्ट रूप से चालू हो (अन्यथा) बहुत पुराना कोड टूट जाएगा)।

Answer 2

मुझे यह स्वीकार करना चाहिए कि ट्रोजन और वायरस के इस पहलू ने मुझे हमेशा प्रभावित किया है। एक सॉफ्टवेयर डेवलपर के रूप में मैंने हमेशा सरणियों की लंबाई आदि की जांच की है, इसलिए मैं नहीं देखता कि बफर ओवररन जैसी चीजें क्यों होनी चाहिए।

खैर, वास्तविक दुनिया में आपका स्वागत है; ;-) बफर ओवरफ्लो और सी। कई भाषाओं में हो सकता है (विशेषकर सी की तरह मैनुअल मेमोरी मैनेजमेंट वाले लोगों में), और जैसा कि डेवलपर्स गलती करते हैं, वे होते हैं।

हालांकि आम तौर पर एक बफर ओवरफ्लो केवल प्रोग्राम (विभाजन उल्लंघन या समान) को क्रैश करेगा, यह एक हमलावर को कोड -> ट्रोजन सक्रिय करने की अनुमति दे सकता है।

उदाहरण के लिए:

http://www.microsoft.com/technet/security/bulletin/MS04-028.mspx

http://secunia.com/advisories/35216/

और एक स्पष्टीकरण के लिए यह कैसे कोड निष्पादन की अनुमति देता है:

/programming/460519/how-are-buffer-overflows-used-to-exploit-computers

Comments

मुझे पता है कि वे होते हैं - यह सिर्फ उन बुनियादी चेकों में से एक है जो मैंने हमेशा डेटा को संसाधित करते समय किया है - चेक मुझे डेटा के लिए पर्याप्त स्थान आवंटित / आवंटित किया गया है।

— क्रिसएफ

@ क्रिस, यह तथ्य कि आपको यह सुनिश्चित करने की आवश्यकता है कि आप जांचते हैं (जैसा कि "कंप्यूटर" के विपरीत समस्या स्वयं है।

— Zabba

@Zabba का मेरा मतलब यह था कि मैं डेटा को संसाधित करते समय "प्रोग्राम को चेक करने के लिए कोड" करता हूं।

— क्रिस ऑक्ट

Answer 3

एक शोषण था जिसने 2006 में मनमाने ढंग से कोड चलाने वाली टूटी हुई जेपीईजी लाइब्रेरी पर एक बफर ओवररन किया था। माइक्रोसॉफ्ट ने पैच को तेजी से ठीक करने के लिए जारी किया था जितना मैंने उन्हें देखा था। आपकी मशीन लगभग निश्चित रूप से असुरक्षित नहीं है और Hupigon अभी बहुत अधिक झूठी सकारात्मक उत्पन्न करता है।

http://www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?name=Win32/Hupigon

Answer 4

मुझे यह स्वीकार करना चाहिए कि ट्रोजन और वायरस के इस पहलू ने मुझे हमेशा प्रभावित किया है। एक सॉफ्टवेयर डेवलपर के रूप में मैंने हमेशा सरणियों की लंबाई आदि की जांच की है, इसलिए मैं नहीं देखता कि बफर ओवररन जैसी चीजें क्यों होनी चाहिए। मैं समझता हूं कि लोग कोनों को काटते हैं और गलतियां करते हैं और यदि सॉफ्टवेयर जटिल है तो ये त्रुटियां खिसक सकती हैं।

हो सकता है कि आप सभी पॉइंटर्स, सरणियों आदि की जांच कर रहे हों, लेकिन क्या आप सुनिश्चित हैं कि किसी भी 3-पेट्री लाइब्रेरी के सभी प्रोग्रामर (हो सकता है) (किसी दिन) ने ऐसा किया हो?

इसके लिए सबसे सरल समाधान एक फ़ाइल डाउनलोड करना होगा जैसे कि "image.jpg.exe" या वास्तविक छवि के बजाय कुछ परिचित।

अपने पीसी को संक्रमित करने के और अधिक उन्नत तरीके पहले से ही यहां वर्णित हैं (जैसे। बफर अतिप्रवाह, ...)

Comments

सच - लेकिन मैं एक्सटेंशन दिखाने के लिए फ़ोल्डर विकल्प बदलता हूं। मुझे यकीन है कि ज्ञात एक्सटेंशन को छुपाने से अधिक समस्याएं पैदा हुई हैं जो इसे हल करता है। वास्तव में मैं वास्तव में हल करता है एक समस्या के बारे में नहीं सोच सकता।

— क्रिस एफएल

पूर्ण ack - यह उन पहले विकल्पों में से एक है जिन्हें मैं सक्रिय करता हूं, जब खिड़कियों के साथ काम करते हैं

— Elvith

@ क्रिस: ठीक है, जाहिर है समस्या यह हल करती है कि अन्यथा उपयोगकर्ता गलती से किसी फ़ाइल के एक्सटेंशन को बदल सकते हैं जब वे इसका नाम बदलते हैं। यह परिचित समस्या का कारण बनता है "मेरे दस्तावेज़ का आइकन मज़ेदार दिखता है, और मैं अब इसे नहीं खोल सकता। मदद करें!" :-) (और हाँ, मैं कभी-कभी अपने परिवार के लिए तकनीकी सहायता करता हूँ)।

— 1931 को सलेके

जब आप किसी फ़ाइल का नाम बदलते हैं तो @sleske - विंडोज 7 एक्सटेंशन का चयन नहीं करता है।

— क्रिस फादर

@ क्रिस: दिलचस्प, वह नहीं जानता था। यह अलग-अलग हुआ करता था, हालांकि - कम से कम विंडोज सर्वर 2003 एक नाम बदलने के लिए पूरे नाम का चयन करता है। और किसी भी दर पर, यदि उपयोगकर्ता एक्सटेंशन को संपादित कर सकते हैं, तो वे :-)।

— सेलेक