
LXD-სა და MicroCloud-ში CVSS 10.0 ხარვეზი თავდამსხმელებს სანდო კლიენტებად წარდგენის საშუალებას აძლევს
Canonical-მა გამოასწორა CVSS 10.0 ხარვეზი LXD-სა და MicroCloud-ში, რომელიც თავდამსხმელს სანდო კლიენტად შესვლის საშუალებას აძლევს იმ კლიენტის პირადი გასაღების გარეშე, საკმარისია HTTPS API-ზე წვდომა და კლიენტის საჯარო სერტიფიკატი.
Canonical-მა გამოუშვა LXD-ისა და MicroCloud-ის გამოსწორებული ვერსიები კრიტიკული ხარვეზის გამოსასწორებლად, რომელიც თავდამსხმელს სანდო კლიენტად შესვლის საშუალებას აძლევს იმ კლიენტის პირადი გასაღების გარეშე. ხარვეზი CVE-2026-112816 კოდით არის რეგისტრირებული, CVSS შეფასება 10.0-ია და საჭიროებს ქსელურ წვდომას HTTPS API-ზე და სანდო კლიენტის საჯარო სერტიფიკატს. Canonical-ის თქმით, თუ ანგარიში პრივილეგირებულია, თავდამსხმელს ჰოსტ მანქანაზე root წვდომის მიღება შეუძლია.
როგორ მუშაობს ხარვეზი
LXD და MicroCloud API-ებზე წვდომას ურთიერთ TLS-ით აძლევს; კლიენტი სერტიფიკატით ადასტურებს იდენტობას და სანდოა, თუ მისი სერტიფიკატი ნდობის საცავშია. ხარვეზი იმაში იყო, რომ სერვერი კლიენტის მიერ გამოგზავნილ ყველა სერტიფიკატს ადარებდა საცავს, თუმცა TLS მხოლოდ ჯაჭვის პირველი სერტიფიკატის, ფოთლის, პირად გასაღებს ამტკიცებს. დანარჩენ ჯაჭვს კლიენტი თავად ამაგრებს, ამიტომ თავდამსხმელს შეეძლო სანდო კლიენტის საჯარო სერტიფიკატი, რომელიც საიდუმლო არ არის, საკუთარის შემდეგ დაემატებინა და სერვერს იმ კლიენტად მიეღო.
ვის ეხება
ხარვეზის გამოსაყენებლად საჭიროა ქსელური წვდომა HTTPS API-ზე და იმ კლიენტის საჯარო სერტიფიკატი, რომელსაც სერვერი ენდობა. დამოუკიდებელი LXD სერვერი ამ API-ს ნაგულისხმევად არ ამჟღავნებს და მხოლოდ ლოკალურ სოკეტზე უსმენს, თუ core.https_address პარამეტრით ქსელურ API არ ჩაირთვება. MicroCloud-ს, რომელიც რამდენიმე LXD მანქანას აერთიანებს, სუსტი წერტილი აქვს: Canonical-ის თქმით, თავდამსხმელს, რომელიც წევრის საჯარო სერტიფიკატს კლასტერში გაწევრიანების დროს ჩაიგდებს ხელში, შემდეგ ამ წევრად შესვლა შეუძლია. CVE-ის ჩანაწერში დაზარალებულ ვერსიებად მითითებულია LXD 4.0.14, 5.0.10, 5.21.8 და 6.9, თითოეული მათგანი გამოსწორებულ ვერსიამდეა, რომელიც მას მოჰყვება.
გამოსწორებული ვერსიები
Canonical-ის სიაში გამოსწორებული snap-ვერსიებია: LXD 6/stable 6.10.1, LXD 5.21/stable 5.21.9, LXD 5.0/stable 5.0.11, LXD 4.0/stable 4.0.15, MicroCloud 3/stable 3.4.1 და MicroCloud 2/stable 2.1.5. ხარვეზი Canonical-ისგან არ მომდინარეობს: Incus-ის პროექტმა, LXD-ის საზოგადოებრივმა ფორკმა, ის გამოავლინა, და Canonical-მაც დაადასტურა, რომ LXD-საც ეხებოდა. Incus-მა იგივე ხარვეზი 7.6.0-ში გამოასწორა. Ubuntu-ს არქივის LXD პაკეტები დაუზარალებელ ან არ მიწოდებულ პაკეტებადაა მითითებული, ამიტომ გამოსწორებული გამოშვებები snap-ებია. ხარვეზის შეტევაში გამოყენების საჯარო ნიშანი არ არის: CVE-ის ჩანაწერში მოცემულია აშშ-ის CISA-ს 30 ოქტომბრის შეფასება, რომ უცნობია ხარვეზის ექსპლუატაციაში გამოყენების ფაქტი; ის არ არის CISA-ს Known Exploited Vulnerabilities სიაში და მოქმედი ექსპლოიტი არ გამოქვეყნებულა.
რა უნდა გააკეთოთ
განაახლეთ LXD და MicroCloud გამოსწორებულ ვერსიებამდე. snap-ინსტალაციისას გაუშვით sudo snap refresh lxd და sudo snap refresh microcloud. Canonical-ის თქმით, გაფრთხილების დროს გამოსწორებული LXD point-რელიზები ჯერ candidate არხიდან stable-ზე გადადიოდა, ამიტომ განახლების შემდეგ შეამოწმეთ რეალური ვერსია და ნუ ჩათვლით, რომ გამოსწორება უკვე ჩამოვიდა. LXD-ისთვის დროებითი გადაწყვეტა არ არის. ვინაიდან შეტევას API-ზე ქსელური წვდომა სჭირდება, წვდომის შეზღუდვა განახლებამდე რისკს ამცირებს. Incus-ის პროექტმა, რომელმაც იგივე ხარვეზი შეატყობინა, თქვა, რომ კონფიგურაციით გამოსწორება არ არსებობს და მხოლოდ მსმენელზე ქსელური წვდომის შეზღუდვა შველის. Incus-ის მომხმარებლებმა 7.6.0-ზე უნდა გადავიდნენ, რომელმაც ეს ხარვეზი 17 სხვა უსაფრთხოების პრობლემასთან ერთად გამოასწორა.
წყაროები: The Hacker News
SiTech — AI-გაძლიერებული ვებ დეველოპმენტი
ვქმნით სწრაფ, თანამედროვე ვებსაიტებს და AI-ს ვაერთიანებთ ქართული ბიზნესებისთვის. გაქვთ პროექტი ან კითხვა? სიამოვნებით დაგეხმარებით.