TL; DR. આ લેખમાં, અમે પાંચ લોકપ્રિય Linux વિતરણો પર બોક્સની બહાર કામ કરતી સખત યોજનાઓનું અન્વેષણ કરીએ છીએ. દરેક માટે, અમે ડિફોલ્ટ કર્નલ રૂપરેખાંકન લીધું, બધા પેકેજો લોડ કર્યા, અને જોડાયેલ બાઈનરીઓમાં સુરક્ષા યોજનાઓનું વિશ્લેષણ કર્યું. OpenSUSE 12.4, ડેબિયન 9, CentOS, RHEL 6.10 અને 7, તેમજ ઉબુન્ટુ 14.04, 12.04 અને 18.04 LTS ગણવામાં આવતા વિતરણો છે.

પરિણામો પુષ્ટિ કરે છે કે સ્ટેકીંગ કેનેરી અને સ્થિતિ-સ્વતંત્ર કોડ જેવી મૂળભૂત યોજનાઓ પણ હજુ સુધી દરેક દ્વારા અપનાવવામાં આવી નથી. કમ્પાઇલર્સ માટે પરિસ્થિતિ વધુ ખરાબ છે જ્યારે સ્ટેક ક્લેશ જેવી નબળાઈઓ સામે રક્ષણની વાત આવે છે, જે પ્રકાશન પછી જાન્યુઆરીમાં સ્પોટલાઇટમાં આવી હતી. સિસ્ટમની નબળાઈઓ વિશે માહિતી. પરંતુ બધું એટલું નિરાશાજનક નથી. નોંધપાત્ર સંખ્યામાં દ્વિસંગી મૂળભૂત સંરક્ષણ પદ્ધતિઓનો અમલ કરે છે, અને તેમની સંખ્યા સંસ્કરણથી સંસ્કરણ સુધી વધે છે.

સમીક્ષા દર્શાવે છે કે OS અને એપ્લિકેશન સ્તરે ઉબુન્ટુ 18.04 માં સૌથી વધુ સંખ્યામાં સંરક્ષણ પદ્ધતિઓ લાગુ કરવામાં આવી છે, ત્યારબાદ ડેબિયન 9 આવે છે. બીજી તરફ, OpenSUSE 12.4, CentOS 7 અને RHEL 7 પણ મૂળભૂત સુરક્ષા યોજનાઓ અને સ્ટેક અથડામણ સુરક્ષાનો અમલ કરે છે. ડિફૉલ્ટ પેકેજોના વધુ ગીચ સમૂહ સાથે વધુ વ્યાપક રીતે ઉપયોગમાં લેવાય છે.

પરિચય

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

આ તે છે જ્યાં પ્રોગ્રામ્સને સુરક્ષિત અથવા સખત બનાવવાની પદ્ધતિઓ અમલમાં આવે છે. અમે અમુક પ્રકારની ભૂલોને રોકી શકતા નથી, પરંતુ અમે હુમલાખોરનું જીવન વધુ મુશ્કેલ બનાવી શકીએ છીએ અને અટકાવીને અથવા અટકાવીને સમસ્યાને આંશિક રીતે હલ કરી શકીએ છીએ. શોષણ આ ભૂલો. આવી સુરક્ષાનો ઉપયોગ તમામ આધુનિક ઓપરેટિંગ સિસ્ટમ્સમાં થાય છે, પરંતુ પદ્ધતિઓ જટિલતા, કાર્યક્ષમતા અને કામગીરીમાં ઘણી અલગ છે: સ્ટેક કેનેરી અને ASLR સંપૂર્ણ રક્ષણ માટે CFI и આર.ઓ.પી.. આ લેખમાં, અમે ડિફોલ્ટ રૂપરેખાંકનમાં સૌથી વધુ લોકપ્રિય Linux વિતરણોમાં કઈ સંરક્ષણ પદ્ધતિઓનો ઉપયોગ કરવામાં આવે છે તે જોઈશું, અને દરેક વિતરણની પેકેજ મેનેજમેન્ટ સિસ્ટમ્સ દ્વારા વિતરિત કરવામાં આવતી દ્વિસંગીઓના ગુણધર્મોનું પણ પરીક્ષણ કરીશું.

CVE અને સુરક્ષા

અમે બધાએ "વર્ષની સૌથી સંવેદનશીલ એપ્લિકેશન્સ" અથવા "સૌથી વધુ સંવેદનશીલ ઓપરેટિંગ સિસ્ટમ્સ" જેવા શીર્ષકોવાળા લેખો જોયા છે. સામાન્ય રીતે તેઓ નબળાઈઓ વિશેના રેકોર્ડ્સની કુલ સંખ્યા પર આંકડા પ્રદાન કરે છે CVE (સામાન્ય નબળાઈ અને એક્સપોઝર), પાસેથી મેળવેલ છે રાષ્ટ્રીય નબળાઈ ડેટાબેઝ (NVD) થી એનઆઈએસટી અને અન્ય સ્ત્રોતો. ત્યારબાદ, આ એપ્લિકેશનો અથવા OS ને CVE ની સંખ્યા દ્વારા ક્રમાંકિત કરવામાં આવે છે. કમનસીબે, જ્યારે CVE એ મુદ્દાઓને ટ્રૅક કરવા અને વિક્રેતાઓ અને વપરાશકર્તાઓને જાણ કરવા માટે ખૂબ જ ઉપયોગી છે, તેઓ સૉફ્ટવેરની વાસ્તવિક સુરક્ષા વિશે થોડું કહે છે.

