প্রোগ্রাম যাচাইকরণের কৌশলগুলি হার্টবলিডের জেনার বাগগুলি সংঘটিত হতে আটকাতে পারে?


9

হার্টবেল্ড বাগের বিষয়ে ব্রুস স্নিয়ার তার 15 ই এপ্রিলের ক্রিপ্টো-গ্রামে লিখেছেন: '' ক্যাটাস্ট্রফিক 'সঠিক শব্দ। 1 থেকে 10 এর স্কেলে এটি একটি ১১। ' আমি বেশ কয়েক বছর আগে পড়েছিলাম যে একটি নির্দিষ্ট অপারেটিং সিস্টেমের কার্নেলটি একটি আধুনিক প্রোগ্রাম যাচাইকরণ সিস্টেমের সাথে কঠোরভাবে যাচাই করা হয়েছে। অতএব হার্টবেল্ড জেনারগুলির বাগগুলি আজ প্রোগ্রাম যাচাইকরণ কৌশল প্রয়োগের মাধ্যমে ঘটতে বাধা দেওয়া যেতে পারে বা এটি এখনও অবাস্তব বা এমনকি মূলত অসম্ভব?


2
জে রেগার এর এই প্রশ্নের আকর্ষণীয় বিশ্লেষণ এখানে দেওয়া হল।
মার্টিন বার্গার

উত্তর:


6

আপনার প্রশ্নের সর্বাধিক সংক্ষিপ্তভাবে উত্তর দিতে - হ্যাঁ, এই বাগটি আনুষ্ঠানিকভাবে যাচাইকরণ সরঞ্জামগুলি দ্বারা ধরা যেতে পারে। প্রকৃতপক্ষে, সম্পত্তি "কখনই এমন কোনও ব্লক প্রেরণ করে না যা প্রেরণ করা হিবিট আকারের চেয়ে বড়" বেশিরভাগ স্পেসিফিকেশন ভাষায় (যেমন এলটিএল) আনুষ্ঠানিকভাবে আনতে মোটামুটি সহজ।

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

এছাড়াও, রাষ্ট্রীয়-বিস্ফোরণ সমস্যার কারণে আনুষ্ঠানিকভাবে সফ্টওয়্যার যাচাই করা কুখ্যাতভাবে কঠিন। এই ক্ষেত্রে, এটি বিশেষভাবে প্রাসঙ্গিক, যেহেতু বহুবার রাষ্ট্রীয় বিস্ফোরণ এড়ানোর জন্য আমরা বিমূর্ততা সীমাবদ্ধ করি। উদাহরণস্বরূপ, যখন আমরা বলতে চাই "প্রতিটি অনুরোধ অনুদানের পরে অনুসরণ করা হয়, 100000 পদক্ষেপের মধ্যে", আমাদের খুব দীর্ঘ সূত্রের প্রয়োজন হয়, তাই আমরা সূত্রটি বিমূর্তভাবে "প্রতিটি অনুরোধ অবশেষে অনুদানের পরে অনুসরণ করা হয়"।

সুতরাং, হৃদয়গ্রাহী ক্ষেত্রে, প্রয়োজনীয়তাগুলি আনুষ্ঠানিক করার চেষ্টা করার পরেও, প্রশ্নে আবদ্ধ হওয়াটিকে বিমূর্ত করা যেতে পারে, ফলে একই আচরণের ফলস্বরূপ।

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


5

ক্লোকওয়ার্ক বা কভারিটির মতো বাণিজ্যিক প্রোগ্রামের চেকাররা হার্টবেলডকে খুঁজে পেতে সক্ষম হবেন কারণ এটি তুলনামূলকভাবে সহজ "বাউন্ডস চেক ত্রুটি করতে ভুলে গেছি", যা তাদের জন্য যাচাই করার জন্য তৈরি করা অন্যতম প্রধান সমস্যা। তবে একটি আরও সহজ উপায় আছে: বাফার ওভাররন থেকে মুক্ত থাকার জন্য অস্বচ্ছ বিমূর্ত ডেটা টাইপগুলি ব্যবহার করুন যা ভালভাবে পরীক্ষিত।

