Microsoft-ის "ოქროს გასაღების" ბოლოდროინდელმა გაჟონვამ და გამართვის რეჟიმის არსებობამ საშუალება მისცა უსაფრთხო ჩატვირთვის გამორთვას Windows მოწყობილობებზე. წაიკითხეთ!
Windows-ზე დაფუძნებული ოპერაციული სისტემა აღარ არის ნაგულისხმევი და მთავარი არჩევანი მობილური სცენაზე. Android-ის ღია კოდის ბუნებამ ბევრი გულშემატკივარი იპოვა OEM-ებში და შედეგად, დღესდღეობით სულ უფრო ნაკლები ტელეფონი იყენებს Windows-ს.
მაგრამ თუ თქვენ ხართ მათ შორის, ვინც კვლავ განაგრძობს Windows მოწყობილობის გამოყენებას თქვენს ყოველდღიურ ცხოვრებაში, თქვენთვის ცოტა სიახლეა. კარგია თუ ცუდი, ეს დამოკიდებული იქნება თქვენს პოზიციაზე და ამ ამბების გამოყენების შემთხვევების ინტერპრეტაციაზე.
როგორც იტყობინება Ars Technica და რეგისტრაცია ა-დან მომდინარე ამბებით საიტი, რომელიც სავარაუდოდ თავის ტკივილს მოგიტანთ (არ ვხუმრობ), რამდენიმე დეველოპერი (@never_released და @TheWack0lian) გაარკვიეს, რომ უკანა კარი, რომელიც მაიკროსოფტმა გამოუშვა გამართვის მიზნით, გახსნა Windows მოწყობილობებზე უსაფრთხო ჩატვირთვის გამორთვის შესაძლებლობა.
უსაფრთხო ჩატვირთვა და რა არის ეს?
როდესაც პირველად ჩატვირთავთ Windows მოწყობილობას, ჩატვირთვის პროცედურა მიდის ამ ზოგადი თანმიმდევრობით: UEFI (Unified Extensible Firmware Interface, რომელიც არის BIOS-ის ჩანაცვლება) -> Boot Manager -> Boot Loader -> ფანჯრები. UEFI არის ის, სადაც არის უსაფრთხო ჩატვირთვის ფუნქცია. როგორც სახელი გულისხმობს უსაფრთხო ჩატვირთვა, ის მიზნად ისახავს უსაფრთხოების გაუმჯობესებას ციფრული ხელმოწერების მოთხოვნით შემდეგ ნაბიჯებზე. არსებითად, თუ ჩამტვირთველი არ არის ხელმოწერილი კლავიშებით, რომლებთანაც UEFI ელოდება, რომ თქვენი მოწყობილობის ჩატვირთვის პროცედურა არ დასრულდება.
Secure Boot არის არასავალდებულო ფუნქცია, მაგრამ Microsoft-მა გახადა სავალდებულო ჩართვა Windows სერთიფიკატის მისაღებად Windows 8-დან და შემდგომში. აქ მსჯელობა იყო ის, რომ Secure Boot გაურთულებდა მავნე პროგრამის ავტორებს კოდის ჩასმა ჩატვირთვის პროცედურაში. თუმცა, Secure Boot-ის გვერდითი ეფექტი ის იყო, რომ Windows-ის აპარატებზე ორმაგი ჩატვირთვა ცოტათი გაართულა. ან მეორე OS და მისი ყველა წინარეკვიზიტი ასევე უნდა იყოს ციფრული ხელმოწერილი, ან უნდა იყოს Secure Boot ინვალიდი. ამაში ბევრი სხვა საკითხია და სეზონურმა ორმაგ ჩამტვირთველებმა მათ შესახებ მეტი იცოდნენ, ვიდრე მე შემეძლო ავხსნა აბზაცში.
ახლა არის რამდენიმე მოწყობილობა, რომლებზეც უსაფრთხო ჩატვირთვა არ შეიძლება გამორთოს მომხმარებლის მიერ, თუნდაც სურდეს. ეს ის სფეროა, სადაც ჩვენი საგანი მკვეთრად ვიწროვდება ყველა Windows მოწყობილობიდან (მათ შორის დესკტოპები) კონკრეტულ Windows მოწყობილობებზე, როგორიცაა Windows Phone მოწყობილობები, Windows RT მოწყობილობები, ზოგიერთი Surface მოწყობილობა და კიდევ ჰოლოლენსი. ამ საბოლოო მომხმარებლის მოწყობილობებს აქვთ უსაფრთხო ჩატვირთვა ჩაკეტილია, რაც იმას ნიშნავს, რომ ა საბოლოო მომხმარებელს არ შეუძლია შეცვალოს ან გამორთოს უსაფრთხო ჩატვირთვასთან დაკავშირებული ასპექტები, და გაფართოებით, მათ არ შეუძლიათ შეეხონ ოპერაციულ სისტემას საბოლოო მომხმარებლისთვის Microsoft-ის მიერ დაუშვებელი მანერებით.
მაგრამ უწყვეტი ოფიციალური განვითარების მიზნებისთვის, Secure Boot ცოტათი უნდა შემსუბუქდეს. მოწყობილობებზე, რომლებზეც Secure Boot არის ჩაკეტილი, არსებობს Secure Boot Policies, რომელიც დაგეხმარებათ ავტორიზებული განვითარებაში Secure Boot-ის გამორთვის გარეშე. როგორც მკვლევარი მომხმარებლები აღნიშნავენ, ეს Secure Boot Policy ფაილი იტვირთება Boot Manager-ის მიერ Windows-ის ჩატვირთვის პროცესის დასაწყისში. პოლიტიკის ფაილები ასევე შეიძლება შეიცავდეს რეესტრის წესებს, რომლებსაც, თავის მხრივ, აქვთ შესაძლებლობა შეიცავდეს კონფიგურაციას თავად პოლიტიკისთვის, სხვა საკითხებთან ერთად. ისევ, პოლიტიკის ფაილი უნდა იყოს ხელმოწერილი და არსებობს სხვა დებულებები, რომლებიც დარწმუნდებიან, რომ მხოლოდ Microsoft-ს შეუძლია უზრუნველყოს ეს ცვლილებები.
ხელმოწერის ელემენტი ასევე ეყრდნობა იმას, რასაც DeviceID ჰქვია, რომელიც გამოიყენება განაცხადის დროს. მე მივცემ უფლებას ბლოგის პოსტს ახსნას აქ, რადგან არის რამდენიმე ნაწილი, რომელიც ჩემთვის გაუგებარია:
ასევე, არსებობს ასეთი რამ, სახელწოდებით DeviceID. ეს არის დამარილებული SHA-256 ჰეშის პირველი 64 ბიტი, ზოგიერთი UEFI PRNG გამომავალი. ის გამოიყენება Windows Phone-ზე და Windows RT-ზე პოლიტიკის გამოყენებისას (mobilestartup აყენებს მას Phone-ზე და SecureBootDebug.efi, როდესაც ის პირველად გაშვებულია RT-ზე). ტელეფონზე პოლიტიკა უნდა განთავსდეს EFIESP დანაყოფის კონკრეტულ ადგილას, ფაილის სახელით DeviceID-ის ექვსკუთხედი ფორმის ჩათვლით. (Redstone-თან ერთად, ეს შეიცვალა UnlockID-ზე, რომელიც დაყენებულია bootmgr-ით და არის მხოლოდ UEFI PRNG-ის დაუმუშავებელი გამომავალი).
ძირითადად, bootmgr ამოწმებს პოლიტიკას ჩატვირთვისას, თუ ის შეიცავს DeviceID-ს, რომელიც არ ემთხვევა იმ მოწყობილობის DeviceID-ს, რომელზეც მუშაობს bootmgr, პოლიტიკა ვერ ჩაიტვირთება. ნებისმიერი პოლიტიკა, რომელიც საშუალებას გაძლევთ ჩართოთ ტესტირების ხელმოწერა (MS მოუწოდებს ამ საცალო მოწყობილობის განბლოკვის / RDU პოლიტიკას და მათი ინსტალაცია არის მოწყობილობის განბლოკვა), უნდა იყოს ჩაკეტილი DeviceID-ზე (UnlockID Redstone-ზე და ზემოთ). მართლაც, მე მაქვს რამდენიმე პოლიტიკა (ხელმოწერილი Windows Phone-ის წარმოების სერთიფიკატით) მსგავსი, სადაც ერთადერთი განსხვავებაა ჩართული DeviceID და ხელმოწერა. თუ არ არის დაინსტალირებული მოქმედი პოლიტიკა, bootmgr უბრუნდება ნაგულისხმევი პოლიტიკის გამოყენებას, რომელიც მდებარეობს მის რესურსებში. ეს არის ის პოლიტიკა, რომელიც ბლოკავს ტესტირების ხელმოწერის ჩართვას და ა.შ. BCD წესების გამოყენებით.
ეს ის ნაწილია, სადაც ყველაფერი საინტერესო ხდება. Windows 10 v1607-ის შემუშავებისას, Microsoft-მა შექმნა ახალი ტიპის უსაფრთხო ჩატვირთვის პოლიტიკა (მოკლედობისთვის ამიერიდან მოიხსენიება როგორც SBP) შიდა ტესტირებისა და გამართვის მიზნით. პოლიტიკა ბუნებით არის „დამატებითი“ DeviceID-ის გარეშე და იწვევს მისი პარამეტრების გაერთიანებას არსებულ ჩატვირთვის პოლიტიკაში. ჩატვირთვის მენეჯერი იტვირთება SBP-ის ძველ ტიპებში, შემდეგ ამოწმებს მის ხელმოწერას და ავთენტურობას და შემდეგ იტვირთება ჩატვირთვის ამ დამატებით პოლიტიკაში. საკითხი აქ არის ის, რომ არ არსებობს დამატებითი გადამოწმება თავად დამატებით პოლიტიკაზე. ასევე, Windows 10 v1511-ზე ადრე ჩატვირთვის მენეჯერებმა არ იციან ამ პოლიტიკის დამატებითი ხასიათის არსებობის შესახებ და, შესაბამისად, იმოქმედეთ ისე, თითქოს მათ ჩატვირთეს იდეალურად სწორი და ხელმოწერილი პოლიტიკა. ისევ და ისევ, ეს ქცევა სავარაუდოდ შიდა განვითარებისთვის იყო, ასე რომ დეველოპერებს არ უნდა ჰქონოდათ ხელი მოეწერათ OS-ის თითოეულ ვერსიას და მცირე ცვლილებას, რაც მათ უნდა გაეკეთებინათ მოწყობილობაზე.
ამ SBP-ს მოიხსენიებენ, როგორც "ოქროს გასაღებს", რადგან ის ძირითადად არღვევს ხელმოწერის შემოწმების მიზანს. ეს SBP უნებლიედ გაიგზავნა საცალო მოწყობილობებზე, თუმცა დეაქტივირებულ მდგომარეობაში. დეველოპერებმა იპოვეს ეს SBP და გამოაცხადეს თავიანთი დასკვნები. ახლა, SBP შეიძლება იყოს ნაპოვნია ინტერნეტში მცურავი, ამ კონკრეტული zip გამოიყენება Windows RT მოწყობილობებზე SBP-ის დასაყენებლად.
Რას ნიშნავს ეს?
თუ ჩატვირთეთ დამატებითი SBP, შეგიძლიათ ჩართოთ ტესტის ხელმოწერა Windows-ისთვის, რათა მოგცეთ ხელმოუწერელი დრაივერების ჩატვირთვა. გარდა ამისა, ვინაიდან ეს პოლიტიკები ამოქმედდება ჩატვირთვის პროცედურის დაწყებამდე ჩატვირთვის მენეჯერის ეტაპამდე, თქვენ შეგიძლიათ დაარღვიოთ მთელი შეკვეთის უსაფრთხოება და გაუშვათ არაავტორიზებული (წაიკითხეთ ხელმოწერილი) კოდი. ეს ხსნის უამრავ შესაძლებლობას მომხმარებლებისთვის, რომლებიც აპირებენ Windows-ის ნაწილების შეცვლას ავტორიზაციის მიღმა და მავნე პროგრამების შემქმნელებისთვისაც.
ამ დასკვნის ავტორები ყურადღებას ამახვილებენ მთელი ფიასკოს ირონიაზე. მაიკროსოფტმა ჩაკეტა Secure Boot გარკვეულ მოწყობილობებზე, რათა არაავტორიზებული ცვლილებები შორს შეენარჩუნებინა, მაგრამ შემდეგ ააშენა უკანა კარი, რათა მათ განაგრძონ განვითარება და გამართვა. მაგრამ ეს უკანა კარი უხსნის გზას უსაფრთხო ჩატვირთვის გამორთვას Windows-ზე გაშვებულ ყველა მოწყობილობაზე, რაც მთელ განსაცდელს უაზროდ აქცევს.
ახლა არა მხოლოდ მსურველ მომხმარებლებს შეუძლიათ დააინსტალირონ Linux დისტროები (და შესაძლოა Android) მხოლოდ Windows-ის პლანშეტებზე და ტელეფონებს, უნებლიე მომხმარებლებს ასევე შეუძლიათ დააინსტალირონ მავნე ჩექმები, თუ ისინი კომპრომეტირებენ ფიზიკურ წვდომას მათზე. მოწყობილობა. მიუხედავად იმისა, რომ პირველი არის ის, რასაც ჩვენ შეგვიძლია ჰაერში გადახტომა, ეს უკანასკნელი ნამდვილად არ იწვევს დიდ ნდობას. ის ორივე მიმართულებით მიდის და გვაჩვენებს, რატომ არის უსაფრთხოება ორლესიანი მახვილი. გარდა ამისა, SBP ბუნებით უნივერსალურია, რაც საშუალებას იძლევა მისი გამოყენება ნებისმიერ მოწყობილობაზე, არქიტექტურის მიუხედავად. ის განსაკუთრებით არ არის გამოსადეგი დესკტოპის შემთხვევებისთვის, სადაც Secure Boot შეიძლება ადვილად გამორთოთ, მაგრამ ის უზარმაზარია იმ მოწყობილობებისთვის, სადაც უსაფრთხო ჩატვირთვისას არ შეგიძლიათ არეულობა.
მაშ, რა არის გამოსავალი?
მაიკროსოფტმა გამოუშვა გარკვეული პატჩები, მაგრამ დეველოპერები ამტკიცებენ, რომ პრობლემა ბოლომდე არ არის გამოსწორებული. შეგიძლიათ ნახოთ ეს პატჩები (MS16-094 და MS16-100) და შემდეგ წაიკითხეთ ბლოგის პოსტი თავად რატომ არ წყვეტენ საკითხს. თუ ისინი სწორია, ამ პრობლემას არ აქვს გამოსწორება ან პაჩი, თუმცა ეს ხელს არ შეუშლის მაიკროსოფტს გზაზე მეტი ბლოკირების დაყენებაში.
Შემდეგი რა არის?
არსებობს შესაძლებლობების სამყარო და ზოგიერთი მათგანი მუშავდება ჩვენს Windows ფორუმებზე. შეგიძლიათ ნახოთ ჩვენი ფორუმები Windows Phone 8-ის განვითარება და ჰაკერობა და ჩვენი ფორუმებისთვის Windows 8, Windows RT და Surface Development and Hacking. თქვენ ასევე შეგიძლიათ იპოვოთ ინსტრუქციის ძაფები ზოგიერთი მოწყობილობისთვის, სადაც სხვა მომხმარებლებიც იმავეს განიხილავენ.
ამ გამართვის უკანა კარის არსებობა და SBP-ის გაჟონვა მნიშვნელოვანია არა მხოლოდ მესამე მხარისთვის ჩაკეტილი Windows მოწყობილობების შემუშავება, ისინი ასევე გვაჩვენებენ საშინელ შეხსენებას იმის შესახებ, თუ რა შეიძლება მოხდეს განზრახ უკანა კარები დარჩა. უსაფრთხოებაზე ბოლო დროს აქცენტი მიმართული იყო საგამოძიებო უწყებებისკენ, რომლებიც ახდენდნენ ზეწოლას, რომ ასეთი უკანა კარების არსებობა გამოიყენებოდა მათი სამართლებრივი საგამოძიებო მიზნების დასახმარებლად. მაგრამ ადრე თუ გვიან, ეს მეთოდები ნება მოხვდება არასწორ ხელში. ის, რაც მიზნად ისახავს გამოიყენოს დანაშაულთან ბრძოლისა და მართლმსაჯულების დასახმარებლად, ერთ მშვენიერ დღეს გახდება თვით დანაშაულის იარაღი.
რას ფიქრობთ Debug SBP-ის გაჟონვის შესახებ? ფიქრობთ, რომ ასეთი "ოქროს გასაღებები" უნდა არსებობდეს? შეგვატყობინეთ ქვემოთ მოცემულ კომენტარებში!