ઉદાહરણ તરીકે, Linux કર્નલ માટે છેલ્લા ચાર વર્ષમાં CVE ની કુલ સંખ્યા અને પાંચ સૌથી લોકપ્રિય સર્વર વિતરણો, જેમ કે ઉબુન્ટુ, ડેબિયન, Red Hat Enterprise Linux અને OpenSUSE ને ધ્યાનમાં લો.

Рис. .

આ ગ્રાફ આપણને શું કહે છે? શું CVE ની વધુ સંખ્યાનો અર્થ એ છે કે એક વિતરણ બીજા કરતાં વધુ સંવેદનશીલ છે? કોઇ જવાબ નથિ. ઉદાહરણ તરીકે, આ લેખમાં તમે જોશો કે ડેબિયન પાસે OpenSUSE અથવા RedHat Linux ની સરખામણીમાં મજબૂત સુરક્ષા પદ્ધતિઓ છે અને તેમ છતાં ડેબિયનમાં વધુ CVE છે. જો કે, તેનો અર્થ એ નથી કે નબળી સુરક્ષા છે: CVE ની હાજરી પણ એ સંકેત આપતી નથી કે શું નબળાઈ છે. શોષણ. ગંભીરતા સ્કોર્સ કેવી રીતે તેનો સંકેત આપે છે કદાચ નબળાઈનું શોષણ, પરંતુ આખરે શોષણ અસરગ્રસ્ત સિસ્ટમમાં હાજર રક્ષણ અને હુમલાખોરોના સંસાધનો અને ક્ષમતાઓ પર ખૂબ આધાર રાખે છે. તદુપરાંત, CVE અહેવાલોની ગેરહાજરી અન્ય લોકો વિશે કશું કહેતી નથી નોંધાયેલ નથી અથવા અજાણ છે નબળાઈઓ CVE માં તફાવત સૉફ્ટવેર ગુણવત્તા સિવાયના અન્ય પરિબળોને કારણે હોઈ શકે છે, જેમાં પરીક્ષણ માટે ફાળવવામાં આવેલા સંસાધનો અથવા વપરાશકર્તા આધારના કદનો સમાવેશ થાય છે. અમારા ઉદાહરણમાં, ડેબિયનના CVE ની વધુ સંખ્યા ફક્ત સૂચવે છે કે ડેબિયન વધુ સોફ્ટવેર પેકેજો મોકલે છે.

અલબત્ત, CVE સિસ્ટમ ઉપયોગી માહિતી પ્રદાન કરે છે જે તમને યોગ્ય સુરક્ષા બનાવવા માટે પરવાનગી આપે છે. પ્રોગ્રામની નિષ્ફળતાના કારણોને આપણે જેટલી સારી રીતે સમજીશું, શોષણની સંભવિત પદ્ધતિઓને ઓળખવી અને યોગ્ય પદ્ધતિઓ વિકસાવવી તેટલું સરળ છે. શોધ અને પ્રતિભાવ. ફિગ માં. 2 છેલ્લા ચાર વર્ષમાં તમામ વિતરણો માટે નબળાઈઓની શ્રેણીઓ દર્શાવે છે (સ્રોત). તે તરત જ સ્પષ્ટ છે કે મોટા ભાગના CVE નીચેની શ્રેણીઓમાં આવે છે: સેવાનો ઇનકાર (DoS), કોડ એક્ઝિક્યુશન, ઓવરફ્લો, મેમરી ભ્રષ્ટાચાર, માહિતી લિકેજ (એક્સફિલ્ટરેશન) અને વિશેષાધિકાર વૃદ્ધિ. જો કે ઘણા CVE ની વિવિધ શ્રેણીઓમાં ઘણી વખત ગણતરી કરવામાં આવે છે, સામાન્ય રીતે સમાન મુદ્દાઓ વર્ષ-દર-વર્ષ ચાલુ રહે છે. લેખના આગળના ભાગમાં, અમે આ નબળાઈઓના શોષણને રોકવા માટે વિવિધ સુરક્ષા યોજનાઓના ઉપયોગનું મૂલ્યાંકન કરીશું.

Рис. .

કાર્યો

આ લેખમાં અમે નીચેના પ્રશ્નોના જવાબ આપવા માંગીએ છીએ:

• વિવિધ Linux વિતરણોની સુરક્ષા શું છે? કર્નલ અને યુઝર સ્પેસ એપ્લીકેશનમાં કઈ પ્રોટેક્શન મિકેનિઝમ્સ અસ્તિત્વમાં છે?
• ડિસ્ટ્રિબ્યુશનમાં સમય જતાં સુરક્ષા મિકેનિઝમ્સ કેવી રીતે બદલાઈ છે?
• દરેક વિતરણ માટે પેકેજો અને લાઇબ્રેરીઓની સરેરાશ નિર્ભરતા શું છે?
• દરેક દ્વિસંગી માટે કયા સંરક્ષણો લાગુ કરવામાં આવે છે?

