ក្រុមហ៊ុន Google បានប្រកាសគាំទ្រចំពោះ V8 Sandbox នៅក្នុង Chrome Web Browser ដើម្បីជាកម្លាំងសម្រាប់ដោះស្រាយបញ្ហា Memory Corruption។Sandbox បើយោងតាមថ្នាក់ដឹកនាំបច្ចេកទេស V8 Security មានបំណងការពារ បញ្ហាគាំងរបស់អង្គចងចាំនៅក្នុង V8 ពីការពង្រីកនៅក្នុងដំណើរការម៉ាស៊ីន host។ ការស្រាវជ្រាវបានបង្ហាញថា V8 Sandbox មានទម្ងន់ស្រាល នៅក្នុងដំណើរការ Sandbox សម្រាប់ JavaScript និង WebAssembly Engine ដែលត្រូវបានបង្កើតឡើងសម្រាប់កាត់បន្ថយភាពងាយរងគ្រោះ V8។ គោលបំណងគឺចង់គ្រប់គ្រងនូវកម្រិតផលប៉ះពាល់របស់ភាពងាយរងគ្រោះ V8 ដោយការរឹតបន្តឹងប្រតិបត្តិការកូដដោយ V8 ជាផ្នែកមួយ (Subset) នៃដំណើរការ Virtual Address Space (“the sandbox”) និងកាត់ផ្តាច់វាចេញពីដំណើរការដែលនៅសល់។
ចំណុចខ្វះខាតនៃ V8 ជាផ្នែកមួយនៃភាពងាយរងគ្រោះ Zero-Day ដែលក្រុមហ៊ុន Google បានដោះស្រាយកាលពីឆ្នាំ២០២១ និង២០២៣ ជាមួយនឹងបញ្ហាសុវត្ថិភាពចំនួន ១៦ដែលត្រូវបានរកឃើញកាលពីពេលនោះ។ ក្រុមការងារ Chromium បានថ្លែងថា ប្រព័ន្ធការពារ Sandbox សន្មតថាហេគឃ័រអាចកែប្រែតាមចិត្ត (Modify) អង្គចងចាំនៅក្នុង Sandbox Address Space នៅពេលដែលការកេងចំណេញនេះត្រូវបានបង្កើតចេញពីភាពងាយរងគ្រោះ V8។ ជាងនេះទៀត វាបានសន្មតថាហេគឃ័រនឹងអាចអានអង្គចងចាំនៅខាងក្រៅប្រព័ន្ធការពារ Sandbox ឧទាហរណ៍តាមរយៈ Hardware Side Channel។ បន្ទាប់មក Sandbox មានបំណងការពារដំណើរការដែលនៅសល់ (Rest Of Process) ពីការវាយប្រហារដូចជា បញ្ហាគាំងអង្គចងចាំ (Corruption of Memory) នៅខាងក្រៅ (outside) Sandbox Address Space ដែលត្រូវបានចាត់ទុកថាជាការបំពាន Sandbox (Violation)។ អ្នកបច្ចេកទេសបានបញ្ជាក់ពីបញ្ហាប្រឈមជាមួយនឹងដំណោះស្រាយភាពងាយរងគ្រោះ V8 ដោយការប្តូរទៅកាន់ភាសា memory-safe ដូចជា Rust ឬគន្លឹះសុវត្ថិភាព Hardware Memory ដូចជា Memory Tagging ដែលផ្តល់ជូនបញ្ហានៃភាពត្រឹមត្រូវដែលពិបាកពណ៌នា (Subtle Logic Issues) ដែលអាចត្រូវបានកេងចំណេញ និងបណ្តាលឱ្យគាំងអង្គចងចាំ មិនដូចបញ្ហាសុវត្ថិភាពនៃអង្គចងចាំបុរាណ Use-After-Frees និង Out-of-Bounds Accesses ជាដើមនោះទេ។
ក្រុមបច្ចេកទេសបានបន្តថា ស្ទើរតែគ្រប់ភាពងាយរងគ្រោះបានរកឃើញ និងកេងចំណេញនៅក្នុង V8 នៅថ្ងៃនេះមានបញ្ហាទូទៅមួយនោះគឺបណ្តាលឱ្យគាំងអង្គចងចាំ (Eventual Memory Corruption) កើតមាននៅក្នុង V8 Heap ដោយសារតែ Compiler និង Runtime (Almost) ប្រតិបត្តិការនៅលើ V8 HeapObject Instances តែមួយ។ ដោយសារតែបញ្ហាទាំងនេះមិនអាចត្រូវបានការពារដោយបច្ចេកទេសដូចគ្នាសម្រាប់ Typical Memory-Corruption Vulnerabilities នោះ ប្រព័ន្ធការពារ V8 Sandbox ត្រូវបានបង្កើតឡើងសម្រាប់កាត់ផ្តាច់ V8’s Heap Memory ដូចដែល Memory Corruption ផ្សេងកើតមាន វាមិនអាចគេចពីការកំណត់ផ្នែកសុវត្ថិភាពទៅលើផ្នែកផ្សេងទៀតនៃដំណើរការរបស់អង្គចងចាំបានទេ។ រឿងនេះត្រូវបានធ្វើឡើងដោយការជំនួសគ្រប់ប្រភេទទិន្នន័យទាំងអស់ដែលអាចដំណើរការ out-of-sandbox memory ជាមួយនឹងជម្រើស “sandbox-compatible” ដោយការការពារហេគឃ័រពីដំណើរការអង្គចងចាំផ្សេង។ ប្រព័ន្ធការពារ Sandbox អាចត្រូវបានបើកដោយការកំណត់ (Enabled By Setting) “V8_Enable_Sandbox”។ លទ្ធផលស្តង់ដារចេញពីឧបករណ៍វាស់ Speedometer និង JetStream បង្ហាញថាមុខងារសុវត្ថិភាពបន្ថែមពីលើនោះមានទំហំប្រមាណជា ១% នៅលើ Typical Workloads ដែលអនុញ្ញាតឱ្យមុខងារសុវត្ថិភាពបើកដំណើរការដោយ Default និងចាប់ផ្តើមជាមួយ Chrome Version 123, spanning Android, ChromeOS, Linux, macOS និង Windows។ អ្នកបច្ចេកទេសបានបន្តថា V8 sandbox មានតម្រូវការ (requires) 64-bit System នៅពេលដែលវាត្រូវការទំហំសម្រាប់បម្រុងទុកធំ Virtual Address Space ប្រមាណជា 1 Terabyte នៅពេលបច្ចុប្បន្ន។
ប្រព័ន្ធការពារ Sandbox ត្រូវបានជំរុញដោយសារបច្ចេកវិទ្យាសុវត្ថិភាពអង្គចងចាំមិនអាចអនុវត្តបានទូលំទូលាយនៅក្នុងការបង្កើនសុវត្ថិភាព JavaScript Engines។ នៅពេលបច្ចេកវិទ្យាទាំងនេះមិនអាចការពារសុវត្ថិភាព Memory Corruption នៅក្នុង V8 ខ្លួនវាបាននោះ បច្ចេកវិទ្យាទាំងនេះអាចការពារ V8 Sandbox Attack Surface។ ដូច្នេះប្រព័ន្ធការពារ Sandbox ចាំបាច់ត្រូវតែបោះជំហានទៅកាន់ Memory Safety។ ក្រុមហ៊ុន Google បានលើកឡើងពីតួនាទីរបស់ Kernel Address Sanitizer (KASan) នៅក្នុងការស្វែងរកបញ្ហានៅក្នុងអង្គចងចាំនៅក្នុង Native Code និងជួយពង្រឹងផ្នែកសុវត្ថិភាព Android firmware ដែលបន្ថែមដោយការប្រើ Compiler-Based Tool សម្រាប់ស្វែងរកបញ្ហា (bugs) ជាង ៤០។ ក្រុមការងារ Android បានថ្លែងថា ការប្រើ KASan សម្រាប់បើកការប្រើប្រាស់នៅពេលសាកល្បងអាចជួយដល់ការចាប់យកភាពងាយរងគ្រោះនៅក្នុងអង្គចងចាំ និងបញ្ហាស្ថិរភាព មុនពេលបច្ចេកទេសទាំងនោះត្រូវបានដាក់បញ្ចូលទៅក្នុងឧបករណ៍របស់អ្នកប្រើប្រាស់៕
https://thehackernews.com/2024/04/google-chrome-adds-v8-sandbox-new.html
ប្រភពព័ត៌មាន៖ ថ្ងៃទី០៨ ខែមេសា ឆ្នាំ២០២៤
