થોડા દિવસો પહેલા સમાચાર પ્રકાશિત થયા હતા સી સ્ટાન્ડર્ડ લાઇબ્રેરીઓમાં uClibc અને uClibc-ng, ઘણા એમ્બેડેડ અને પોર્ટેબલ ઉપકરણોમાં વપરાય છે, નબળાઈ ઓળખવામાં આવી છે (CVE સાથે હજુ સુધી સોંપાયેલ નથી), જે DNS કેશમાં ડમી ડેટાને બદલવાની મંજૂરી આપે છે, જેનો ઉપયોગ કેશમાં મનસ્વી ડોમેનના IP સરનામાંને સ્પૂફ કરવા અને ડોમેનને હુમલાખોરના સર્વર પર વિનંતીઓ રીડાયરેક્ટ કરવા માટે થઈ શકે છે.
સમસ્યા અંગે ઉલ્લેખ કરવામાં આવ્યો છે કે આ રાઉટર્સ, એક્સેસ પોઈન્ટ્સ અને IoT ઉપકરણો માટે વિવિધ Linux ફર્મવેરને અસર કરે છે, તેમજ ઓપનડબ્લ્યુઆરટી અને એમ્બેડેડ જેન્ટુ જેવા એમ્બેડેડ લિનક્સ વિતરણો.
નબળાઈ વિશે
નબળાઇ ક્વેરી મોકલવા માટે કોડમાં અનુમાનિત વ્યવહાર ઓળખકર્તાઓના ઉપયોગને કારણે છે DNS ના. DNS ક્વેરી ID ને પોર્ટ નંબરોના વધુ રેન્ડમાઇઝેશન વિના ફક્ત કાઉન્ટરને વધારીને પસંદ કરવામાં આવ્યું હતું, જે DNS કેશને ઝેર કરવાનું શક્ય બનાવ્યું બોગસ પ્રતિસાદો સાથેના UDP પેકેટો આગોતરી રીતે મોકલીને (જો તે વાસ્તવિક સર્વર તરફથી પ્રતિસાદ પહેલાં આવે અને સાચી ઓળખ સમાવિષ્ટ હોય તો પ્રતિભાવ સ્વીકારવામાં આવશે).
2008 માં પ્રસ્તાવિત કામિન્સ્કી પદ્ધતિથી વિપરીત, વ્યવહાર IDનું અનુમાન લગાવવું પણ જરૂરી નથી, કારણ કે તે શરૂઆતમાં અનુમાનિત છે (શરૂઆતમાં, તે 1 પર સેટ છે, જે દરેક વિનંતી સાથે વધે છે, અને રેન્ડમલી પસંદ કરવામાં આવતું નથી).
તમારી જાતને બચાવવા માટે આઈડી અનુમાનની વિરુદ્ધ, સ્પષ્ટીકરણ આગળ નેટવર્ક પોર્ટ નંબરોના રેન્ડમ વિતરણનો ઉપયોગ કરવાની ભલામણ કરે છે મૂળ કે જ્યાંથી DNS ક્વેરી મોકલવામાં આવે છે, જે ID ના અપૂરતા કદ માટે વળતર આપે છે.
જ્યારે પોર્ટ રેન્ડમાઇઝેશન સક્ષમ હોય, ત્યારે ડમી પ્રતિસાદ બનાવવા માટે, 16-બીટ ઓળખકર્તા પસંદ કરવા ઉપરાંત, નેટવર્ક પોર્ટ નંબર પસંદ કરવો પણ જરૂરી છે. uClibc અને uClibc-ng માં, આવા રેન્ડમાઇઝેશનને સ્પષ્ટ રીતે સક્ષમ કરવામાં આવ્યું ન હતું (જ્યારે બાઈન્ડ કહેવામાં આવ્યું હતું, ત્યારે રેન્ડમ સ્ત્રોત UDP પોર્ટનો ઉલ્લેખ કરવામાં આવ્યો ન હતો) અને તેનો અમલ ઑપરેટિંગ સિસ્ટમ ગોઠવણી પર આધારિત હતો.
જ્યારે પોર્ટ રેન્ડમાઇઝેશન અક્ષમ હોય, કઈ વિનંતી આઈડી વધારવી તે નિર્ધારિત કરવું એક તુચ્છ કાર્ય તરીકે ચિહ્નિત થયેલ છે. પરંતુ રેન્ડમાઇઝેશનના કિસ્સામાં પણ, હુમલાખોરે ફક્ત 32768-60999 રેન્જમાંથી નેટવર્ક પોર્ટનો અંદાજ લગાવવાની જરૂર છે, જેના માટે તે વિવિધ નેટવર્ક પોર્ટ્સ પર એકસાથે મોટા પ્રમાણમાં ડમી જવાબો મોકલવાનો ઉપયોગ કરી શકે છે.
સમસ્યા uClibc અને uClibc-ng ના તમામ વર્તમાન સંસ્કરણોમાં પુષ્ટિ થયેલ છે, uClibc 0.9.33.2 અને uClibc-ng 1.0.40 ના નવીનતમ સંસ્કરણો સહિત.
"એ નોંધવું મહત્વપૂર્ણ છે કે પ્રમાણભૂત C લાઇબ્રેરીને અસર કરતી નબળાઈ ખૂબ જટિલ હોઈ શકે છે," ટીમે આ અઠવાડિયે એક બ્લોગ પોસ્ટમાં લખ્યું.
"એક જ પ્રોગ્રામમાં બહુવિધ બિંદુઓ પર નબળા ફંક્શન માટે સેંકડો અથવા હજારો કૉલ્સ હશે એટલું જ નહીં, પરંતુ નબળાઈ તે લાઇબ્રેરીનો ઉપયોગ કરવા માટે ગોઠવેલ અન્ય મલ્ટિ-વેન્ડર પ્રોગ્રામ્સની અનિશ્ચિત સંખ્યાને અસર કરશે."
સપ્ટેમ્બર 2021 માં, નબળાઈ વિશે માહિતી મોકલવામાં આવી હતી સંકલિત એરે તૈયારી માટે CERT/CC ને. જાન્યુઆરી 2022 માં, સમસ્યા 200 થી વધુ ઉત્પાદકો સાથે શેર કરવામાં આવી હતી CERT/CC સાથે સંકળાયેલ.
માર્ચમાં, uClibc-ng પ્રોજેક્ટના જાળવણીકારનો અલગથી સંપર્ક કરવાનો પ્રયાસ કરવામાં આવ્યો હતો, પરંતુ તેણે જવાબ આપ્યો હતો કે તે પોતે નબળાઈને ઠીક કરી શક્યો નથી અને સમસ્યા અંગેની માહિતી જાહેર કરવાની ભલામણ કરી હતી, તેને સુધારવામાં મદદ મેળવવાની આશામાં. સમુદાય. ઉત્પાદકો તરફથી, NETGEAR એ નબળાઈ દૂર કરવા સાથે અપડેટ રિલીઝ કરવાની જાહેરાત કરી.
એ નોંધવું અગત્યનું છે કે પ્રમાણભૂત C લાઇબ્રેરીને અસર કરતી નબળાઈ ખૂબ જટિલ હોઈ શકે છે. એક જ પ્રોગ્રામમાં બહુવિધ બિંદુઓ પર નબળા ફંક્શન માટે સેંકડો અથવા હજારો કૉલ્સ હશે એટલું જ નહીં, પરંતુ નબળાઈ તે લાઇબ્રેરીનો ઉપયોગ કરવા માટે ગોઠવેલા બહુવિધ વિક્રેતાઓના અન્ય પ્રોગ્રામ્સની અનિશ્ચિત સંખ્યાને અસર કરશે.
તે નોંધ્યું છે કે નબળાઈ ઘણા ઉત્પાદકોના ઉપકરણોમાં પોતાને પ્રગટ કરે છે (ઉદાહરણ તરીકે, લિન્કસીસ, નેટગિયર અને એક્સિસના ફર્મવેરમાં uClibc નો ઉપયોગ થાય છે), પરંતુ uClibc અને uClibc-ng માં નબળાઈ અનપેચ્ડ હોવાથી, ઉપકરણો વિશે વિગતવાર માહિતી અને વિશિષ્ટ ઉત્પાદકો કે જેમના ઉત્પાદનોમાં સમસ્યા છે, જ્યાં સુધી તેઓ જાહેર ન થાય ત્યાં સુધી.
છેલ્લે જો તમને તેના વિશે વધુ જાણવામાં રસ છે, તમે વિગતો ચકાસી શકો છો નીચેની કડીમાં