তারা ওয়াসমটাইমে একটি গুরুতর দুর্বলতা সনাক্ত করেছে

কয়েকদিন আগে এলওয়াসমটাইম 6.0.1, 5.0.1 এবং 4.0.1 সংশোধনমূলক আপডেট প্রকাশিত হয়েছে Que তারা একটি দুর্বলতা ঠিক করতে পেতে (ইতিমধ্যেই CVE-2023-26489 এর অধীনে তালিকাভুক্ত) যা সমালোচনামূলক রেট করা হয়েছে।

ক্ষতিগ্রস্থতা অনুমোদিত সীমার বাইরে একটি মেমরি এলাকায় ডেটা লেখা সংগঠিত করার অনুমতি দেয় বিচ্ছিন্ন WebAssembly কোডের জন্য, যা বিচ্ছিন্ন WASI পরিবেশের বাইরে তাদের কোড কার্যকর করার জন্য আক্রমণকারীর দ্বারা সম্ভাব্যভাবে ব্যবহার করা যেতে পারে।

যারা ওয়াসমটাইমের সাথে অপরিচিত তাদের জন্য, আপনার জানা উচিত যে এটি সাধারণ স্বতন্ত্র অ্যাপ্লিকেশন হিসাবে WASI (WebAssembly সিস্টেম ইন্টারফেস) এক্সটেনশনগুলির সাথে WebAssembly অ্যাপ্লিকেশন চালানোর জন্য একটি রানটাইম।

Wasmtime লেখা আছে মরিচা এবং রাউটিং নিয়মের সংজ্ঞায় একটি যৌক্তিক ত্রুটির কারণে দুর্বলতা ক্রেনলিফ্ট কোড জেনারেটরে রৈখিক মেমরির, যা x86_64 আর্কিটেকচারের জন্য এক্সিকিউটেবল মেশিন কোডে হার্ডওয়্যার আর্কিটেকচার থেকে স্বাধীন একটি মধ্যবর্তী উপস্থাপনা অনুবাদ করে।

স্থির দুর্বলতা সম্পর্কে, এটি উল্লেখ করা হয়েছে যে বিশেষভাবে, কার্যকর 35-বিট ঠিকানা গণনা করা হয়েছিল WebAssembly অ্যাপ্লিকেশনের জন্য WebAssembly-এ অনুমোদিত 33-বিট ঠিকানার পরিবর্তে, যা পড়ার এবং লেখার ক্রিয়াকলাপের জন্য অনুমোদিত ভার্চুয়াল মেমরি সীমাকে 34 GB-তে পরিবর্তন করেছে, যখন স্যান্ডবক্স পরিবেশ সেটিং 6 গিগাবাইটের জন্য সুরক্ষা প্রদান করে। ভিত্তি ঠিকানা থেকে।

Wasmtime এর কোড জেনারেটর, Cranelift, x86_64 লক্ষ্যে একটি বাগ রয়েছে যেখানে ঠিকানা মোড গণনা ভুলভাবে WebAssembly দ্বারা সংজ্ঞায়িত 35-বিট কার্যকরী ঠিকানার পরিবর্তে একটি 33-বিট কার্যকরী ঠিকানা গণনা করবে। এই বাগটির অর্থ হল, ডিফল্ট কোড জেনারেশন কনফিগারেশনের সাথে, একটি wasm-নিয়ন্ত্রিত লোড/স্টোর অপারেশন লিনিয়ার মেমরির বেস থেকে 35 বিট পর্যন্ত ঠিকানা পড়তে/লিখতে পারে। 

ফলস্বরূপ, বেস অ্যাড্রেস থেকে ভার্চুয়াল মেমরি রেঞ্জ 6 থেকে 34 গিগাবাইট পর্যন্ত পড়া এবং লেখার জন্য উপলব্ধ হয়ে উঠেছে WebAssembly অ্যাপ্লিকেশন থেকে। এই মেমরি অন্যান্য WebAssembly পরিবেশ বা WebAssembly রানটাইম উপাদান ধারণ করতে পারে।

উদাহরণস্বরূপ (i32.load (i32.shl (local.get 0) (i32.const 3))), WebAssembly ঠিকানা $local0 থেকে লোড করা হয় << 3. Cranelift এ অনুবাদ করা হলে, $local0 << 3 এর হিসাব একটি 32-বিট মান, শূন্য-প্রসারিত একটি 64-বিট মান, এবং তারপর রৈখিক মেমরির মূল ঠিকানায় যোগ করা হয়। Cranelift ফর্ম movl(%base, %local0, 8), %dst এর একটি বিবৃতি তৈরি করবে যা %base + %local0 << 3 গণনা করে।

তবে এখানে ত্রুটি হল যে ঠিকানা গণনাটি 64-বিট মানগুলির সাথে ঘটে, যেখানে $local0 << 3 ঠিকানাটিকে 32-বিট মানতে ছেঁটে ফেলার কথা ছিল। এর মানে হল যে %local0, যা একটি ঠিকানার জন্য 32 বিট পর্যন্ত ব্যবহার করতে পারে, movl এর মাধ্যমে অ্যাক্সেসযোগ্য হওয়ার জন্য অতিরিক্ত 3 বিট ঠিকানা স্থান পায়।

অবশেষে, সর্বদা হিসাবে এটি উপলব্ধ সর্বশেষ সংস্করণে প্যাকেজ আপডেট করার সুপারিশ করা হয়এটাও উল্লেখ করা দরকার যে আপডেট করা সম্ভব না হলে এই সমস্যাটি কমানোর জন্য বেশ কয়েকটি সম্ভাব্য সমাধান ব্যবহার করা যেতে পারে।

এটি উল্লেখ করা হয়েছে যে এই সমাধানগুলির কোনটিই ডিফল্টরূপে চালু নেই এবং সুস্পষ্ট কনফিগারেশন প্রয়োজন:

• যদি Wasmtime-এর সংস্করণ আপডেট করা সম্ভব না হয়, তাহলে "Config::static_memory_maximum_size(0)" বিকল্পটি উল্লেখ করা হয়েছে যাতে ত্রুটিটি ব্লক করার জন্য একটি সমাধান হিসাবে যেকোন রৈখিক মেমরি অ্যাক্সেসে বাধ্যতামূলক পৃথক সীমানা পরীক্ষা করা যায় (ফলাফল একটি উল্লেখযোগ্য কর্মক্ষমতা হ্রাস পায়। )
• আরেকটি বিকল্প হল সমস্যাযুক্ত ভার্চুয়াল মেমরি রেঞ্জে অবস্থিত গার্ড পেজ (গার্ড পেজ, এক্সেস করা হলে ব্যতিক্রম) সংখ্যা বাড়ানোর জন্য "Config::static_memory_guard_size(1 <36)" সেটিং ব্যবহার করা (যা বড় পরিমাণ ভার্চুয়াল রিজার্ভ করে। মেমরি এবং সমসাময়িক WebAssembly অ্যাপ্লিকেশনের সংখ্যা সীমিত করা)।
• যদি একটি নন-x86_64 হোস্ট ব্যবহার করা সম্ভব হয়, তাহলে এটি এই ত্রুটিটিও ঠিক করবে। এই বাগটি Wasmtime বা Cranelift এর AArch64 ব্যাকএন্ডকে প্রভাবিত করে না, উদাহরণস্বরূপ।

পরিশেষে আপনি যদি এটি সম্পর্কে আরও জানতে আগ্রহী হন, আপনি বিশদটি পরীক্ষা করতে পারেন নিম্নলিখিত লিঙ্ক।