গুরুতর নিরাপত্তা: GnuTLS OpenSSL অনুসরণ করে, টাইমিং অ্যাটাক বাগ সংশোধন করে

গুরুতর নিরাপত্তা: GnuTLS OpenSSL অনুসরণ করে, টাইমিং অ্যাটাক বাগ সংশোধন করে

উত্স নোড: 1956368

গত সপ্তাহে, আমরা একটি গুচ্ছ সম্পর্কে লিখেছেন মেমরি ম্যানেজমেন্ট বাগ যেগুলো জনপ্রিয় OpenSSL এনক্রিপশন লাইব্রেরির সর্বশেষ নিরাপত্তা আপডেটে ঠিক করা হয়েছে।

সেই মেমরি বাগগুলির সাথে, আমরা ডাব করা একটি বাগ সম্পর্কেও রিপোর্ট করেছি CVE-2022-4304: RSA ডিক্রিপশনে টাইমিং ওরাকল.

এই বাগটিতে, একটি সার্ভারে একই এনক্রিপ্ট করা বার্তা বারবার ফায়ার করা হয়, কিন্তু ডেটার শেষে প্যাডিং পরিবর্তন করে ডেটা অবৈধ করে, এবং এইভাবে কিছু ধরণের অপ্রত্যাশিত আচরণকে উস্কে দেয়...

…একটি ধারাবাহিক সময় লাগবে না, ধরে নিচ্ছি যে আপনি নেটওয়ার্কে লক্ষ্যের কাছাকাছি ছিলেন যে আপনি নির্ভরযোগ্যভাবে অনুমান করতে পারেন যে প্রক্রিয়াটির ডেটা স্থানান্তর অংশটি কতক্ষণ লাগবে।

সমস্ত ডেটা সমানভাবে প্রক্রিয়া করা হয় না

আপনি যদি একটি অনুরোধ বন্ধ করেন, উত্তরটি কতক্ষণ সময় নেয় এবং নেটওয়ার্ক ডেটার নিম্ন-স্তরের প্রেরণ এবং গ্রহণে ব্যয় করা সময় বিয়োগ করেন, আপনি জানেন যে অনুরোধটি প্রক্রিয়া করতে সার্ভারটি তার অভ্যন্তরীণ গণনা করতে কত সময় নিয়েছে। .

এমনকি যদি আপনি নিশ্চিত না হন যে নেটওয়ার্কে কতটা সময় ব্যয় হয়েছে, আপনি প্রচুর অনুরোধ বন্ধ করে এবং প্রচুর নমুনা সংগ্রহ করে রাউন্ড-ট্রিপ সময়ের পরিবর্তনগুলি সন্ধান করতে পারেন।

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

এটি থেকে, আপনি অনেকেই মূল আনএনক্রিপ্ট করা ডেটার কাঠামো বা এমনকি বিষয়বস্তু সম্পর্কে কিছু অনুমান করতে সক্ষম হবেন যা প্রতিটি বারবার অনুরোধের মধ্যে গোপন রাখা উচিত।

এমনকি যদি আপনি প্লেইনটেক্সটের একটি বাইট বের করতে পারেন, ভাল, এটি হওয়ার কথা নয়।

তথাকথিত সময় আক্রমণ এই ধরণের সব সময়ই সমস্যা হয়, এমনকি যদি আপনাকে লক্ষ লক্ষ জাল প্যাকেট পাঠাতে হয় এবং প্লেইনটেক্সট ডেটার মাত্র এক বাইট পুনরুদ্ধার করার সুযোগ পেতে সেগুলিকে সময় দিতে হয়...

…কারণ নেটওয়ার্কগুলি দ্রুত, আরও অনুমানযোগ্য, এবং কয়েক বছর আগের তুলনায় অনেক বেশি লোড পরিচালনা করতে সক্ষম৷

আপনি মনে করতে পারেন যে লক্ষ লক্ষ বিশ্বাসঘাতক প্যাকেট আপনার দিকে স্প্যাম করেছে, বলুন, পরের ঘন্টাটি একটি বাছাই করা থাম্বের মতো দাঁড়িয়ে থাকবে।

কিন্তু "এক মিলিয়ন প্যাকেট স্বাভাবিকের চেয়ে এক ঘন্টা বেশি বা কম" কেবলমাত্র একটি বিশেষ বড় পরিবর্তন নয়।

GnuTLS-এ অনুরূপ "ওরাকল" বাগ

ঠিক আছে, যে ব্যক্তি ওপেনএসএসএল-এ ফিক্সড-এ-লাস্ট বাগ টাইমিং বাগ রিপোর্ট করেছে সেও রিপোর্ট করেছে GnuTLS-এ অনুরূপ বাগ প্রায় একই সময়ে।

এই এক বাগ শনাক্তকারী আছে জন্য CVE-2023-0361.

যদিও GnuTLS ওপেনএসএসএল-এর মতো জনপ্রিয় বা ব্যাপকভাবে ব্যবহৃত হয় না, তবে সম্ভবত আপনার আইটি এস্টেটে বা এমনকি আপনার নিজের কম্পিউটারেও অনেকগুলি প্রোগ্রাম রয়েছে যা এটি ব্যবহার করে বা অন্তর্ভুক্ত করে, সম্ভবত FFmpeg, GnuPG, Mplayer, QEMU সহ , Rdesktop, Samba, Wget এবং Wireshark।