વિતરણોની પસંદગી

તે તારણ આપે છે કે વિતરણ સ્થાપનો પર સચોટ આંકડા શોધવા મુશ્કેલ છે, કારણ કે મોટાભાગના કિસ્સાઓમાં ડાઉનલોડ્સની સંખ્યા વાસ્તવિક ઇન્સ્ટોલેશનની સંખ્યા સૂચવતી નથી. જો કે, યુનિક્સ વેરિઅન્ટ્સ મોટાભાગની સર્વર સિસ્ટમો બનાવે છે (વેબ સર્વર્સ પર 69,2%, દ્વારા આંકડા W3techs અને અન્ય સ્ત્રોતો), અને તેમનો હિસ્સો સતત વધી રહ્યો છે. આમ, અમારા સંશોધન માટે અમે પ્લેટફોર્મ પર બોક્સની બહાર ઉપલબ્ધ વિતરણો પર ધ્યાન કેન્દ્રિત કર્યું Google મેઘ. ખાસ કરીને, અમે નીચેની OS પસંદ કરી છે:

વિતરણ/સંસ્કરણ
કોર
બિલ્ડ

ઓપનસેસ 12.4
4.12.14-95.3-ડિફોલ્ટ
#1 SMP બુધ ડિસેમ્બર 5 06:00:48 UTC 2018 (63a8d29)

ડેબિયન 9 (ખેંચ)
4.9.0-8-amd64
#1 SMP ડેબિયન 4.9.130-2 (2018-10-27)

સેન્ટોસ 6.10
2.6.32-754.10.1.el6.x86_64
#1 SMP મંગળ 15 જાન્યુઆરી 17:07:28 UTC 2019

સેન્ટોસ 7
3.10.0-957.5.1.el7.x86_64
#1 SMP શુક્ર ફેબ્રુઆરી 1 14:54:57 UTC 2019

Red Hat Enterprise Linux સર્વર 6.10 (સેન્ટિયાગો)
2.6.32-754.9.1.el6.x86_64
#1 SMP બુધ નવેમ્બર 21 15:08:21 EST 2018

Red Hat Enterprise Linux સર્વર 7.6 (Maipo)
3.10.0-957.1.3.el7.x86_64
#1 SMP ગુરૂ નવેમ્બર 15 17:36:42 UTC 2018

ઉબુન્ટુ 14.04 (વિશ્વાસુ તાહર)
4.4.0–140-સામાન્ય

#166~14.04.1-Ubuntu SMP શનિ નવેમ્બર 17 01:52:43 UTC 20…

ઉબુન્ટુ 16.04 (ઝેનિયલ ઝેરસ)
4.15.0–1026-gcp
#27~16.04.1-Ubuntu SMP શુક્ર 7 ડિસેમ્બર 09:59:47 UTC 2018

ઉબુન્ટુ 18.04 (બાયોનિક બીવર)
4.15.0–1026-gcp
#27-Ubuntu SMP ગુરુ 6 ડિસેમ્બર 18:27:01 UTC 2018

ટેબલ 1

ઍનાલેઝ

ચાલો મૂળભૂત કર્નલ રૂપરેખાંકનનો અભ્યાસ કરીએ, તેમજ દરેક વિતરણના પેકેજ મેનેજર દ્વારા બોક્સની બહાર ઉપલબ્ધ પેકેજોના ગુણધર્મોનો અભ્યાસ કરીએ. આમ, અમે અસ્થિર રિપોઝીટરીઝ (જેમ કે ડેબિયન 'ટેસ્ટિંગ' મિરર્સ) અને તૃતીય-પક્ષ પેકેજો (જેમ કે સ્ટાન્ડર્ડ મિરર્સમાંથી Nvidia પેકેજો) ના પેકેજોને અવગણીને, દરેક ડિસ્ટ્રિબ્યુશનના ડિફૉલ્ટ મિરર્સમાંથી માત્ર પેકેજોને ધ્યાનમાં લઈએ છીએ. વધુમાં, અમે વૈવિધ્યપૂર્ણ કર્નલ સંકલન અથવા સુરક્ષા-કઠણ રૂપરેખાંકનોને ધ્યાનમાં લેતા નથી.

કર્નલ રૂપરેખાંકન વિશ્લેષણ

અમે તેના આધારે વિશ્લેષણ સ્ક્રિપ્ટ લાગુ કરી મફત kconfig તપાસનાર. ચાલો નામિત વિતરણોના આઉટ-ઓફ-ધ-બૉક્સ સુરક્ષા પરિમાણો જોઈએ અને તેમની યાદી સાથે સરખામણી કરીએ કોર સેલ્ફ ડિફેન્સ પ્રોજેક્ટ (KSPP). દરેક રૂપરેખાંકન વિકલ્પ માટે, કોષ્ટક 2 ઇચ્છિત સેટિંગનું વર્ણન કરે છે: ચેકબોક્સ એવા વિતરણો માટે છે જે KSSP ભલામણોનું પાલન કરે છે (શરતોની સમજૂતી માટે નીચે જુઓ). અહીં; ભવિષ્યના લેખોમાં અમે સમજાવીશું કે આમાંથી કેટલી સુરક્ષા પદ્ધતિઓ અસ્તિત્વમાં આવી અને તેમની ગેરહાજરીમાં સિસ્ટમ કેવી રીતે હેક કરવી).

