OpenBSD యొక్క W^X భద్రతా యంత్రాంగాన్ని బలోపేతం చేయడానికి ప్రణాళికలు

థియో డి రాడ్ట్ భాగస్వామ్యం చేయబడింది W^X (రైట్ XOR ఎగ్జిక్యూట్) మెమొరీ ప్రొటెక్షన్ మెకానిజంను బలోపేతం చేయాలని యోచిస్తోంది. మెకానిజం యొక్క సారాంశం ఏమిటంటే, ప్రాసెస్ మెమరీ పేజీలను వ్రాయడం మరియు అమలు చేయడం కోసం ఏకకాలంలో యాక్సెస్ చేయబడదు. అందువల్ల, కోడ్ రాయడం నిలిపివేయబడిన తర్వాత మాత్రమే అమలు చేయబడుతుంది మరియు మెమరీ పేజీకి వ్రాయడం అనేది అమలును నిలిపివేసిన తర్వాత మాత్రమే సాధ్యమవుతుంది. స్టాక్ ఓవర్‌ఫ్లోలతో సహా సాధారణ బఫర్ ఓవర్‌ఫ్లో దాడుల నుండి యూజర్-స్పేస్ అప్లికేషన్‌లను రక్షించడంలో W^X మెకానిజం సహాయపడుతుంది మరియు OpenBSDలో సక్రియంగా ఉంటుంది అప్రమేయంగా.

W^Xపై పని ప్రారంభించినప్పటి నుండి, JITని ఉపయోగించి గణనీయమైన సంఖ్యలో అప్లికేషన్‌లు ఉన్నందున ఇది సుదీర్ఘ రహదారి అని స్పష్టమైంది. JIT అమలులను మూడు వర్గాలుగా విభజించవచ్చు:

  • W మరియు X రాష్ట్రాల మధ్య మెమరీని మార్చడం, సిస్టమ్ కాల్ యొక్క "ఖర్చు"ని అంగీకరించడం రక్షించండి.
  • ఒకే మెమరీకి చెందిన ఒక జత W మరియు X మ్యాపింగ్‌ల మధ్య మారుపేర్లను సృష్టిస్తోంది.
  • అత్యంత "డర్టీ" ఎంపికకు ఏకకాలంలో రికార్డింగ్ మరియు అమలును అనుమతించే W|X మెమరీ మోడల్ అవసరం.

ప్రస్తుతం, మూడవ ఎంపికను ఉపయోగించి చాలా తక్కువ ప్రోగ్రామ్‌లు ఉన్నాయి మరియు మొదటి మరియు రెండవ వాటిని ఉపయోగిస్తున్నాయి. అయినప్పటికీ, W|X JIT (ప్రధానంగా Chromium మరియు Iridum)తో ప్రోగ్రామ్‌లను అమలు చేయాల్సిన అవసరం ఉన్నందున, "wxallowed" ఫైల్‌సిస్టమ్ మౌంట్ ఎంపిక జోడించబడింది, ఇది ఎక్జిక్యూటబుల్ ELF అయితే, రాయడం మరియు అమలు చేయడం రెండింటికీ ఏకకాలంలో మెమరీని ఉపయోగించడానికి అనుమతించింది. ఫైల్ “wxneeded” మార్కర్‌తో గుర్తించబడింది మరియు అప్లికేషన్‌లు అదనంగా మెకానిజమ్‌లను ఉపయోగించి రక్షించబడ్డాయి ప్రతిజ్ఞ и తెరచు ఉపయోగించిన సిస్టమ్ కాల్‌ల జాబితాను మరియు అప్లికేషన్‌కు అందుబాటులో ఉన్న ఫైల్ సిస్టమ్ భాగాలను వరుసగా పరిమితం చేయడానికి.

అటువంటి అనువర్తనాల్లో దుర్బలత్వాల దోపిడీని మరింత క్లిష్టతరం చేయడానికి, యంత్రాంగానికి అదనంగా ప్రతిపాదించబడింది MAP_STACK, ఇది సిస్టమ్ కాల్ రైటబుల్ మెమరీ పేజీ నుండి అమలు చేయబడుతుందో లేదో తనిఖీ చేస్తుంది. పేజీ వ్రాయగలిగితే, ప్రక్రియను ముగించవలసి వస్తుంది. ఈ విధంగా, దాడి చేసే వ్యక్తి సిస్టమ్ కాల్‌లను ఉపయోగించుకోలేరు మరియు JIT అమలులో అవసరమైన గాడ్జెట్‌లను కనుగొనడానికి ప్రయత్నించవలసి వస్తుంది లేదా సిస్టమ్ కాల్ స్టబ్‌లను నేరుగా లోపల గుర్తించే మరింత కష్టమైన పనిని కూడా చేయవలసి వస్తుంది. అనుకోకుండా libc లింక్ చేయబడింది.

Chrome/Iridium ప్రక్రియలు ఇప్పటికే ప్రతిజ్ఞ మరియు అన్‌వెయిల్‌ని ఉపయోగించి చాలా విశ్వసనీయంగా రక్షించబడ్డాయి, అయితే ఉపయోగించగల సామర్థ్యాన్ని తీసివేయడం, ఉదాహరణకు, రైట్(2) సిస్టమ్ కాల్‌కు కొంత ప్రయోజనం ఉంటుంది, ఎందుకంటే ఇది దాడి చేసేవారికి అదనపు ఇబ్బందులను సృష్టిస్తుంది. అయినప్పటికీ, JIT అమలు W|X మెమరీ నుండి స్థానిక సిస్టమ్ కాల్‌లను ఉపయోగిస్తే కూడా ఇబ్బందులు తలెత్తవచ్చు. అయితే, ABI అనేక సార్లు మార్చబడినందున, ఇది అలా ఉండదని ఆశించడానికి కారణం ఉంది, కానీ ఎవరూ సమస్యలను నివేదించలేదు.

OpenBSD-ప్రస్తుత శాఖ యొక్క సాధారణ స్నాప్‌షాట్‌లలో మార్పులు ఇప్పటికే అందుబాటులో ఉన్నాయి, ఆసక్తి ఉన్న ప్రతి ఒక్కరూ పరీక్షించడానికి ఆహ్వానించబడ్డారు.

Chrome/Iridiumలో మోడ్ యొక్క రూపానికి సంబంధించిన సంబంధిత వార్తలు థియో నుండి ప్రత్యేక వ్యాఖ్యకు అర్హమైనవి JITలెస్. అతని దృక్కోణం నుండి, ఇది కొన్ని వినియోగ నమూనాలకు ఆమోదయోగ్యమైనది, కానీ బహుశా అందరికీ కాదు, ఎందుకంటే ఈ మోడ్ ప్రాసెసర్‌పై లోడ్‌ని స్పష్టంగా పెంచుతుంది. ప్రస్తుతం, మీరు /usr/local కోసం "wxallowed"ని నిలిపివేస్తే Chrome ఎక్కువగా పని చేస్తుంది, అయితే కొన్ని పొడిగింపులతో సమస్యలు ఉండవచ్చు (ఘోస్టరీ ఒక ఉదాహరణ). ఒక మార్గం లేదా మరొకటి, JITless మోడ్‌లో పూర్తి స్థాయి పనిని సమీప భవిష్యత్తులో పూర్తి కార్యాచరణ స్థితికి తీసుకురావాలని థియో భావిస్తున్నారు.

మూలం: opennet.ru

ఒక వ్యాఖ్యను జోడించండి