უკან დაბრუნება

კრიტიკული ავთენტიფიკაციამდელი MongoDB-ის ხარვეზი (CVE-2026-118383) შეიძლება ჩამოაგდოს ჩამორჩენილი სერვერები გადართვისას
SiTech AI Team3 წთ. საკითხავი

კრიტიკული ავთენტიფიკაციამდელი MongoDB-ის ხარვეზი (CVE-2026-118383) შეიძლება ჩამოაგდოს ჩამორჩენილი სერვერები გადართვისას

MongoDB-მ გამოუშვა CVE-2026-118383-ის გასწორებები, კრიტიკული ავთენტიფიკაციამდელი use-after-free ხარვეზი, რომელსაც შეუძლია ჩამოაგდოს replica set-ის წევრი, თუ ის არჩევნებს მოიგებს ჩამორჩენილ მდგომარეობაში ორი ავთენტიფიკაციამდელი ping მოთხოვნის შემდეგ.

MongoDB-მ გამოუშვა გასწორებული ვერსიები CVE-2026-118383-ისთვის, MongoDB Server-ის კრიტიკული ავთენტიფიკაციამდელი ხარვეზისთვის, რომელსაც შეუძლია ჩამოაგდოს replica set-ის წევრი, თუ ის არჩევნებს მოიგებს რეპლიკაციაზე ჩამორჩენილი მდგომარეობით ორი ავთენტიფიკაციის გარეშე მოთხოვნის მიღების შემდეგ. ხარვეზი use-after-free ტიპისაა და CVSS 4.0 სკალით 9,5 ქულითაა შეფასებული. დაზარალებული წევრები მოიცავს replica set-ის წევრებს და sharded კლასტერების shard-ის და config server-ის წევრებს, ხოლო ცალკე mongod არ არის დაზარალებული.

როგორ მუშაობს ხარვეზი

დაზარალებულ ვერსიებში ავთენტიფიკაციის ჩართვა არ აჩერებს ორ მოთხოვნას. ისინი ping ბრძანებებია readConcern.afterOpTime მნიშვნელობით და თითოეული სთხოვს სერვერს დაელოდოს, სანამ რეპლიკაცია მიაღწევს გარკვეულ წერტილს, რითაც იქმნება მოლოდინის შეტყობინება, რომელსაც waiter ეწოდება. waiters არ იწურება და რჩება, სანამ წევრი არ გადაიტვირთება, არ მოხდება rollback, ან არ დატოვებს primary-ის როლს. ჩამოგდება ხდება, როცა მოთხოვნები მიმღები წევრი მოგვიანებით მოიგებს არჩევნებს მიუხედავად იმისა, რომ სხვა წევრს ჩამორჩება; catch-up-ის დასრულებისას cleanup ორჯერ სრულდება და გათავისუფლებულ მეხსიერებას ხელმეორედ იყენებს, რაც ახალ primary-ს ჩამოაგდებს ჩაწერების მიღებამდე. მკვლევრებმა თქვეს, რომ ამ პირობების შესრულების შემდეგ ჩამოგდება დროის რბოლაში მოგებაზე არ არის დამოკიდებული, ხოლო თავდამსხმელს არ შეუძლია სამიზნე წევრი ჩამორჩენილად გახადოს ან არჩევნები მოაგებინოს, ან დაინახოს, როდის ხდება ეს.

დაზარალებული ვერსიები და გასწორებები