સામાન્ય રીતે, નવા કર્નલોમાં બોક્સની બહાર કડક સેટિંગ્સ હોય છે. ઉદાહરણ તરીકે, 6.10 કર્નલ પર CentOS 6.10 અને RHEL 2.6.32 માં નવા કર્નલોમાં અમલમાં મૂકાયેલ મોટાભાગની જટિલ સુવિધાઓનો અભાવ છે જેમ કે SMAP, કડક RWX પરવાનગીઓ, સરનામાં રેન્ડમાઇઝેશન અથવા copy2usr સુરક્ષા. એ નોંધવું જોઈએ કે કોષ્ટકમાંના ઘણા રૂપરેખાંકન વિકલ્પો કર્નલના જૂના સંસ્કરણોમાં ઉપલબ્ધ નથી અને વાસ્તવિકતામાં લાગુ પડતા નથી - આ હજુ પણ યોગ્ય સુરક્ષાના અભાવ તરીકે કોષ્ટકમાં સૂચવવામાં આવ્યું છે. તેવી જ રીતે, જો આપેલ સંસ્કરણમાં રૂપરેખાંકન વિકલ્પ હાજર ન હોય, અને સુરક્ષા માટે તે વિકલ્પને નિષ્ક્રિય કરવાની જરૂર હોય, તો આને વાજબી રૂપરેખાંકન ગણવામાં આવે છે.

પરિણામોનું અર્થઘટન કરતી વખતે ધ્યાનમાં લેવાનો બીજો મુદ્દો: કેટલાક કર્નલ રૂપરેખાંકનો કે જે હુમલાની સપાટીને વધારે છે તેનો ઉપયોગ સુરક્ષા માટે પણ થઈ શકે છે. આવા ઉદાહરણોમાં uprobes અને kprobes, કર્નલ મોડ્યુલો અને BPF/eBPF નો સમાવેશ થાય છે. અમારી ભલામણ એ છે કે ઉપરોક્ત મિકેનિઝમ્સનો વાસ્તવિક સુરક્ષા પ્રદાન કરવા માટે ઉપયોગ કરો, કારણ કે તે ઉપયોગમાં લેવા માટે બિન-તુચ્છ છે અને તેમનું શોષણ ધારે છે કે દૂષિત અભિનેતાઓએ સિસ્ટમમાં પહેલેથી જ પગ જમાવી લીધો છે. પરંતુ જો આ વિકલ્પો સક્ષમ હોય, તો સિસ્ટમ એડમિનિસ્ટ્રેટરે દુરુપયોગ માટે સક્રિયપણે નિરીક્ષણ કરવું આવશ્યક છે.

કોષ્ટક 2 માંની એન્ટ્રીઓ પર વધુ જોતાં, આપણે જોઈએ છીએ કે આધુનિક કર્નલ નબળાઈઓના શોષણ સામે રક્ષણ માટે ઘણા વિકલ્પો પ્રદાન કરે છે જેમ કે માહિતી લિકેજ અને સ્ટેક/હીપ ઓવરફ્લો. જો કે, અમે નોંધ્યું છે કે સૌથી તાજેતરના લોકપ્રિય વિતરણોએ પણ હજુ સુધી વધુ જટિલ સંરક્ષણ લાગુ કર્યું નથી (ઉદાહરણ તરીકે, પેચ સાથે grsecurity) અથવા કોડ પુનઃઉપયોગ હુમલાઓ સામે આધુનિક રક્ષણ (દા.ત. કોડ માટે R^X જેવી યોજનાઓ સાથે રેન્ડમાઇઝેશનનું સંયોજન). બાબતોને વધુ ખરાબ કરવા માટે, આ વધુ અદ્યતન સંરક્ષણ પણ હુમલાઓની સંપૂર્ણ શ્રેણી સામે રક્ષણ આપતા નથી. તેથી, સિસ્ટમ એડમિનિસ્ટ્રેટર્સ માટે તે મહત્વપૂર્ણ છે કે તે ઉકેલો સાથે સ્માર્ટ રૂપરેખાંકનોને પૂરક બનાવે છે જે રનટાઇમ શોષણ શોધ અને નિવારણ પ્રદાન કરે છે.

એપ્લિકેશન વિશ્લેષણ

આશ્ચર્યની વાત નથી કે, વિવિધ વિતરણોમાં અલગ-અલગ પેકેજ લાક્ષણિકતાઓ, સંકલન વિકલ્પો, પુસ્તકાલયની અવલંબન વગેરે હોય છે. માટે પણ તફાવતો અસ્તિત્વમાં છે. સંબંધિત ડિસ્ટ્રિબ્યુશન અને પેકેજો નાની સંખ્યામાં અવલંબન સાથે (ઉદાહરણ તરીકે, ઉબુન્ટુ અથવા ડેબિયન પર કોર્યુટીલ્સ). તફાવતોનું મૂલ્યાંકન કરવા માટે, અમે બધા ઉપલબ્ધ પેકેજો ડાઉનલોડ કર્યા, તેમની સામગ્રીઓ કાઢી અને દ્વિસંગીઓ અને નિર્ભરતાઓનું વિશ્લેષણ કર્યું. દરેક પેકેજ માટે, અમે તેના પર નિર્ભર અન્ય પેકેજોનો ટ્રૅક રાખ્યો છે, અને દરેક દ્વિસંગી માટે, અમે તેની નિર્ભરતાને ટ્રૅક કરી છે. આ વિભાગમાં અમે સંક્ષિપ્તમાં તારણોનો સારાંશ આપીએ છીએ.

