uClibc અને uClibc-ng માં નબળાઈ કે જે ડેટાને DNS કેશમાં સ્પૂફ કરવાની મંજૂરી આપે છે

પ્રમાણભૂત C લાઇબ્રેરીઓ uClibc અને uClibc-ng માં, ઘણા એમ્બેડેડ અને પોર્ટેબલ ઉપકરણોમાં ઉપયોગમાં લેવામાં આવે છે, એક નબળાઈ ઓળખવામાં આવી છે (CVE સોંપાયેલ નથી) જે બનાવટી ડેટાને DNS કેશમાં દાખલ કરવાની મંજૂરી આપે છે, જેનો ઉપયોગ IP સરનામાંને બદલવા માટે થઈ શકે છે. કેશમાં મનસ્વી ડોમેનનું અને હુમલાખોરના સર્વર પર ડોમેન પર રીડાયરેક્ટ વિનંતીઓ.

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

નબળાઈ DNS ક્વેરીઝ મોકલવા માટે કોડમાં અનુમાનિત વ્યવહાર ઓળખકર્તાઓના ઉપયોગને કારણે છે. પોર્ટ નંબરોના વધારાના રેન્ડમાઇઝેશનનો ઉપયોગ કર્યા વિના ફક્ત કાઉન્ટરને વધારીને DNS વિનંતીનો ઓળખ નંબર પસંદ કરવામાં આવ્યો હતો, જેના કારણે કાલ્પનિક પ્રતિસાદો સાથે UDP પેકેટના પ્રિમપ્ટિવ મોકલવા દ્વારા DNS કેશને ઝેર કરવાનું શક્ય બન્યું હતું (જો તે પહેલાં આવે તો પ્રતિસાદ સ્વીકારવામાં આવશે. વાસ્તવિક સર્વર તરફથી પ્રતિસાદ અને તેમાં યોગ્ય ID શામેલ છે). 2008 માં પ્રસ્તાવિત કામિન્સ્કી પદ્ધતિથી વિપરીત, વ્યવહાર ઓળખકર્તાને અનુમાન લગાવવાની પણ જરૂર નથી, કારણ કે તે શરૂઆતમાં અનુમાનિત છે (મૂલ્ય શરૂઆતમાં 1 પર સેટ કરવામાં આવે છે, જે રેન્ડમ રીતે પસંદ કરવાને બદલે દરેક વિનંતી સાથે વધે છે).

આઇડેન્ટિફાયર બ્રુટ ફોર્સ સામે રક્ષણ આપવા માટે, સ્પષ્ટીકરણ વધુમાં વધુ સોર્સ નેટવર્ક પોર્ટની સંખ્યાના રેન્ડમ વિતરણનો ઉપયોગ કરવાની ભલામણ કરે છે જેમાંથી DNS વિનંતીઓ મોકલવામાં આવે છે, જે ઓળખકર્તાના અપૂરતા મોટા કદ માટે વળતર આપે છે. જ્યારે તમે કાલ્પનિક પ્રતિસાદ જનરેટ કરવા માટે પોર્ટ રેન્ડમાઇઝેશનને સક્ષમ કરો છો, ત્યારે 16-બીટ ઓળખકર્તા પસંદ કરવા ઉપરાંત, તમારે નેટવર્ક પોર્ટ નંબર પણ પસંદ કરવો આવશ્યક છે. uClibc અને uClibc-ng માં, આવા રેન્ડમાઇઝેશનને સ્પષ્ટ રીતે સક્ષમ કરવામાં આવ્યું ન હતું (જ્યારે બાઇન્ડને કૉલ કરતી વખતે, રેન્ડમ સ્ત્રોત UDP પોર્ટનો ઉલ્લેખ કરવામાં આવ્યો ન હતો) અને તેનો ઉપયોગ ઑપરેટિંગ સિસ્ટમ સેટિંગ્સ પર આધારિત હતો.

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

uClibc અને uClibc-ng ના તમામ વર્તમાન પ્રકાશનોમાં સમસ્યાની પુષ્ટિ કરવામાં આવી છે, જેમાં uClibc 0.9.33.2 અને uClibc-ng 1.0.40 ના સૌથી તાજેતરના સંસ્કરણોનો સમાવેશ થાય છે. સપ્ટેમ્બર 2021 માં, નબળાઈ વિશેની માહિતી CERT/CC ને સુધારાઓની સંકલિત તૈયારી માટે મોકલવામાં આવી હતી. જાન્યુઆરી 2022 માં, CERT/CC સાથે સહયોગ કરતા 200 થી વધુ ઉત્પાદકો સાથે સમસ્યા પરનો ડેટા શેર કરવામાં આવ્યો હતો. માર્ચમાં, uClibc-ng પ્રોજેક્ટના જાળવણીકારનો અલગથી સંપર્ક કરવાનો પ્રયાસ કરવામાં આવ્યો હતો, પરંતુ તેણે જવાબ આપ્યો હતો કે તે પોતાની રીતે નબળાઈને ઠીક કરવામાં સક્ષમ નથી અને સમસ્યા વિશેની માહિતી જાહેરમાં જાહેર કરવાની ભલામણ કરી હતી, જેમાં મદદ મેળવવાની આશા હતી. સમુદાયમાંથી ઠીક કરો. ઉત્પાદકોમાં, NETGEAR એ નબળાઈને દૂર કરતા અપડેટની રજૂઆતની જાહેરાત કરી.

સોર્સ: opennet.ru