MongoDB-მ თითოეულ დაზარალებულ შტოში გამოუშვა გასწორებული ვერსია, და შტოს პირველი გამოშვებიდან ყველა უფრო ადრეული ვერსია დაზარალებულია. თვითმართულ განლაგებებს სჭირდებათ გასწორებული გამოშვება ყველა replica set-ის წევრზე, ხოლო განახლების შემდეგ ადმინისტრატორებმა უნდა შეამოწმონ, რომელ ვერსიას უშვებს თითოეული წევრი, მათ შორის კონტეინერებში მყოფი წევრები და ნებისმიერი, რომელიც ტექნიკური მომსახურების დროს ოფლაინ იყო. MongoDB Atlas-ის კლასტერები ავტომატურად იღებენ გასწორებულ ვერსიებს ტექნიკური მომსახურების დროს, ხოლო მომხმარებლებმა, რომლებიც ტექნიკურ მომსახურებას გადადებენ, უნდა განახორციელონ განახლება რაც შეიძლება მალე. 8.2 შტო არ არის ჩამოთვლილ დაზარალებულ ვერსიებს შორის, ხოლო მისი უახლესი გამოშვებაა 8.2.12, თუმცა GitHub-ზე გამოქვეყნებული proof of concept-ი იუწყება, რომ 8.2.12-მა ლაბორატორიულ ტესტში კვლავ გამოავლინა ხარვეზი ტესტირებისთვის განკუთვნილი პარამეტრის გამოყენებით. კომპანიის ცხოვრების ციკლის გრაფიკის მიხედვით, 8.2 შტოს მხარდაჭერა დასრულდა 31 ივლისს.

გამოვლენა და შემსუბუქება

სანამ წევრის განახლება შესაძლებელი გახდება, მკვლევრები რჩევენ, რომ მონაცემთა ბაზის ქსელური წვდომა შეიზღუდოს მხოლოდ იმ სისტემებისთვის, რომლებსაც ის სჭირდებათ; ეს ზღუდავს, ვის შეუძლია ორი მოთხოვნის გაგზავნა, მაგრამ ხარვეზს არ ასწორებს. waiters-ის განთავსების ან ავარიული გაჩერების მოსაძებნად შეამოწმეთ სტრუქტურირებული ჟურნალები: COMMAND Slow query ჩანაწერი ID 51803-ით არაავტორიზებული ping-ისთვის, რომელიც შეიცავს readConcern.afterOpTime-ს და დასრულდა MaxTimeMSExpired-ით; წევრის შესვლა primary catch-up-ში ID 21359-ით და შემდეგ მისი ორჯერ გამოსვლა ID 21363-ით ერთ გადასვლაში; და ფატალური სიგნალი ან backtrace, რომელიც შეიცავს CatchupState::abort_inlock()-ს ამ გამოსვლების შემდეგ. მოთხოვნები შეიძლება გადართვამდე მივიდეს, ამიტომ იმავე წევრის უფრო ადრეული ჟურნალებიც უნდა შემოწმდეს.

კოდის შესრულების მტკიცებები

MongoDB ამბობს, რომ ხარვეზმა გარკვეულ პირობებში შეიძლება სერვერის პროცესში ნებისმიერი კოდის შესრულება გამოიწვიოს. ლაბორატორიაში მკვლევრებმა თქვეს, რომ კოდის შესრულება ვერ მიაღწიეს, და მათი შედეგები არ აჩვენებს, რამდენად ხშირად იმუშავებდა შეტევა სხვა კონფიგურაციებში. proof-of-concept კოდი ხარვეზს ლაბორატორიულ replica set-ში აღადგენს; მისი საიმედო რეჟიმი მოითხოვს მხოლოდ ტესტირებისთვის განკუთვნილ პარამეტრს, რომლის ჩართვა დისტანციურ შემტევს არ შეუძლია, ხოლო მისი განცხადებული ზემოქმედება არის ავარიული გაჩერება ან მეხსიერების დაზიანება. proof-of-concept ლაბორატორიულ ტესტში, როდესაც ავტენტიფიკაცია გამორთული იყო, გასწორებულმა 8.0.37-მა მიიღო განთავსებული waiters, მაგრამ გაწმენდა მხოლოდ ერთხელ შეასრულა.

წყაროები: The Hacker News

გააზიარე ციფრული გამოცდილება

SiTech

SiTech — AI-გაძლიერებული ვებ დეველოპმენტი

ვქმნით სწრაფ, თანამედროვე ვებსაიტებს და AI-ს ვაერთიანებთ ქართული ბიზნესებისთვის. გაქვთ პროექტი ან კითხვა? სიამოვნებით დაგეხმარებით.