વિતરણો

કુલ મળીને, અમે તમામ ડિસ્ટ્રિબ્યુશન માટે 361 પેકેજો ડાઉનલોડ કર્યા છે, માત્ર ડિફોલ્ટ મિરર્સમાંથી પેકેજો કાઢીને. અમે ELF એક્ઝિક્યુટેબલ વગરના પેકેજોની અવગણના કરી, જેમ કે સ્ત્રોતો, ફોન્ટ્સ વગેરે. ફિલ્ટર કર્યા પછી, 556 પેકેજો રહી ગયા, જેમાં કુલ 129 દ્વિસંગી છે. વિતરણોમાં પેકેજો અને ફાઇલોનું વિતરણ ફિગમાં બતાવવામાં આવ્યું છે. 569.

Рис. .

તમે જોશો કે વિતરણ જેટલું આધુનિક છે, તેટલા વધુ પેકેજો અને દ્વિસંગીઓ તેમાં સમાવિષ્ટ છે, જે તાર્કિક છે. જો કે, ઉબુન્ટુ અને ડેબિયન પેકેજોમાં CentOS, SUSE અને RHEL કરતાં ઘણી વધુ દ્વિસંગીઓ (બંને એક્ઝિક્યુટેબલ અને ડાયનેમિક મોડ્યુલ અને લાઇબ્રેરીઓ)નો સમાવેશ થાય છે, જે સંભવિતપણે ઉબુન્ટુ અને ડેબિયનની હુમલાની સપાટીને અસર કરે છે (એ નોંધવું જોઈએ કે સંખ્યાઓ તમામ સંસ્કરણોની તમામ દ્વિસંગીઓને પ્રતિબિંબિત કરે છે. પેકેજ, એટલે કે, કેટલીક ફાઇલોનું ઘણી વખત વિશ્લેષણ કરવામાં આવે છે). આ ખાસ કરીને મહત્વનું છે જ્યારે તમે પેકેજો વચ્ચે નિર્ભરતાને ધ્યાનમાં લો. આમ, એક જ પેકેજ બાઈનરીમાં નબળાઈ ઇકોસિસ્ટમના ઘણા ભાગોને અસર કરી શકે છે, જેમ કે એક સંવેદનશીલ પુસ્તકાલય તેને આયાત કરતી તમામ દ્વિસંગીઓને અસર કરી શકે છે. પ્રારંભિક બિંદુ તરીકે, ચાલો વિવિધ ઓપરેટિંગ સિસ્ટમ્સમાં પેકેજો વચ્ચે નિર્ભરતાની સંખ્યાના વિતરણને જોઈએ:

Рис. .

લગભગ તમામ વિતરણોમાં, 60% પેકેજોમાં ઓછામાં ઓછી 10 નિર્ભરતા હોય છે. વધુમાં, કેટલાક પેકેજોમાં નોંધપાત્ર રીતે મોટી સંખ્યામાં અવલંબન (100 થી વધુ) હોય છે. આ જ રિવર્સ પેકેજ અવલંબન પર લાગુ પડે છે: અપેક્ષા મુજબ, વિતરણમાં અન્ય ઘણા પેકેજો દ્વારા થોડા પેકેજોનો ઉપયોગ કરવામાં આવે છે, તેથી તે પસંદ કરેલા કેટલાકમાં નબળાઈઓ ઉચ્ચ જોખમ છે. ઉદાહરણ તરીકે, નીચેનું કોષ્ટક SLES, Centos 20, Debian 7 અને Ubuntu 9 (દરેક સેલ પેકેજ અને રિવર્સ ડિપેન્ડન્સીની સંખ્યા દર્શાવે છે) માં મહત્તમ સંખ્યામાં રિવર્સ ડિપેન્ડન્સી સાથે 18.04 પેકેજોની યાદી આપે છે.

ટેબલ 3

રસપ્રદ હકીકત. જો કે વિશ્લેષિત તમામ OSes x86_64 આર્કિટેક્ચર માટે બનાવવામાં આવ્યા છે, અને મોટાભાગના પેકેજોમાં આર્કિટેક્ચરને x86_64 અને x86 તરીકે વ્યાખ્યાયિત કરવામાં આવ્યું છે, પેકેજોમાં ઘણીવાર અન્ય આર્કિટેક્ચરો માટે દ્વિસંગી હોય છે, જેમ કે આકૃતિ 5 માં બતાવ્યા પ્રમાણે. XNUMX.

Рис. .

આગળના વિભાગમાં, અમે વિશ્લેષિત દ્વિસંગીઓની લાક્ષણિકતાઓનો અભ્યાસ કરીશું.

દ્વિસંગી ફાઇલ સંરક્ષણ આંકડા

