પ્રોજેક્ટ ઝીરોએ ગિટહબ પર ગંભીર સુરક્ષા ભંગની વિગતો પ્રકાશિત કરી છે અને તેઓ અહેવાલ આપે છે ભૂલ ક્રિયા વર્કફ્લો આદેશોને અસર કરે છે ગિટહબથી અને ઉચ્ચ તીવ્રતા તરીકે વર્ણવવામાં આવે છે. (આ ભૂલ જુલાઈમાં મળી આવી હતી, પરંતુ માનક 90-દિવસીય જાહેરાત સમયગાળા હેઠળ, વિગતો ફક્ત હવે જારી કરવામાં આવી છે.)
આ ખામી એ કેટલીક નબળાઈઓમાંથી એક બની ગઈ જે નિશ્ચિત નહોતી ગૂગલ પ્રોજેક્ટ ઝીરો દ્વારા આપવામાં આવેલ પ્રમાણભૂત 90-દિવસીય સમયમર્યાદા પહેલાં યોગ્ય રીતે.
ફેલિક્સ વિલ્હેમ અનુસાર (જેણે તેને શોધી કા )્યો), પ્રોજેક્ટ ઝીરો ટીમના સભ્ય, ખામી એ ગિટહબની ક્રિયાઓની સુવિધાને અસર કરે છે, જે વિકાસકર્તાઓના કાર્યને સ્વચાલિત કરવાનું સાધન છે. આ કારણ છે કે ક્રિયાઓનો વર્કફ્લો આદેશો "ઇન્જેક્શનના હુમલાઓ માટે સંવેદનશીલ" છે:
“ક્રિયાઓ ગીથબ એક્શન બ્રોકર અને એક્ઝેક્યુટ કરેલી ક્રિયા વચ્ચેની સંદેશાવ્યવહાર ચેનલ તરીકે વર્કફ્લો આદેશો તરીકે ઓળખાતી સુવિધાને સમર્થન આપે છે. વર્કફ્લો આદેશો / src / રનર.વર્કર / એક્શનકોમન્ડ મેનેજર.સી. માં અમલમાં મૂકાયા છે અને તે બે કમાન્ડ માર્કર્સમાંથી એક શોધીને કરવામાં આવતી બધી ક્રિયાઓના STDOUT ને વિશ્લેષણ કરીને કાર્ય કરે છે.
તેનો ઉલ્લેખ કરો આ સુવિધા સાથેની મોટી સમસ્યા એ છે કે તે ઇન્જેક્શનના હુમલાથી ખૂબ જ સંવેદનશીલ છે. કારણ કે એક્ઝેક્યુશન પ્રક્રિયા વર્કફ્લો આદેશો માટે STDOUT માં છપાયેલી દરેક પંક્તિને સ્કેન કરે છે, તેથી દરેક GitHub ક્રિયા જેમાં તેના અમલના ભાગ રૂપે અવિશ્વાસવાળી સામગ્રી હોય છે તે સંવેદનશીલ છે.
મોટા ભાગના કિસ્સાઓમાં, મનસ્વી વાતાવરણના ચલોને સુયોજિત કરવાની ક્ષમતા દૂરસ્થ કોડ એક્ઝેક્યુશનમાં તરત જ બીજો વર્કફ્લો ચાલે છે. મેં લોકપ્રિય ગીટહબ રીપોઝીટરીઓ અને લગભગ કોઈ પણ પ્રોજેક્ટ કે જે સહેજ જટિલ ગીટહબ ક્રિયાઓનો ઉપયોગ કરે છે તે જોવા માટે થોડો સમય પસાર કર્યો છે, આ પ્રકારની બગ માટે સંવેદનશીલ છે.
પાછળથી બગનો ઉપયોગ કેવી રીતે થઈ શકે તેના કેટલાક ઉદાહરણો આપ્યા અને સમાધાન સૂચવ્યું:
“મને ખરેખર ખાતરી નથી કે તેને સુધારવા માટેની શ્રેષ્ઠ રીત કઈ છે. મને લાગે છે કે જે રીતે વર્કફ્લો આદેશો લાગુ કરવામાં આવ્યા છે તે મૂળભૂત રીતે અસુરક્ષિત છે. V1 આદેશ વાક્યરચનાને અવમૂલ્યન કરવું અને પરવાનગી સૂચિ સાથે મજબૂતીકરણ-env કદાચ સીધા આરસીઈ વેક્ટર્સની વિરુદ્ધ કાર્ય કરશે.
“જો કે, પછીના પગલામાં ઉપયોગમાં લેવામાં આવતા 'સામાન્ય' પર્યાવરણ ચલોને ફરીથી લખવાની ક્ષમતા પણ વધુ જટિલ ક્રિયાઓનું શોષણ કરવા માટે પૂરતી છે. કે મેં વર્કસ્પેસમાંના અન્ય નિયંત્રણોની સુરક્ષા અસરનું વિશ્લેષણ કર્યું નથી.
બીજી તરફ, એક સારા લાંબા ગાળાના સોલ્યુશનનો ઉલ્લેખ કરો STDOUT દ્વારા પદચ્છેદન ટાળવા માટે, વર્કફ્લો આદેશોને અલગ ચેનલ (દા.ત. નવી ફાઇલ વર્ણનકર્તા) પર ખસેડવાની રહેશે, પરંતુ આ ઘણાં હાલના એક્શન કોડને તોડી નાખશે.
ગિટહબની વાત કરીએ તો, તેના વિકાસકર્તાઓએ 1 ઓક્ટોબરના રોજ એક સલાહકાર પોસ્ટ કર્યો હતો અને નબળા આદેશોને નકારી કા .્યા હતા, પરંતુ દલીલ કરી હતી કે વિલ્હેમ જે શોધી કા factે છે તે હકીકતમાં "મધ્યમ સુરક્ષા નબળાઈ" છે. ગિટહબને ભૂલ ઓળખકર્તા સીવીઇ -2020-15228 સોંપેલ છે:
"ગિટહબ ક્રિયાઓ રનટાઈમમાં એક મધ્યમ સુરક્ષા નબળાઈને ઓળખવામાં આવી છે જે પાથ અને પર્યાવરણના ચલોના ઇન્જેક્શનને વર્કફ્લોઝમાં મંજૂરી આપી શકે છે જે STDOUT પર અવિશ્વસનીય ડેટા લ logગ કરે છે. આ વર્કફ્લો લેખકના હેતુ વિના પર્યાવરણ ચલોની રજૂઆત અથવા ફેરફાર તરફ દોરી શકે છે.
“અમને આ સમસ્યા હલ કરવામાં મદદ કરવા અને તમને ગતિશીલ રીતે પર્યાવરણ ચલો સેટ કરવાની મંજૂરી આપવા માટે, અમે વર્કફ્લોમાં પર્યાવરણ અને પાથ અપડેટ્સને હેન્ડલ કરવા ફાઇલોનો નવો સેટ રજૂ કર્યો છે.
“જો તમે સ્વ-હોસ્ટેડ બ્રોકર્સનો ઉપયોગ કરી રહ્યાં છો, તો ખાતરી કરો કે તેઓ 2.273.1 અથવા તેથી વધુ સંસ્કરણ પર અપડેટ થયા છે.
વિલ્હેમના જણાવ્યા અનુસાર, 12 Octoberક્ટોબરે, પ્રોજેક્ટ ઝીરોએ ગિટહબનો સંપર્ક કર્યો અને જો ગિટબબ નબળા આદેશોને અક્ષમ કરવા માટે વધુ સમય માંગતો હોય તો તેમને સક્રિયપણે 14-દિવસીય વિંડોની offeredફર કરી. અલબત્ત, offerફર સ્વીકારવામાં આવી હતી અને ગિટહબ 19 Octoberક્ટોબર પછી નબળા આદેશોને અક્ષમ કરવાની આશામાં હતા. પ્રોજેકટ ઝીરો પછી નવેમ્બર 2 માટે નવી જાહેરાત તારીખ સેટ કરી.
સ્રોત: https://bugs.chromium.org