সি প্রোগ্রামিংয়ের জন্য প্রচুর "নিরাপদ স্ট্রিং" বিমূর্ত তথ্য প্রকার উপলব্ধ। যার সাথে আমি সবচেয়ে বেশি পরিচিত তা হ'ল ভাস্ট্র । লেখক, জেমস অ্যান্টিলের নিজের কন্সট্রাক্টর / ফ্যাক্টরি পদ্ধতিগুলির সাথে স্ট্রিং অ্যাবস্ট্রাক্ট ডেটা টাইপ এবং সি এর জন্য অন্যান্য স্ট্রিং অ্যাবস্ট্রাক্ট ডেটা টাইপের একটি তালিকা কেন প্রয়োজন তা সম্পর্কে দুর্দান্ত আলোচনা করেছেন ।


2
গোপনীয়তা হৃদয়গ্রাহী খুঁজে পাচ্ছে না, জন রেগারের এই বিশ্লেষণটি দেখুন ।
মার্টিন বার্গার

দুর্দান্ত লিঙ্ক! এটি গল্পটির আসল নৈতিকতা প্রদর্শন করে: খারাপভাবে নকশা করা (বা অস্তিত্বহীন) বিমূর্ততাগুলির জন্য প্রোগ্রাম যাচাইকরণ তৈরি করতে পারে না।
বেড়ানো

2
এটি প্রোগ্রাম যাচাইকরণ দ্বারা আপনি কী বোঝাতে চান তা নির্ভর করে। যদি আপনি স্থির বিশ্লেষণ বোঝাতে চান, তবে হ্যাঁ, এটি সর্বদা রাইসের উপপাদ্যের প্রত্যক্ষ পরিণতি হিসাবে একটি অনুমান is যদি আপনি একটি ইন্টারেক্টিভ উপপাদ্য প্রসেসর মধ্যে সম্পূর্ণ আচরণ যাচাই করেন, তবে আপনি একটি aালাই-লোহার গ্যারান্টি পাবেন যে প্রোগ্রামটি এর নির্দিষ্টকরণগুলি পূরণ করে, তবে এটি অত্যন্ত শ্রমসাধ্য। এবং আপনি এখনও সমস্যার মুখোমুখি হয়েছিলেন যে আপনার স্পেসিফিকেশনগুলি ভুল হতে পারে (যেমন দেখুন এরিয়েন 5 বিস্ফোরণ)।
মার্টিন বার্গার

1
@ মার্টিনবার্গার: গোপনীয়তা এখন এটি খুঁজে পেয়েছে ।
মনিকা পুনরায় ইনস্টল করুন - এম Schröder

4

আপনি যদি রানটাইম বাউন্ড-চেকিং এবং ফজিংয়ের সংমিশ্রণটিকে " প্রোগ্রাম যাচাইকরণ কৌশল  " হিসাবে গণনা করেন  , তবে হ্যাঁ এই বিশেষ বাগটি ধরা যেতে পারে

যথাযথ ঝাঁকুনির ফলে এখন কুখ্যাতটি memcpy(bp, pl, payload);মেমরির ব্লকের plঅন্তর্গত সীমার মধ্যে পড়তে বাধ্য করবে। রানটাইম বাউন্ড-চেকিং নীতিগতভাবে এ জাতীয় যে কোনও অ্যাক্সেস ধরতে পারে এবং বাস্তবে, এই বিশেষ ক্ষেত্রে, এমনকি একটি ডিবাগ সংস্করণও mallocপ্যারামিটারগুলির সীমাবদ্ধ-চেক করার জন্য যত্নশীল তা memcpyকাজটি করতে পারে (এখানে এমএমইউতে গোলযোগ করার দরকার নেই) need । সমস্যাটি হ'ল, প্রতিটি ধরণের নেটওয়ার্ক প্যাকেটে ধোঁয়াটে পরীক্ষা করতে প্রচেষ্টা নেওয়া দরকার।