સંપૂર્ણ ન્યૂનતમ, તમારે તમારી હાલની દ્વિસંગીઓ માટે સુરક્ષા વિકલ્પોના મૂળભૂત સેટનું અન્વેષણ કરવાની જરૂર છે. કેટલાક Linux વિતરણો સ્ક્રિપ્ટો સાથે આવે છે જે આવી તપાસ કરે છે. ઉદાહરણ તરીકે, ડેબિયન/ઉબુન્ટુ પાસે આવી સ્ક્રિપ્ટ છે. અહીં તેમના કાર્યનું ઉદાહરણ છે:

$ hardening-check $(which docker)
/usr/bin/docker:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: no, only unprotected functions found!
 Read-only relocations: yes
 Immediate binding: yes

સ્ક્રિપ્ટ પાંચ તપાસે છે સંરક્ષણ કાર્યો:

• પોઝિશન ઇન્ડિપેન્ડન્ટ એક્ઝિક્યુટેબલ (PIE): જો કર્નલમાં ASLR સક્ષમ હોય તો રેન્ડમાઇઝેશન હાંસલ કરવા માટે પ્રોગ્રામના ટેક્સ્ટ સેક્શનને મેમરીમાં ખસેડી શકાય છે કે કેમ તે સૂચવે છે.
• સ્ટેક પ્રોટેક્ટેડ: સ્ટેક અથડામણના હુમલા સામે રક્ષણ આપવા માટે સ્ટેક કેનેરી સક્ષમ છે કે કેમ.
• ફોર્ટીફાઈ સોર્સ: શું અસુરક્ષિત કાર્યો (ઉદાહરણ તરીકે, strcpy) તેમના વધુ સુરક્ષિત સમકક્ષો સાથે બદલવામાં આવે છે, અને રનટાઈમ પર ચકાસાયેલ કૉલ્સ તેમના અનચેક કરેલા સમકક્ષો સાથે બદલવામાં આવે છે (ઉદાહરણ તરીકે, __memcpy_chk ને બદલે memcpy).
• ફક્ત-વાંચવા માટેના રિલોકેશન્સ (RELRO): શું રિલોકેશન ટેબલ એન્ટ્રીઓને માત્ર વાંચવા માટે ચિહ્નિત કરવામાં આવે છે જો તે અમલ શરૂ થાય તે પહેલાં ટ્રિગર થઈ હોય.
• તાત્કાલિક બંધનકર્તા: પ્રોગ્રામ એક્ઝેક્યુશન શરૂ થાય તે પહેલાં રનટાઇમ લિંકર બધી ચાલને મંજૂરી આપે છે કે કેમ (આ સંપૂર્ણ RELRO ની સમકક્ષ છે).

શું ઉપરોક્ત પદ્ધતિઓ પર્યાપ્ત છે? કમનસીબે નાં. ઉપરોક્ત તમામ સંરક્ષણોને બાયપાસ કરવાની જાણીતી રીતો છે, પરંતુ સંરક્ષણ જેટલું કઠિન છે, હુમલાખોર માટે બાર વધારે છે. દાખ્લા તરીકે, RELRO બાયપાસ પદ્ધતિઓ જો PIE અને તાત્કાલિક બંધનકર્તા અમલમાં હોય તો લાગુ કરવું વધુ મુશ્કેલ છે. તેવી જ રીતે, સંપૂર્ણ ASLR ને કાર્યકારી શોષણ બનાવવા માટે વધારાના કાર્યની જરૂર છે. જો કે, અત્યાધુનિક હુમલાખોરો આવા રક્ષણોને પહોંચી વળવા માટે પહેલેથી જ તૈયાર છે: તેમની ગેરહાજરી અનિવાર્યપણે હેકને ઝડપી બનાવશે. આથી આ પગલાં જરૂરી ગણાય તે જરૂરી છે લઘુત્તમ.

અમે આ અને અન્ય ત્રણ પદ્ધતિઓ દ્વારા પ્રશ્નમાં રહેલા વિતરણોમાં કેટલી બાઈનરી ફાઇલો સુરક્ષિત છે તેનો અભ્યાસ કરવા માગીએ છીએ:

• એક્ઝિક્યુટેબલ બીટ (NX) કોઈપણ પ્રદેશમાં અમલને અટકાવે છે જે એક્ઝેક્યુટેબલ ન હોવા જોઈએ, જેમ કે સ્ટેક હીપ, વગેરે.
• RPATH/RUNPATH મેચિંગ લાઇબ્રેરીઓ શોધવા માટે ડાયનેમિક લોડર દ્વારા ઉપયોગમાં લેવાતા એક્ઝેક્યુશન પાથને સૂચવે છે. પ્રથમ એક છે ફરજિયાત કોઈપણ આધુનિક સિસ્ટમ માટે: તેની ગેરહાજરી હુમલાખોરોને મનસ્વી રીતે પેલોડને મેમરીમાં લખવા અને તેને જેમ છે તેમ ચલાવવાની મંજૂરી આપે છે. બીજા માટે, અયોગ્ય એક્ઝેક્યુશન પાથ રૂપરેખાંકનો અવિશ્વસનીય કોડ રજૂ કરવામાં મદદ કરે છે જે સંખ્યાબંધ સમસ્યાઓ તરફ દોરી શકે છે (દા.ત. વિશેષાધિકાર વૃદ્ધિ, અને અન્ય સમસ્યાઓ).
• સ્ટેક અથડામણ રક્ષણ એવા હુમલાઓ સામે રક્ષણ પૂરું પાડે છે જે સ્ટેકને મેમરીના અન્ય ક્ષેત્રોને ઓવરલેપ કરવા માટેનું કારણ બને છે (જેમ કે ઢગલો). આપેલ તાજેતરના શોષણ દુરુપયોગ સિસ્ટમડ હીપ અથડામણ નબળાઈઓ, અમને લાગ્યું કે અમારા ડેટાસેટમાં આ પદ્ધતિનો સમાવેશ કરવો યોગ્ય છે.

