OpenBSD ની W^X સુરક્ષા મિકેનિઝમને મજબૂત બનાવવાની યોજના

થિયો ડી રાડટ વહેંચાયેલું W^X (Write XOR Execute) મેમરી પ્રોટેક્શન મિકેનિઝમને મજબૂત કરવાની યોજના ધરાવે છે. મિકેનિઝમનો સાર એ છે કે પ્રક્રિયા મેમરી પૃષ્ઠો એક સાથે લેખન અને અમલ માટે ઍક્સેસ કરી શકાતા નથી. આમ, લખાણ અક્ષમ કર્યા પછી જ કોડ એક્ઝિક્યુટ થઈ શકે છે, અને એક્ઝેક્યુશન ડિસેબલ કર્યા પછી જ મેમરી પેજ પર લખવાનું શક્ય છે. W^X મિકેનિઝમ યુઝર-સ્પેસ એપ્લીકેશનને સામાન્ય બફર ઓવરફ્લો હુમલાઓથી સુરક્ષિત કરવામાં મદદ કરે છે, જેમાં સ્ટેક ઓવરફ્લોનો સમાવેશ થાય છે અને OpenBSDમાં સક્રિય છે. મૂળભૂત.

W^X પર કામની શરૂઆતથી, તે સ્પષ્ટ હતું કે આ એક લાંબો રસ્તો હતો, કારણ કે JIT નો ઉપયોગ કરીને નોંધપાત્ર સંખ્યામાં અરજીઓ આવી હતી. JIT અમલીકરણને ત્રણ કેટેગરીમાં વિભાજિત કરી શકાય છે:

• સિસ્ટમ કૉલની "ખર્ચ" સ્વીકારીને, W અને X સ્ટેટ્સ વચ્ચે મેમરી સ્વિચ કરવી mprotect.
• સમાન મેમરીના ડબલ્યુ અને એક્સ મેપિંગની જોડી વચ્ચે ઉપનામો બનાવવું.
• સૌથી વધુ "ગંદા" વિકલ્પને W|X મેમરી મોડલની જરૂર છે જે એકસાથે રેકોર્ડિંગ અને એક્ઝેક્યુશનને મંજૂરી આપે છે.

હાલમાં, ત્રીજા વિકલ્પનો ઉપયોગ કરીને નોંધપાત્ર રીતે ઓછા પ્રોગ્રામ્સ છે અને પ્રથમ અને બીજાનો ઉપયોગ કરીને વધુ. જો કે, W|X JIT (મુખ્યત્વે ક્રોમિયમ અને ઇરિડમ) સાથે પ્રોગ્રામ્સ ચલાવવા જરૂરી હોવાથી, "wxallowed" ફાઇલસિસ્ટમ માઉન્ટ વિકલ્પ ઉમેરવામાં આવ્યો હતો, જે મેમરીનો ઉપયોગ લેખન અને એક્ઝેક્યુશન બંને માટે એકસાથે કરવાની મંજૂરી આપે છે, જો એક્ઝિક્યુટેબલ ELF. ફાઇલને "wxneeded" માર્કર સાથે ચિહ્નિત કરવામાં આવે છે, અને એપ્લિકેશનો પોતે જ મિકેનિઝમ્સનો ઉપયોગ કરીને સુરક્ષિત હતી. પ્રતિજ્ઞા и અનાવરણ અનુક્રમે એપ્લિકેશન માટે ઉપલબ્ધ સિસ્ટમ કૉલ્સની સૂચિ અને ફાઇલ સિસ્ટમના ભાગોને મર્યાદિત કરવા.

આવી એપ્લિકેશન્સમાં નબળાઈઓના શોષણને વધુ જટિલ બનાવવા માટે, મિકેનિઝમમાં વધારાની દરખાસ્ત કરવામાં આવી છે. MAP_STACK, જે તપાસે છે કે શું સિસ્ટમ કૉલ લખી શકાય તેવા મેમરી પેજ પરથી એક્ઝિક્યુટ થઈ રહ્યો છે. જો પૃષ્ઠ લખી શકાય તેવું છે, તો પ્રક્રિયાને સમાપ્ત કરવાની ફરજ પાડવામાં આવે છે. આ રીતે, હુમલાખોર સિસ્ટમ કૉલ્સનો ઉપયોગ કરી શકશે નહીં અને JIT અમલીકરણમાં જરૂરી ગેજેટ્સ શોધવાનો પ્રયાસ કરવા અથવા સિસ્ટમ કૉલ સ્ટબ્સને સીધી અંદર શોધવાનું વધુ મુશ્કેલ કાર્ય કરવા માટે ફરજ પાડવામાં આવશે. આકસ્મિક રીતે લિંક થયેલ libc.

ક્રોમ/ઇરીડિયમ પ્રક્રિયાઓ પહેલેથી જ પ્રતિજ્ઞા અને અનાવરણનો ઉપયોગ કરીને તદ્દન વિશ્વસનીય રીતે સુરક્ષિત છે, પરંતુ ઉપયોગ કરવાની ક્ષમતાને દૂર કરવાથી, ઉદાહરણ તરીકે, લખવા(2) સિસ્ટમ કૉલનો દેખીતી રીતે થોડો ફાયદો છે, કારણ કે તે હુમલાખોર માટે વધારાની મુશ્કેલીઓ ઊભી કરે છે. જો કે, જો JIT અમલીકરણ W|X મેમરીમાંથી મૂળ સિસ્ટમ કૉલ્સનો ઉપયોગ કરે તો મુશ્કેલીઓ પણ ઊભી થઈ શકે છે. જો કે, આશા રાખવાનું કારણ છે કે આવું થશે નહીં, કારણ કે ABI ઘણી વખત બદલાઈ ગયું છે, પરંતુ કોઈએ ક્યારેય સમસ્યાની જાણ કરી નથી.

ઓપનબીએસડી-વર્તમાન શાખાના નિયમિત સ્નેપશોટમાં ફેરફારો પહેલેથી જ ઉપલબ્ધ છે, રસ ધરાવતા દરેકને પરીક્ષણ માટે આમંત્રિત કરવામાં આવે છે.

Chrome/Iridium માં મોડના દેખાવ વિશે સંબંધિત સમાચાર થિયો તરફથી અલગ ટિપ્પણીને પાત્ર છે JITless. તેમના દૃષ્ટિકોણથી, આ કેટલાક ઉપયોગ મોડેલો માટે સ્વીકાર્ય છે, પરંતુ કદાચ બધા માટે નહીં, કારણ કે આ મોડ દેખીતી રીતે પ્રોસેસર પરનો ભાર વધારશે. હાલમાં, જો તમે /usr/local માટે "wxallowed" ને અક્ષમ કરો તો ક્રોમ મોટે ભાગે કામ કરશે, જો કે કેટલાક એક્સ્ટેન્શન્સમાં સમસ્યા હોઈ શકે છે (ભૂતિયા એક ઉદાહરણ છે). એક રીતે અથવા બીજી રીતે, થિયોને આશા છે કે નજીકના ભવિષ્યમાં JITless મોડમાં પૂર્ણ કાર્ય પૂર્ણપણે કાર્યરત સ્થિતિમાં લાવવામાં આવશે.

સોર્સ: opennet.ru