1
আইআইআরসি সাধারণভাবে সত্য হলেও, ওপেনএসএসএল-র ক্ষেত্রে লেখকরা তাদের নিজস্ব অভ্যন্তরীণ মেমরি পরিচালনাকে বাস্তবায়ন করেছেন যে memcpyসিস্টেম থেকে অনুরোধকৃত (বৃহত্তর) অঞ্চলের সত্য সীমানায় আঘাত হানার সম্ভাবনা খুব কম ছিল malloc
উইলিয়াম মূল্য

হ্যাঁ, ওপেনএসএসএলের ক্ষেত্রে যেমন এটি বাগের সময় ছিল, memcpy(bp, pl, payload)ততক্ষণে mallocসিস্টেমটি নয়, ওপেনএসএসএল-এর প্রতিস্থাপনের দ্বারা ব্যবহৃত সীমানার বিরুদ্ধে পরীক্ষা করতে হবে malloc। এটি বাইনারি স্তরে স্বয়ংক্রিয়ভাবে সীমাবদ্ধ-চেকিংয়ের বিধি নিষেধ করে (কমপক্ষে mallocপ্রতিস্থাপনের গভীর জ্ঞান ছাড়াই )। সোর্স-লেভেল উইজার্ড্রি ব্যবহার করে অবশ্যই পুনরায় সংশ্লেষ করতে হবে যেমন সি ম্যাক্রো টোকেন mallocপ্রতিস্থাপন বা যে কোনও প্রতিস্থাপন ওপেনএসএসএল ব্যবহার করেছে; এবং মনে memcpyহয় খুব চালাক এমএমইউ ট্রিক্স ব্যতীত আমাদের একই দরকার ।
fgrieu

4

একটি কঠোর ভাষা ব্যবহার করা কেবলমাত্র প্রয়োগের সঠিক হওয়া থেকে অনুমানের সঠিক হওয়া থেকে গোল পোস্টগুলিকে সরিয়ে দেয় না। এমন কিছু তৈরি করা শক্ত যা খুব ভুল, তবুও যুক্তিযুক্তভাবে সুসংগত; এই কারণেই সংকলকরা এতগুলি বাগ ধরেন।