হাস্যকরভাবে, GnuTLS-এর টাইমিং ফ্লো কোডে উপস্থিত হয়েছিল যা প্রথমে টাইমিং অ্যাটাক ত্রুটিগুলি লগ করার কথা ছিল।

আপনি কোড পার্থক্য থেকে দেখতে পারেন (পরিবর্তন) নীচে, প্রোগ্রামার সচেতন ছিল যে কোন শর্তসাপেক্ষ (if ... then) একটি ডিক্রিপশন ত্রুটি পরীক্ষা এবং মোকাবেলায় ব্যবহৃত অপারেশনটি সময়ের বৈচিত্র তৈরি করতে পারে, কারণ CPU গুলি সাধারণত "শাখা" নির্দেশের পরে আপনার কোড কোন পথে যায় তার উপর নির্ভর করে একটি ভিন্ন পরিমাণ সময় নেয়।

(এটি বিশেষ করে এমন একটি শাখার জন্য সত্য যা প্রায়শই এক দিকে যায় এবং কদাচিৎ অন্য দিকে যায়, কারণ CPU গুলি মনে রাখে, বা ক্যাশে, কোড যা কার্যক্ষমতা উন্নত করার জন্য বারবার চলে, এইভাবে কদাচিৎ নেওয়া কোডটি সনাক্তযোগ্যভাবে ধীর গতিতে চলে।)

3.7.8 এর বিপরীতে gnutls-3.7.9/lib/auth/rsa.c এর কোড পার্থক্য

কিন্তু প্রোগ্রামার এখনও লগ করতে চেয়েছিলেন যে একটি আক্রমণ ঘটতে পারে, যা ঘটতে পারে যদি if (ok) উপরে পরীক্ষা ব্যর্থ হয় এবং শাখায় else { ... } অধ্যায়.

এই সময়ে, কোড কল _gnutls_debug_log() ফাংশন, যা তার কাজ করতে বেশ সময় নিতে পারে।

তাই কোডার একটি ইচ্ছাকৃত কল সন্নিবেশ _gnutls_no_log() মধ্যে then { ... } কোডের একটি অংশ, যা একটি না থাকলে একটি "আক্রমণ" লগ করার ভান করে, কোডটি যেকোন দিকে যে সময় ব্যয় করে তা আরও বাড়ানোর চেষ্টা করার জন্য if (ok) শাখা নির্দেশ নিতে পারেন।

দৃশ্যত, যাইহোক, দুটি কোড পাথ ব্যবহার করার সময় যথেষ্ট মিল ছিল না (বা সম্ভবত _gnutls_debug_log() বিভিন্ন ধরণের ত্রুটি মোকাবেলায় তার নিজস্ব ফাংশন অপর্যাপ্তভাবে সামঞ্জস্যপূর্ণ ছিল), এবং একজন আক্রমণকারী লক্ষ লক্ষ চেষ্টা করার পরে ডিক্রিপশন টেলটেলগুলিকে আলাদা করতে শুরু করতে পারে।

কি করো?

আপনি যদি একজন প্রোগ্রামার হন: এখানে বাগ সংশোধন সহজ ছিল, এবং "কম বেশি" নীতি অনুসরণ করে।

উপরের গোলাপি রঙের কোডটি, যেটি যাইহোক ভয়ঙ্করভাবে দরকারী আক্রমণ সনাক্তকরণ ডেটা দেয় না বলে মনে করা হয়েছিল, কেবল মুছে ফেলা হয়েছিল, এই কারণে যে কোডটি নেই সেটি ভুল করে কম্পাইল করা যাবে না, আপনার বিল্ড সেটিংস নির্বিশেষে…

…এবং যে কোডটি কম্পাইল করা হয়নি তা কখনই চালনা করতে পারে না, তা দুর্ঘটনা বা ডিজাইন দ্বারাই হোক।

আপনি যদি একজন GnuTLS ব্যবহারকারী হন: সম্প্রতি প্রকাশিত সংস্করণ 3.7.9 এবং "নতুন পণ্যের স্বাদ" 3.8.0 এই সংশোধন আছে, বিভিন্ন অন্যান্য সহ, অন্তর্ভুক্ত.

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

লিনাক্সে, নামের সাথে ফাইলগুলি অনুসন্ধান করুন libgnutls*.so আশেপাশে পড়ে থাকা কোনো শেয়ার্ড লাইব্রেরি খুঁজে পেতে এবং অনুসন্ধান করুন gnutls-cli কমান্ড লাইন ইউটিলিটির যেকোন কপি খুঁজে পেতে যা প্রায়শই লাইব্রেরির সাথে অন্তর্ভুক্ত থাকে।

আপনি চালাতে পারেন gnutls-cli -vv কোন সংস্করণ খুঁজে বের করতে libgnutls এটি গতিশীলভাবে লিঙ্কযুক্ত:

 $ gnutls-cli -vv gnutls-cli 3.7.9 <-- আমার লিনাক্স ডিস্ট্রো গত শুক্রবার আপডেট পেয়েছে (2023-02-10)

সময় স্ট্যাম্প:

থেকে আরো নগ্ন সুরক্ষা