AMD-ის ოფიციალური პროგრამული უზრუნველყოფა, რომელიც სისტემის განახლებებზეა პასუხისმგებელი, სერიოზული უსაფრთხოების ხარვეზს შეიცავდა. პრობლემა, რომელიც დისტანციური კოდის შესრულების (RCE) საშუალებას იძლეოდა, დამოუკიდებელმა მკვლევარმა მას შემდეგ აღმოაჩინა, რაც მის კომპიუტერზე AMD AutoUpdate-ის შემაწუხებელმა ფანჯრებმა სისტემატური ხასიათი მიიღო.

კვლევის პროცესში გაირკვა, რომ პროგრამა განახლებებს HTTP პროტოკოლის მეშვეობით ეძებდა. ეს კი ნიშნავს, რომ ქსელში მყოფ თავდამსხმელს მარტივად შეეძლო „შუამავლის“ (MITM) შეტევის განხორციელება და რეალური განახლების ჩანაცვლება მავნე ფაილით.

კრიტიკული პრობლემა ის იყო, რომ AutoUpdate-ის პროგრამა ჩამოტვირთულ ფაილებს არანაირი კრიპტოგრაფიული ხელმოწერით არ ამოწმებდა. სისტემა უბრალოდ ასრულებდა ნებისმიერ ფაილს, რომელსაც სერვერიდან მიიღებდა.

მკვლევარმა აღმოჩენის შესახებ კომპანიას მიაწოდა ინფორმაცია, თუმცა თავდაპირველად AMD-ის მხრიდან პასუხი უარყოფითი იყო. მათი განცხადებით, MITM ტიპის შეტევები კომპანიის „Bug Bounty“ პროგრამის ფარგლებს გარეთ იყო.

სიტუაცია მას შემდეგ შეიცვალა, რაც საკითხი „Hacker News“-ზე გავრცელდა. AMD-მ აღიარა პრობლემა და მკვლევარს ინფორმაციის დროებით დამალვა სთხოვა, თუმცა უარი თქვა ფულად ანაზღაურებაზე, რადგან ინსტრუმენტი „არასავალდებულო“ იყო.

საინტერესოა, რომ პროცესი 124 დღე გაგრძელდა. მკვლევარის თქმით, მთელი ამ ხნის განმავლობაში კომპანია კომუნიკაციაში პასიური იყო და მხოლოდ ვადების ამოწურვამდე რამდენიმე დღით ადრე დააზუსტა გამოსწორების გზები.

თუმცა, სიტუაცია გაცილებით პარადოქსულია. როგორც გაირკვა, AutoUpdate-ის პროგრამას აქვს მეორე, დამოუკიდებელი ხარვეზიც: დომენის შეცვლის გამო, პროგრამა ვეღარ ხედავს განახლებების ახალ მისამართებს და ავარიულად ითიშება. შედეგად, პროგრამა ვერც კი აღწევს იმ კოდამდე, სადაც უსაფრთხოების ხარვეზია, რადგან მანამდე თავად განახლების სერვისი იჭედება.

საბოლოო ჯამში, AMD-მ დაუცველობა HTTPS-ზე გადასვლით „მოაგვარა“, თუმცა მკვლევარის შემოწმებით, კრიპტოგრაფიული ხელმოწერის ვალიდაცია კვლავ არ ხდება — კომპანია იყენებს მხოლოდ CRC-32 შემოწმებას, რაც უსაფრთხოების სტანდარტებს არ შეესაბამება.