পয়েন্টার গাণিতিক যেমনটি সাধারণত তৈরি করা হয় ততক্ষণ সাউন্ড না কারণ টাইপ সিস্টেমটি আসলে এর অর্থ বোঝার কথাটি বোঝায় না। কোনও আবর্জনা সংগ্রহ করা ভাষায় কাজ করার মাধ্যমে আপনি এই সমস্যাটিকে পুরোপুরি এড়াতে পারবেন (স্বাভাবিক পদ্ধতির ফলে যা আপনাকে বিমূর্ততার জন্য অর্থ প্রদান করে)। অথবা আপনি কী ধরণের পয়েন্টার ব্যবহার করছেন সে সম্পর্কে আপনি আরও সুনির্দিষ্ট হতে পারেন, যাতে সংকলকটি বেমানান এমন কোনও কিছু প্রত্যাখ্যান করতে পারে যা কেবল লিখিত হিসাবে সঠিক প্রমাণিত হতে পারে না। এটি জং এর মতো কিছু ভাষার যোগাযোগ।

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

  • int * x; // একটি মিথ্যা দাবি। এক্স বিদ্যমান এবং কোন প্রকারের দিকে নির্দেশ করে না
  • int * y = z; // z কেবলমাত্র যদি কোন আন্তঃকে নির্দেশ করে প্রমাণিত হয়
  • * (x + 3) = 5; // কেবলমাত্র সত্য (x + 3) যদি x এর মতো একই অ্যারেতে কোনও বিন্দুতে নির্দেশ করে
  • int c = a / b; // শুধুমাত্র সত্য যদি খ ননজারো হয়, যেমন: "ননজারো ইন্ট বি = ...;"
  • nullable int * z = NULL; // nullaable int * কোনও int * এর মতো নয়
  • int d = * z; // একটি ভ্রান্ত প্রতিশ্রুতি, কারণ z হ'ল নমনীয়
  • যদি (z! = NULL) {int * e = z; // ঠিক আছে কারণ z নাল নয়
  • বিনামূল্যে (Y); int w = * y; // ভুয়া দাবি, কারণ y এর আর ডাব্লুতে নেই

এই বিশ্বে পয়েন্টারগুলি নালার হতে পারে না। নালপয়েন্টার ডিरेফেরেন্সগুলি বিদ্যমান নেই এবং পয়েন্টারগুলিকে কোথাও নালার জন্য পরীক্ষা করতে হবে না। পরিবর্তে, "nullaable int *" হ'ল একটি আলাদা ধরণের যা এর মান হয় নালিতে বা একটি পয়েন্টারের কাছে আহরণ করতে। এর অর্থ এই যে বিন্দুতে নন-নাল অনুমান শুরু হয় আপনি নিজের ব্যতিক্রম লগইন করুন বা নাল শাখা নীচে যান।

এই বিশ্বে, সীমা ত্রুটির বাইরে অ্যারে উপস্থিত নেই। যদি সংকলক প্রমাণ করতে না পারে যে এটি সীমাবদ্ধ, তবে পুনরায় লেখার চেষ্টা করুন যাতে সংকলক এটি প্রমাণ করতে পারে। যদি এটি না করতে পারে, তবে আপনাকে সেই স্থানে ম্যানুয়ালি একটি অনুমান স্থাপন করতে হবে; সংকলক পরে এটির সাথে একটি দ্বন্দ্ব খুঁজে পেতে পারে।

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

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

ঠিক এ কারণেই দুটি খারাপ অভ্যাস হ'ল বৈশ্বিক পরিবর্তনশীল এবং গোটোস। এই জিনিসগুলি যে কোনও কিছুর আগে প্রাক / পোস্ট / আক্রমণকারী শর্ত স্থাপন করা রোধ করে। প্রকারগুলি এত কার্যকর কেন এটিও। প্রকারগুলি আরও শক্তিশালী হওয়ার সাথে সাথে (প্রকৃত মানটিকে বিবেচনায় নিতে অবশেষে নির্ভরশীল প্রকারগুলি ব্যবহার করে) তারা নিজের মধ্যে গঠনমূলক যথার্থতার প্রমাণ হিসাবে উপস্থিত হয়; অসামঞ্জস্য প্রোগ্রামগুলি সংকলনে ব্যর্থ।

মনে রাখবেন যে এটি কেবল বোবা ভুল সম্পর্কে নয়। এটি চালাক অনুপ্রবেশকারীদের কাছ থেকে কোড বেসকে রক্ষা করার বিষয়েও। "আনুষ্ঠানিকভাবে নির্দিষ্ট প্রোটোকল অনুসরণ করে" এর মতো গুরুত্বপূর্ণ বৈশিষ্ট্যগুলির দৃ conv়প্রত্যয়ী মেশিন-উত্পাদিত প্রমাণ ছাড়াই আপনাকে জমা দিতে হবে এমন ক্ষেত্রেও এমন ঘটনা ঘটবে।


2

স্ট্যাটিক বিশ্লেষণ সরঞ্জাম যেমন কভারিটি হ'ল হার্টব্লিড এবং অনুরূপ ত্রুটিগুলি খুঁজে পেতে পারে। সম্পূর্ণ প্রকাশ: আমি গোপনীয়তা cofounded।

হার্টব্লিড সম্পর্কে আমাদের তদন্ত সম্পর্কে আমার ব্লগ পোস্টটি দেখুন এবং এটি সনাক্ত করতে কীভাবে আমাদের বিশ্লেষণ বাড়ানো হয়েছিল:

http://security.coverity.com/blog/2014/Apr/on-detecting-heartbleed-with-static-analysis.html


1

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

মিডিয়া থেকে এর উৎপত্তি সম্পর্কে আরও বি কেজি:

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.