તેથી, વધુ અડચણ વિના, ચાલો નંબરો પર ઉતરીએ. કોષ્ટકો 4 અને 5 અનુક્રમે એક્ઝિક્યુટેબલ ફાઇલો અને વિવિધ વિતરણોની લાઇબ્રેરીઓના વિશ્લેષણનો સારાંશ ધરાવે છે.

• જેમ તમે જોઈ શકો છો, દુર્લભ અપવાદો સાથે, NX સંરક્ષણ દરેક જગ્યાએ લાગુ કરવામાં આવે છે. ખાસ કરીને, CentOS, RHEL અને OpenSUSE ની તુલનામાં ઉબુન્ટુ અને ડેબિયન વિતરણોમાં તેનો થોડો ઓછો ઉપયોગ નોંધી શકાય છે.
• સ્ટેક કેનેરી ઘણી જગ્યાએ ખૂટે છે, ખાસ કરીને જૂના કર્નલો સાથેના વિતરણમાં. સેન્ટોસ, આરએચઈએલ, ડેબિયન અને ઉબુન્ટુના નવીનતમ વિતરણોમાં કેટલીક પ્રગતિ જોવા મળી રહી છે.
• ડેબિયન અને ઉબુન્ટુ 18.04 ના અપવાદ સાથે, મોટા ભાગના વિતરણોમાં નબળો PIE સપોર્ટ છે.
• OpenSUSE, Centos 7 અને RHEL 7માં સ્ટેક અથડામણ સુરક્ષા નબળી છે અને અન્યમાં વર્ચ્યુઅલ રીતે અસ્તિત્વમાં નથી.
• આધુનિક કર્નલ સાથેના તમામ વિતરણોમાં RELRO માટે થોડો સપોર્ટ છે, જેમાં ઉબુન્ટુ 18.04 આગળ છે અને ડેબિયન બીજા ક્રમે આવે છે.

પહેલેથી જ ઉલ્લેખ કર્યો છે તેમ, આ કોષ્ટકમાં મેટ્રિક્સ એ બાઈનરી ફાઇલના તમામ સંસ્કરણો માટે સરેરાશ છે. જો તમે ફક્ત ફાઇલોના નવીનતમ સંસ્કરણોને જોશો, તો સંખ્યાઓ અલગ હશે (ઉદાહરણ તરીકે, જુઓ PIE અમલીકરણ સાથે ડેબિયન પ્રગતિ). વધુમાં, મોટા ભાગના વિતરણો સામાન્ય રીતે આંકડાઓની ગણતરી કરતી વખતે દ્વિસંગીનાં અમુક ફંક્શન્સની સુરક્ષાનું પરીક્ષણ કરે છે, પરંતુ અમારું વિશ્લેષણ સખ્તાઇવાળા કાર્યોની સાચી ટકાવારી દર્શાવે છે. તેથી, જો 5 માંથી 50 ફંક્શન્સ બાઈનરીમાં સુરક્ષિત છે, તો અમે તેને 0,1 નો સ્કોર આપીશું, જે 10% ફંક્શનને મજબૂત કરવામાં આવે છે.

કોષ્ટક 4. ફિગમાં બતાવેલ એક્ઝિક્યુટેબલ ફાઇલો માટેની સુરક્ષા લાક્ષણિકતાઓ. 3 (એક્ઝિક્યુટેબલ ફાઇલોની કુલ સંખ્યાની ટકાવારી તરીકે સંબંધિત કાર્યોનું અમલીકરણ)

કોષ્ટક 5. ફિગમાં બતાવેલ પુસ્તકાલયો માટેની સુરક્ષા લાક્ષણિકતાઓ. 3 (ગ્રંથાલયોની કુલ સંખ્યાની ટકાવારી તરીકે સંબંધિત કાર્યોનું અમલીકરણ)

તો શું ત્યાં પ્રગતિ છે? ત્યાં ચોક્કસપણે છે: આ વ્યક્તિગત વિતરણોના આંકડાઓમાંથી જોઈ શકાય છે (ઉદાહરણ તરીકે, ડેબિયન), તેમજ ઉપરના કોષ્ટકોમાંથી. ફિગમાં ઉદાહરણ તરીકે. આકૃતિ 6 ઉબુન્ટુ એલટીએસ 5 (અમે સ્ટેક અથડામણ સંરક્ષણના આંકડાઓને અવગણ્યા છે) ના ત્રણ ક્રમિક વિતરણોમાં સંરક્ષણ મિકેનિઝમના અમલીકરણને બતાવે છે. અમે નોંધ્યું છે કે વર્ઝનથી વર્ઝન સુધી વધુને વધુ ફાઇલો સ્ટેક કેનેરીને સપોર્ટ કરે છે અને વધુને વધુ બાઈનરીઝ સંપૂર્ણ RELRO સુરક્ષા સાથે મોકલવામાં આવે છે.

