ഓപ്പൺബിഎസ്ഡിയുടെ W^X സുരക്ഷാ സംവിധാനം ശക്തിപ്പെടുത്താനുള്ള പദ്ധതികൾ

തിയോ ഡി റാഡ് പങ്കിട്ടു W^X (Write XOR Execute) മെമ്മറി സംരക്ഷണ സംവിധാനം ശക്തിപ്പെടുത്താൻ പദ്ധതിയിടുന്നു. പ്രോസസ്സ് മെമ്മറി പേജുകൾ എഴുതുന്നതിനും നടപ്പിലാക്കുന്നതിനും ഒരേസമയം ആക്സസ് ചെയ്യാൻ കഴിയില്ല എന്നതാണ് മെക്കാനിസത്തിന്റെ സാരം. അതിനാൽ, എഴുത്ത് പ്രവർത്തനരഹിതമാക്കിയതിനുശേഷം മാത്രമേ കോഡ് എക്സിക്യൂട്ട് ചെയ്യാൻ കഴിയൂ, കൂടാതെ എക്സിക്യൂഷൻ പ്രവർത്തനരഹിതമാക്കിയതിനുശേഷം മാത്രമേ മെമ്മറി പേജിലേക്ക് എഴുതാൻ കഴിയൂ. സ്റ്റാക്ക് ഓവർഫ്ലോകൾ ഉൾപ്പെടെയുള്ള സാധാരണ ബഫർ ഓവർഫ്ലോ ആക്രമണങ്ങളിൽ നിന്ന് ഉപയോക്തൃ-സ്പേസ് ആപ്ലിക്കേഷനുകളെ സംരക്ഷിക്കാൻ 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 മെമ്മറിയിൽ നിന്നുള്ള നേറ്റീവ് സിസ്റ്റം കോളുകൾ ഉപയോഗിക്കുകയാണെങ്കിൽ ബുദ്ധിമുട്ടുകളും ഉണ്ടാകാം. എന്നിരുന്നാലും, എബിഐ പലതവണ മാറ്റിയെങ്കിലും ആരും ഇതുവരെ പ്രശ്നങ്ങൾ റിപ്പോർട്ട് ചെയ്തിട്ടില്ലാത്തതിനാൽ ഇത് അങ്ങനെയാകില്ലെന്ന് പ്രതീക്ഷിക്കാൻ കാരണമുണ്ട്.

ഓപ്പൺബിഎസ്ഡി-നിലവിലെ ബ്രാഞ്ചിന്റെ സാധാരണ സ്നാപ്പ്ഷോട്ടുകളിൽ മാറ്റങ്ങൾ ഇതിനകം ലഭ്യമാണ്, താൽപ്പര്യമുള്ള എല്ലാവരെയും പരീക്ഷിക്കാൻ ക്ഷണിക്കുന്നു.

Chrome/Iridium-ലെ മോഡ് ദൃശ്യമാകുന്നതുമായി ബന്ധപ്പെട്ട വാർത്തകൾ തിയോയിൽ നിന്ന് ഒരു പ്രത്യേക അഭിപ്രായം അർഹിക്കുന്നു JITലെസ്സ്. അദ്ദേഹത്തിന്റെ വീക്ഷണകോണിൽ, ഇത് ചില ഉപയോഗ മോഡലുകൾക്ക് സ്വീകാര്യമാണ്, പക്ഷേ മിക്കവാറും എല്ലാവർക്കും അല്ല, കാരണം ഈ മോഡ് പ്രോസസറിലെ ലോഡ് വർദ്ധിപ്പിക്കും. നിലവിൽ, /usr/local എന്നതിനായി നിങ്ങൾ "wxallowed" പ്രവർത്തനരഹിതമാക്കിയാൽ Chrome മിക്കവാറും പ്രവർത്തിക്കും, എന്നിരുന്നാലും ചില വിപുലീകരണങ്ങളിൽ പ്രശ്‌നങ്ങളുണ്ടാകാം (ghostery ഒരു ഉദാഹരണമാണ്). ഒരു തരത്തിലല്ലെങ്കിൽ മറ്റൊരു തരത്തിൽ, JITless മോഡിലെ പൂർണ്ണമായ ജോലി സമീപഭാവിയിൽ പൂർണ്ണമായി പ്രവർത്തനക്ഷമമായ അവസ്ഥയിലേക്ക് കൊണ്ടുവരുമെന്ന് തിയോ പ്രതീക്ഷിക്കുന്നു.

അവലംബം: opennet.ru