ఆరోరా మొబైల్ ఆపరేటింగ్ సిస్టమ్ (ఓపెన్ మొబైల్ ప్లాట్ఫామ్ కంపెనీ అభివృద్ధి చేసిన సెయిల్ఫిష్ ఓఎస్ యొక్క ఫోర్క్) డెవలపర్లు, తొలగించడం గురించి ఒక ఉదాహరణాత్మక కథను పంచుకున్నారు. (Glibc లోని ఒక లోపం, ఇది కేవలం ARMv7 ప్లాట్ఫారమ్లో మాత్రమే కనిపిస్తుంది. ఈ లోపాన్ని మే నెలలోనే వెల్లడించారు, కానీ ఇటీవల వరకు దానికి పరిష్కారం అందుబాటులోకి రాలేదు. అధిక స్థాయి ప్రమాదం మరియు memcpy() మరియు memmove() ఫంక్షన్లలో ప్రత్యేకంగా ఫార్మాట్ చేయబడిన డేటాను ప్రాసెస్ చేస్తున్నప్పుడు కోడ్ ఎగ్జిక్యూషన్కు అనుమతించే ఒక ఎక్స్ప్లాయిట్ యొక్క వర్కింగ్ ప్రోటోటైప్. ప్యాకేజీ పరిష్కారాలు и ఇంకా విడుదల కాలేదు మరియు దానిని బహిరంగంగా వెల్లడించిన దాదాపు రెండు నెలల తర్వాత మరియు Glibc డెవలపర్లకు తెలియజేసిన ఐదు నెలల తర్వాత కూడా ఆ లోపానికి ప్యాచ్ చేయలేదు.
ARMv7 కోసం memcpy() మరియు memmove() యొక్క అసెంబ్లీ లాంగ్వేజ్ ఇంప్లిమెంటేషన్లో ఈ లోపం బయటపడింది మరియు కాపీ చేయబడిన ప్రాంతం యొక్క పరిమాణాన్ని నిర్ధారించే పారామీటర్ యొక్క ప్రతికూల విలువలను తప్పుగా నిర్వహించడం దీనికి కారణం. కంపెనీలు ప్యాచ్ డెవలప్మెంట్తో సమస్యలను ప్రారంభించాయి. и వారు 32-బిట్ ARMv7 సిస్టమ్ల కోసం బిల్డ్ చేయనందున, తమ ప్లాట్ఫారమ్లు ఈ సమస్య వల్ల ప్రభావితం కాలేదని ప్రకటించి, ప్యాచ్కు సహకరించడానికి నిరాకరించారు. అనేక ఎంబెడెడ్ డిస్ట్రిబ్యూషన్ల డెవలపర్లు స్పష్టంగా Glibc బృందంపై ఆధారపడ్డారు మరియు వారు కూడా ప్యాచ్కు చురుకుగా సహకరించలేదు.
ఎంపిక హువావే దాదాపు వెంటనే ఈ సమస్యను నివారించడానికి ఒక పరిష్కారాన్ని ప్రతిపాదించింది, సైన్డ్ ఆపరేండ్లను (bge మరియు blt) నిర్వహించే అసెంబ్లీ సూచనలను అన్సైన్డ్ సమానమైన వాటితో (blo మరియు bhs) భర్తీ చేయడానికి ప్రయత్నించింది. Glibc నిర్వహకులు వివిధ లోప పరిస్థితులను తనిఖీ చేయడానికి ఒక పరీక్షల సమితిని అభివృద్ధి చేశారు, ఆ తర్వాత హువావే యొక్క ప్యాచ్ అనుచితమైనదని మరియు సాధ్యమయ్యే అన్ని ఇన్పుట్ డేటా కలయికలను నిర్వహించలేదని స్పష్టమైంది.
ఆరోరా OSకు ARM కోసం 32-బిట్ బిల్డ్ ఉన్నందున, దాని డెవలపర్లు ఆ దుర్బలత్వాన్ని స్వయంగా ప్యాచ్ చేసి, కమ్యూనిటీకి ఒక పరిష్కారాన్ని అందించాలని నిర్ణయించుకున్నారు. వివిధ ఇన్పుట్ ఆర్గ్యుమెంట్లను పరిగణనలోకి తీసుకుంటూ, ఆ ఫంక్షన్కు సమర్థవంతమైన అసెంబ్లీ ఇంప్లిమెంటేషన్ను రాయడమే ఇక్కడ సవాలుగా ఉంది. ఆ ఇంప్లిమెంటేషన్ను అన్సైన్డ్ ఇన్స్ట్రక్షన్లను ఉపయోగించి తిరిగి రాశారు. అది చిన్న సమస్యే అయినా, అన్ని రకాల ఇన్పుట్ విలువల కలయికలతో అనుకూలతను కొనసాగిస్తూనే, అమలు వేగాన్ని నిలబెట్టడం మరియు memcpy, memmove ఫంక్షన్ల పనితీరు క్షీణతను తొలగించడమే ప్రధాన సమస్యగా ఉంది.
జూన్ ప్రారంభంలో, Glibc నిర్వహకుల పరీక్షా ఫ్రేమ్వర్క్ మరియు అరోరా యొక్క అంతర్గత పరీక్షా సూట్ను దాటిన రెండు ప్యాచ్ వేరియంట్లు సిద్ధం చేయబడ్డాయి. జూన్ 3న, ఆ వేరియంట్లలో ఒకటి ఎంపిక చేయబడింది మరియు Glibc మెయిలింగ్ జాబితాకు. ఒక వారంలో
ఇది ఇదే విధమైన విధానంతో కూడిన మరో ప్యాచ్, హువావే గతంలో పరిష్కరించడానికి ప్రయత్నించిన మల్టీఆర్చ్ ఇంప్లిమెంటేషన్లోని ఒక సమస్యను పరిష్కరించింది. దీనిని పరీక్షించడానికి ఒక నెల పట్టింది మరియు ప్యాచ్ యొక్క ప్రాముఖ్యత కారణంగా.
జూలై 8 సవరణలు రాబోయే glibc 2.32 విడుదల యొక్క ప్రధాన బ్రాంచ్లోకి. ఈ అమలులో రెండు ప్యాచ్లు ఉన్నాయి: ARMv7 కోసం memcpy యొక్క మల్టీఆర్చ్ ఇంప్లిమెంటేషన్ కొరకు, మరియు ARM కోసం memcpy() మరియు memmove() యొక్క సాధారణ అసెంబ్లీ ఇంప్లిమెంటేషన్ కొరకు.
ఈ సమస్య లక్షలాది ARMv7 పరికరాలను ప్రభావితం చేస్తుంది Linux సరైన అప్డేట్ లేకుండా, యజమానులు వాటిని నెట్వర్క్కు కనెక్ట్ చేయడం ద్వారా ప్రమాదం తెచ్చుకుంటారు (పరిమాణ పరిమితులు లేకుండా ఇన్పుట్ డేటాను స్వీకరించే నెట్వర్క్-యాక్సెస్ చేయగల సేవలు మరియు అప్లికేషన్లపై దాడి చేయవచ్చు). ఉదాహరణకు, ఈ లోపాన్ని కనుగొన్న పరిశోధకులు సిద్ధం చేసిన ఎక్స్ప్లాయిట్, చాలా పెద్ద GET రిక్వెస్ట్ను పంపడం ద్వారా వాహనం యొక్క ఇన్ఫర్మేషన్ సిస్టమ్లో అంతర్నిర్మితంగా ఉన్న HTTP సర్వర్పై ఎలా దాడి చేయాలో మరియు సిస్టమ్కు రూట్ యాక్సెస్ను ఎలా పొందాలో చూపిస్తుంది.
మూలం: opennet.ru