Рис. .

કમનસીબે, વિવિધ વિતરણોમાં સંખ્યાબંધ એક્ઝિક્યુટેબલ ફાઇલો પાસે હજુ પણ ઉપરોક્ત કોઈપણ સુરક્ષા નથી. ઉદાહરણ તરીકે, ઉબુન્ટુ 18.04ને જોતા, તમે ngetty દ્વિસંગી (એક ગેટ્ટી રિપ્લેસમેન્ટ), તેમજ mksh અને lksh શેલ્સ, પિકોલિસ્પ ઈન્ટરપ્રીટર, nvidia-cuda-ટૂલકીટ પેકેજો (GPU-એક્સીલરેટેડ એપ્લિકેશન્સ માટે લોકપ્રિય પેકેજ) જોશો. જેમ કે મશીન લર્નિંગ ફ્રેમવર્ક), અને klibc -utils. તેવી જ રીતે, mandos-client દ્વિસંગી (એક વહીવટી સાધન જે તમને એનક્રિપ્ટેડ ફાઇલ સિસ્ટમ્સ સાથે મશીનોને આપમેળે રીબૂટ કરવાની મંજૂરી આપે છે) તેમજ rsh-redone-client (rsh અને rlogin નું પુનઃ અમલીકરણ) NX રક્ષણ વિના જહાજ, જો કે તેમની પાસે SUID અધિકારો છે : (. ઉપરાંત, કેટલીક સ્યુડ દ્વિસંગીઓમાં મૂળભૂત સુરક્ષાનો અભાવ છે જેમ કે સ્ટેક કેનેરી (ઉદાહરણ તરીકે, Xorg પેકેજમાંથી Xorg.wrap દ્વિસંગી).

સારાંશ અને સમાપન ટીકા

આ લેખમાં, અમે આધુનિક Linux વિતરણોની કેટલીક સુરક્ષા સુવિધાઓને પ્રકાશિત કરી છે. વિશ્લેષણ દર્શાવે છે કે નવીનતમ ઉબુન્ટુ એલટીએસ ડિસ્ટ્રિબ્યુશન (18.04) પ્રમાણમાં નવા કર્નલ, જેમ કે ઉબુન્ટુ 14.04, 12.04 અને ડેબિયન 9 સાથેના વિતરણોમાં સરેરાશ સૌથી મજબૂત OS અને એપ્લિકેશન સ્તર સુરક્ષાનો અમલ કરે છે. જો કે, તપાસેલ વિતરણો CentOS, RHEL અને OpenSUSE અમારા સેટમાં ડિફૉલ્ટ રૂપે તેઓ પેકેજોના વધુ ગીચ સમૂહનું ઉત્પાદન કરે છે, અને નવીનતમ સંસ્કરણો (CentOS અને RHEL) માં તેઓ ડેબિયન-આધારિત સ્પર્ધકો (ડેબિયન અને ઉબુન્ટુ) ની સરખામણીમાં સ્ટેક અથડામણ સુરક્ષાની ઊંચી ટકાવારી ધરાવે છે. CentOS અને RedHat સંસ્કરણોની સરખામણી કરતા, અમે સંસ્કરણ 6 થી 7 સુધી સ્ટેક કેનેરી અને RELROના અમલીકરણમાં મોટા સુધારાઓ જોયા છે, પરંતુ સરેરાશ CentOS માં RHEL કરતાં વધુ સુવિધાઓ લાગુ કરવામાં આવી છે. સામાન્ય રીતે, તમામ વિતરણોએ PIE સુરક્ષા પર વિશેષ ધ્યાન આપવું જોઈએ, જે, ડેબિયન 9 અને ઉબુન્ટુ 18.04 ના અપવાદ સાથે, અમારા ડેટાસેટમાં 10% કરતા ઓછા બાઈનરીઝમાં લાગુ કરવામાં આવે છે.

છેલ્લે, એ નોંધવું જોઈએ કે જો કે અમે સંશોધન જાતે કર્યું છે, ત્યાં ઘણા સુરક્ષા સાધનો ઉપલબ્ધ છે (દા.ત. લીનીસ, ટાઇગર, હબલ), જે વિશ્લેષણ કરે છે અને અસુરક્ષિત રૂપરેખાંકનો ટાળવામાં મદદ કરે છે. કમનસીબે, વાજબી રૂપરેખાંકનોમાં મજબૂત રક્ષણ પણ શોષણની ગેરહાજરીની બાંયધરી આપતું નથી. તેથી જ અમે નિશ્ચિતપણે માનીએ છીએ કે તેની ખાતરી કરવી મહત્વપૂર્ણ છે વાસ્તવિક સમયમાં હુમલાઓનું વિશ્વસનીય નિરીક્ષણ અને નિવારણ, શોષણના દાખલાઓ પર ધ્યાન કેન્દ્રિત કરવું અને તેમને અટકાવવું.

સોર્સ: www.habr.com