მსოფლიოს მასშტაბით უსაფრთხოების სპეციალისტებს კიდევ ერთი უხარისხოდ გამჟღავნებული კოდის შესრულების ხარვეზის გამოსწორება უწევთ. ამჯერად პრობლემა ჩატვირთვისას გამოყენებულ პროგრამულ უზრუნველყოფაშია, რომელსაც სერვერების მწარმოებლებისა და მონაცემთა ცენტრების უმეტესობა იყენებს.
ხარვეზი TianoCore EDK II-ის ღია კოდის ბაზაშია. აპარატურის მწარმოებლები და ღრუბლოვანი მომსახურების მიმწოდებლები მას UEFI პროგრამული უზრუნველყოფის შესაქმნელად იყენებენ, რომელიც მოწყობილობის ჩატვირთვისას მუშაობს. ხარვეზის სიმძიმე 10-დან 9,5 ქულით შეფასდა. გასულ წელს UEFI Forum-ის წარმომადგენელმა EDK2-ს UEFI-ის სპეციფიკაციების „წამყვანი გადაწყვეტა და განხორციელება“ უწოდა. UEFI-ის თითქმის ყველა მიმწოდებელი, რომლებსაც ზოგჯერ დამოუკიდებელ BIOS-მომწოდებლებსაც უწოდებენ, მათ შორის AMI, Insyde და Phoenix, ამ საცნობარო კოდს ფართოდ იყენებს. Microsoft-ის მიერ გამაგრებული EDK2-ის განშტოება Project Mu-ც შეიცავდა მოწყვლად კომპონენტს.
CVE-2026-97631-ად აღრიცხული ხარვეზი ICMP კომპონენტში მეხსიერების დაზიანებას იწვევს. თავდამსხმელებს მისი გამოყენებით მავნე კოდის გაშვება შეუძლიათ მანამდე, სანამ ოპერაციული სისტემა და პროგრამული უზრუნველყოფა ისეთ დაცვას აამოქმედებს, როგორიცაა Secure Boot. ის სანდოობის ჯაჭვს ადგენს ჩატვირთვისას ჩატვირთული ყველა კოდისთვის, მათ შორის სანდო პლატფორმის მოდულისთვის (TPM). საბოლოო მავნე კოდი მუდმივად არ ნარჩუნდება, ანუ მხოლოდ ერთხელ მუშაობს, მაგრამ თავდამსხმელებს სხვა კოდის დასაყენებლად ფართო შესაძლებლობას აძლევს. ეს კოდიც ჩატვირთვის საწყის ეტაპზე გაეშვება.
CVE-2026-97631-ის აღმომჩენებმა, Anthropic-ის ალექს მატროსოვმა და Google-ის დენ ჰოლმსმა, შეთანხმდნენ, ხარვეზის შესახებ ინფორმაცია იანვარში დაგეგმილ კოორდინირებულ გამჟღავნებამდე საიდუმლოდ შეენახათ. დედაპლატებისა და სხვა აპარატურის მწარმოებელმა AMI-მ გასულ თვეში გამოაქვეყნა მოთხოვნა კოდში ცვლილების შესატანად. მასში აღწერილი იყო ხარვეზი და გამოსასწორებელი კოდიც იყო დართული. მას შემდეგ, რაც აღმომჩენებმა ეს პოსტი შენიშნეს, TianoCore Project-ის წევრებმა გასულ კვირას საჯარო გაფრთხილება გამოაქვეყნეს.
საჯაროდ ხელმისაწვდომი გამოსასწორებელი კოდის გამო გამოცდილი ჰაკერებისთვის მარტივი იქნება ხარვეზის ამოქმედების გზის გაგება და მოქმედი თავდასხმის საშუალებების შექმნა. გადაუდებლობას ისიც ზრდის, რომ მილიონობით საბოლოო მოწყობილობაში UEFI კოდის ხარვეზის გამოსწორება რთული და დროში გაწელილი პროცესია. ამ მოწყობილობებს ათასობით აპარატურის მწარმოებელი და ღრუბლოვანი მომსახურების მიმწოდებელი ყიდის და იყენებს. ხარვეზის შესახებ ინფორმაცია კიდევ ერთი უხარისხოდ გამჟღავნებული შემთხვევიდან ექვს დღეში გავრცელდა. წინა შემთხვევა PHP პროგრამირების ენაში კოდის შესრულების კრიტიკულ ხარვეზს ეხებოდა.
„EDK2-ის ქსელური დასტის ICMP პარსერში ეს ხარვეზი საინტერესოა იმით, თუ როგორ მოქმედებს სანდოობის ჯაჭვსა და უფრო ფართო ეკოსისტემაზე“, განაცხადა Metasploit-ის შემქმნელმა და უსაფრთხოების კომპანია Dragos-ის კვლევების მთავარმა ოფიცერმა, ჰ. დ. მურმა. „თავდამსხმელს, რომელსაც ახლომდებარე საბოლოო მოწყობილობის ან სერვერის ხელში ჩაგდება სურს, შეუძლია ამ ხარვეზით პროგრამის შესრულების მართვა იმ ეტაპზე ჩაიგდოს ხელში, როცა ჩატვირთვის პროცესს ჯერ კიდევ მიუწვდება ხელი მგრძნობიარე კომპონენტებთან, მაგალითად, მოწყობილობის TPM-თან. ამან შეიძლება დისკის დაშიფვრის გატეხვა შესაძლებელი გახადოს იმ შემთხვევაში, როცა თავდამსხმელს ქსელზე მოკლევადიანი წვდომა აქვს. მოპარვის შემთხვევაში კი ეს კიდევ უფრო ადვილი იქნება“.
CVE-2026-97631 16 წლის ბუფერის გადავსების ხარვეზია PXE-Base Code დრაივერში (NetworkPkg/UefiPxeBcDxe). ეს დრაივერი სერვერებს, მონაცემთა შესანახ მოწყობილობებსა და სხვა აპარატურას ადგილობრივი ქსელიდან ჩამოტვირთული კოდით ჩატვირთვის საშუალებას აძლევს. წინასწარი შესრულების გარემოს ჩატვირთვისას დრაივერი ქსელურ მსმენელს იყენებს ICMP შეცდომების დასაკვირვებლად. დრაივერი მეხსიერებაში კოპირებულ მონაცემებს 504 ბაიტამდე არ ზღუდავს. ამიტომ მავნე შიდა მომხმარებელს ან ჰაკერს, რომელსაც ადგილობრივ ქსელში დაბალი დონის წვდომა აქვს, შეუძლია შეცდომის შეტყობინებით კოდი ამ ზღვარს გადააცილოს და მეზობელი მონაცემები გადაწეროს. შედეგად, პროცესორზე მომუშავე IUEFI მოდული ზიანდება.
ქსელიდან ჩატვირთვისას PXE Base Code დრაივერი (NetworkPkg/UefiPxeBcDxe) ICMP შეცდომების მიღების მოთხოვნას ღიას ტოვებს და თითოეულ შეტყობინებას თავისი კონტექსტის სტრუქტურის ფიქსირებული, 504 ბაიტიანი Mode.IcmpError ველში აკოპირებს. IPv4-ისა და IPv6-ის დამმუშავებლებში, PxeBcIcmpErrorDpcHandle-სა და PxeBcIcmp6ErrorDpcHandle-ში, კოპირების ციკლის საზღვრები არასწორადაა დამუშავებული. 504 ბაიტზე გრძელი შეტყობინების დროსაც კოდი ველში მონაცემებს აგრძელებს. ამასთან, მიმღების მისამართს ფრაგმენტების სიგრძის ნაცვლად მათი ჯამური სიგრძით ზრდის. შედეგად, ზედმეტად გრძელი შეტყობინება ველის მიღმაც წერს თავდამსხმელის მიერ კონტროლირებულ ბაიტებს. მიღების გზაზე მანამდე შეტყობინების სიგრძეს არაფერი ზღუდავს.
მავნე შეცდომის შეტყობინების გაგზავნა შესაძლებელია ნებისმიერი ქსელური მანძილიდან, სამიზნე მოწყობილობის IP მისამართზე მარტივი ერთმიმართულებიანი შეტყობინების გაგზავნით, თუ ეს PXE ჩატვირთვისას მოხდება. თავდამსხმელს შეუძლია მომსახურების უარყოფის შეტევა განახორციელოს და ჩატვირთვის პროცესი გააჩეროს. თუ თავდამსხმელმა სამიზნე პროგრამული უზრუნველყოფის აგებულება იცის, მას შეუძლია „ყალბი მოვლენის“ ჩასმა, რომელიც პროცესორზე მავნე კოდს გაუშვებს UEFI გარემოში. კოდი მუშაობს ring 0-ში, პროცესორის ყველაზე მაღალი პრივილეგიების მქონე დონეზე. ამგვარი თავდასხმები გვერდს უვლის ატესტაციის პროცესებს, რომლებიც დისტანციურ სერვერებს კრიპტოგრაფიულად უდასტურებს აპარატურის უსაფრთხოებას. ამიტომ ისინი შეზღუდული პრივილეგიების გასაზრდელად მნიშვნელოვან შესაძლებლობას ქმნის.
CVE-2026-97631 UEFI-ში ან მასთან მჭიდროდ დაკავშირებულ კოდში აღმოჩენილი ხარვეზების გრძელ სიას ემატება. მათგან ყველაზე მძიმე LogoFail-ი თითქმის ყველა აპარატურის მწარმოებლის UEFI-ში შეტანილ ლოგოებს უკავშირდებოდა. გამოსახულების დამუშავების შეცდომები თავდამსხმელებს საშუალებას აძლევდა, გვერდი აევლოთ UEFI-ის მიერ დაცული სანდოობის ჯაჭვისთვის და ოპერაციული სისტემის ჩატვირთვამდე ან Secure Boot-ის ამოქმედებამდე მავნე კომპონენტები დაეყენებინათ. PixieFail CVE-2026-97631-ის მსგავსი ხარვეზი იყო და ისიც EDK2-ში PXE ჩატვირთვის შეცდომებმა გამოიწვია. მისი აღმოჩენის შემდეგ მკვლევრებმა ღია კოდის ბიბლიოთეკაში სხვა კრიტიკული ხარვეზების გამოსავლენად რამდენიმე ფაზინგ-პროექტი დაიწყეს. როგორც ჩანს, ამ მცდელობებმა უახლესი ხარვეზი ვერ გამოავლინა.
CVE-2026-97631-ის მსგავსად, ამ ტიპის კოდის გამოყენება თავდამსხმელებს იმიტომ იზიდავს, რომ მანქანების ჩატვირთვის დასაწყისშივე აინფიცირებს, სანამ TPM და სხვა დაცვის მექანიზმები ჩაიტვირთება, და ამით მაქსიმალური ზიანის მიყენების საშუალებას აძლევს. მური ამბობს, რომ ხარვეზი, სავარაუდოდ, „სამუდამოდ“ დარჩება სისტემებში, რომელთა მხარდაჭერის ვადაც ამოიწურა.
ამ ხარვეზის გამოყენებას მნიშვნელოვანი წინაპირობები და შეზღუდვები აქვს. როგორც აღინიშნა, თავდამსხმელს ადგილობრივ ქსელზე გარკვეული კონტროლი სჭირდება. ამიტომ, სავარაუდოდ, ხარვეზის გამოყენება მხოლოდ შიდა მომხმარებლებს ან ისეთ თავდამსხმელებს შეეძლებათ, როგორებიც არიან სახელმწიფოები და გამოსასყიდი პროგრამების ოპერატორები. მათ ჯერ ქსელში დაბალი დონის წვდომის მოპოვება, შემდეგ კი სისტემის უფლებების გაზრდის გზა უნდა იპოვონ. ჯერჯერობით არაფერი ადასტურებს, რომ CVE-2026-97631 ქსელში თავდაპირველად შეღწევის საშუალებას იძლევა. თავდამსხმელს სხვა დაბრკოლებების გადალახვაც მოუწევს.
„თავად ხარვეზის გამოსაყენებლად თავდამსხმელმა სამიზნე სისტემის კონკრეტული მისამართები უნდა გამოიცნოს. ამიტომ ერთი თავდასხმის საშუალების გამოყენებით სხვადასხვა მოწყობილობაზე კოდის დისტანციურად შესრულება შეუძლებელია. საჭიროა მისი მორგება თითოეული სამიზნე მოდელის, ვერსიისა და კონფიგურაციისთვის, რადგან მისამართები ამ მახასიათებლების მიხედვით იცვლება“, განუცხადა Ars-ს firmware-ის უსაფრთხოების კომპანია Eclypsium-ის მთავარმა მკვლევარმა ჯესი მაიკლმა.
„ზოგიერთი წინა, გახმაურებული ხარვეზისგან, მაგალითად BootHole-ის, Black Lotus-ისა და Baton Drop-ისგან განსხვავებით, ამ ხარვეზის გამოსასწორებლად კოდის მარტივი შესწორებაა საჭირო. ამისთვის BIOS/UEFI განახლება უნდა დაინერგოს, მაგრამ საჭირო არ არის გაუქმებების, pk/kek/db/dbx გასაღებების მართვის განახლებების ან ოპერაციული სისტემისა და ჩატვირთვის საშუალებების განახლება, როგორც ეს თავად ჩატვირთვის პროგრამაში Secure Boot-ის გვერდის ავლისას ხდება“.
CVE-2026-97631 სახლისა და მცირე ოფისების მომხმარებლებს, ან სხვა მომხმარებლებს, რომლებიც მოწყობილობებს მხოლოდ დისკიდან ტვირთავენ, არ ეხება. ხარვეზი მხოლოდ იმ ორგანიზაციებს ეხება, რომელთა მანქანებიც ადგილობრივი ქსელიდან ან, შესაძლოა, ინტერნეტთან დაკავშირებული რესურსებიდან იტვირთება. ამ შემთხვევაშიც სამიზნე პროგრამულ უზრუნველყოფაში EDK2 უნდა იყოს გამოყენებული და არა სხვა საცნობარო განხორციელება. მასში ასევე ჩართული უნდა იყოს PXE ფუნქცია, რომელიც ნაგულისხმევად ჩართულია.
Intel-მა ელფოსტით განაცხადა, რომ მის „ამჟამად უსაფრთხოების მხარდაჭერაში მყოფ კომერციულ პროდუქტებს“ ხარვეზი, როგორც ცნობილია, არ ეხება. კომპანიამ დასძინა, რომ Intel-ის საცნობარო კოდი დაზიანებულ EDK2 ფუნქციონალს არ შეიცავს, თუმცა ის შეიძლება დედაპლატის OEM მწარმოებელმა ან სისტემის მწარმოებელმა დაამატოს. Intel-მა მომხმარებლებს კონკრეტული მითითებების მისაღებად სისტემის მწარმოებელთან დაკავშირება ურჩია. თუმცა Intel-ის საჯაროდ ხელმისაწვდომ საცნობარო კოდში EDK2 არის ნახსენები. ამასთან, TianoCore-ის თანახმად, Intel-ის მიერ მოწოდებული UEFI-ის თითოეული დეველოპერული ნაკრები EDK II-ის წყაროს კონკრეტული ვერსიის „სრულად შემოწმებული განხორციელებაა“. Intel-ის სხვა დოკუმენტებშიც არაერთხელ არის ნახსენები EDK2.
Arm-მა კითხვების ჩამონათვალს ასე უპასუხა: „CVE-2026-97631 უშუალოდ Arm-ის პროდუქციის პორტფელს არ ეხება“. Intel-ის მსგავსად, კომპანიის მიერ ხელმისაწვდომი პროგრამული უზრუნველყოფაც ფართოდ ეყრდნობა EDK2-ს. TianoCore-ს Arm-ის მიერ EDK2-ის გამოყენებაც აქვს აღწერილი.
შესაძლებელია, ზოგი პლატფორმა EDK2-ის კოდს არ შეიცავდეს, თუმცა ყველა სერვერის მომხმარებელმა უნდა შეამოწმოს, ეხება თუ არა მათ CVE-2026-97631.
AMD-ის, Phoenix Technologies-ის, AMI-ის, Microsoft-ისა და Amazon-ისთვის, რომლებიც, სავარაუდოდ, ხარვეზით დაზარალებულ უმსხვილეს ორგანიზაციებს შორის არიან, გაგზავნილ კითხვებს ამ სტატიის გამოქვეყნების დროისთვის პასუხი არ მოჰყოლია. ამ ორგანიზაციებში EDK2-ის გამოყენების შესახებ კონკრეტული პასუხების გარეშე შეუძლებელია იმის თქმა, რომელ მოწყობილობებს და როგორ ეხება ხარვეზი, ან რა ნაბიჯები უნდა გადადგან თავად ორგანიზაციებმა თუ მათმა მომხმარებლებმა. TianoCore Project-ის წარმომადგენლებმაც არ უპასუხეს.
ზოგი მკითხველი, სავარაუდოდ, ინფორმაციის სიმწირით უკმაყოფილო დარჩება. ზოგჯერ, განსაკუთრებით მაშინ, როცა დაგეგმილ ვადამდე თვითნებური გამჟღავნება რამდენიმე თვით ადრე არღვევს ემბარგოს, პირველადი ინფორმაციის გამოქვეყნებისას გამოსადეგი მითითებების ნაკლებობის თავიდან აცილება შეუძლებელია.
დაზარალებულმა ორგანიზაციებმა უნდა დაუკავშირდნენ პროგრამული უზრუნველყოფის მწარმოებელს, რომელსაც მათი სისტემები ჩატვირთვისას იყენებს, და რჩევა სთხოვონ. გარდა ამისა, თუ შესაძლებელია, დროებით უნდა გამორთონ ქსელიდან ჩატვირთვის შესაძლებლობა. პროგრამული უზრუნველყოფის კონფიგურაციებში ყოველთვის უნდა იყოს ჩართული უსაფრთხოების ფუნქციები, მათ შორის TPM და Secure Boot, თუ ამის შესაძლებლობა არსებობს, თუმცა ეს დაცვა კონკრეტული საფრთხისგან არ იცავს. ასევე სასურველია, ჩანაწერებში თავდასხმის მცდელობის ნიშნებს დააკვირდნენ.
კომენტარი (0)
გაგვიზიარე შენი აზრი.
კომენტარები ავტომატურად მოწმდება.
აზრის გასაზიარებლად შექმენი ანგარიში ან შედი.
კომენტარები ჯერ არ არის. დაწერე პირველი.