Glibc માં Aurora OS ડેવલપર્સ દ્વારા તૈયાર કરવામાં આવેલ memcpy નબળાઈ માટેના સુધારાનો સમાવેશ થાય છે.

ઓરોરા મોબાઇલ ઓપરેટિંગ સિસ્ટમના વિકાસકર્તાઓએ (ઓપન મોબાઇલ પ્લેટફોર્મ કંપની દ્વારા વિકસિત સેઇલફિશ ઓએસનો ફોર્ક) નાબૂદ કરવા વિશે એક છતી કરતી વાર્તા શેર કરી. જટિલ નબળાઈ (CVE-2020-6096) Glibc માં, જે ફક્ત ARMv7 પ્લેટફોર્મ પર દેખાય છે. નબળાઈ વિશેની માહિતી મે મહિનામાં જાહેર કરવામાં આવી હતી, પરંતુ તાજેતરના દિવસો સુધી, નબળાઈઓ હોવા છતાં, સુધારાઓ ઉપલબ્ધ ન હતા. સોંપેલ જોખમનું ઊંચું સ્તર અને ત્યાં એક એક્સપ્લોઈટનો વર્કિંગ પ્રોટોટાઈપ છે જે તમને memcpy() અને memmove() ફંક્શન્સમાં ચોક્કસ રીતે ફોર્મેટ કરેલા ડેટાની પ્રક્રિયા કરતી વખતે કોડ એક્ઝિક્યુશન ગોઠવવાની મંજૂરી આપે છે. માટે પેકેજ ફિક્સ ડેબિયન и ઉબુન્ટુ હજુ સુધી બહાર પાડવામાં આવ્યું નથી અને જાહેર જાહેરાતની ક્ષણથી લગભગ બે મહિના અને Glibc ડેવલપર્સને સૂચિત કરવામાં આવ્યા ત્યારથી પાંચ મહિના સુધી નબળાઈ અનિશ્ચિત રહે છે.

નબળાઈ એ એઆરએમવી7 માટે એસેમ્બલી ભાષામાં memcpy() અને memmove() ના અમલીકરણમાં પોતાને પ્રગટ કરે છે અને પેરામીટરના નકારાત્મક મૂલ્યોની ખોટી પ્રક્રિયાને કારણે થાય છે જે કૉપિ કરેલ વિસ્તારનું કદ નક્કી કરે છે. પેચ ડેવલપમેન્ટ સાથે સમસ્યાઓ ત્યારે શરૂ થઈ જ્યારે કંપનીઓ SUSE и લાલ ટોપી જાહેરાત કરી કે તેમના પ્લેટફોર્મ્સ સમસ્યાથી પ્રભાવિત નથી, કારણ કે તેઓ 32-બીટ ARMv7 સિસ્ટમ્સ માટે બિલ્ડ કરતા નથી, અને ફિક્સ બનાવવામાં ભાગ લીધો નથી. ઘણા એમ્બેડેડ ડિસ્ટ્રિબ્યુશનના વિકાસકર્તાઓ Glibc ટીમ પર આધાર રાખતા હોય તેવું લાગે છે, અને ફિક્સ તૈયાર કરવામાં પણ સક્રિયપણે સામેલ થયા નથી.

વિકલ્પ પેચ સમસ્યાને અવરોધિત કરવા માટે, Huawei એ લગભગ તરત જ પ્રસ્તાવ મૂક્યો કે તેણે સહી કરેલ ઓપરેન્ડ્સ (bge અને blt) સાથે કામ કરતી એસેમ્બલી સૂચનાઓને સહી વગરના એનાલોગ (blo અને bhs) સાથે બદલવાનો પ્રયાસ કર્યો. Glibc જાળવણીકારોએ વિવિધ ભૂલ પરિસ્થિતિઓને ચકાસવા માટે પરીક્ષણોનો સમૂહ વિકસાવ્યો, જે પછી તે બહાર આવ્યું કે Huawei પેચ યોગ્ય નથી અને ઇનપુટ ડેટાના તમામ સંભવિત સંયોજનો પર પ્રક્રિયા કરતું નથી.

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

જૂનની શરૂઆતમાં, ફિક્સની બે આવૃત્તિઓ તૈયાર કરવામાં આવી હતી, જે Glibc જાળવણીકારોના પરીક્ષણ માળખું અને અરોરાના આંતરિક પરીક્ષણ સ્યુટમાંથી પસાર થાય છે. 3 જૂનના રોજ, વિકલ્પોમાંથી એક પસંદ કરવામાં આવ્યો હતો અને મોકલેલ Glibc મેઇલિંગ લિસ્ટમાં. એક અઠવાડિયા પછી
હતી સૂચવ્યું અભિગમમાં સમાન અન્ય પેચ, જેણે મલ્ટિઆર્ક અમલીકરણમાં સમસ્યાને સુધારી, જેને હ્યુઆવેઇએ અગાઉ ઠીક કરવાનો પ્રયાસ કર્યો હતો. પરીક્ષણમાં એક મહિનાનો સમય લાગ્યો અને કાનૂની નોંધણી પેચના મહત્વને કારણે.
8 જુલાઈના સુધારા સ્વીકારવામાં આવ્યા હતા આગામી glibc 2.32 રિલીઝની મુખ્ય શાખામાં. અમલીકરણમાં બે પેચોનો સમાવેશ થાય છે - первый ARMv7 માટે memcpy ના મલ્ટિઆર્ક અમલીકરણ માટે, અને બીજા ARM માટે memcpy() અને memmove() ના સામાન્ય એસેમ્બલી ભાષા અમલીકરણ માટે.

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

સોર્સ: opennet.ru