ثغرة Heartbleed: فرصة لتصحيح بعض المفاهيم الخاطئة المُتعلقة بالبرمجيات مفتوحة المصدر

أثارت ثغرة Heartbleed (ثغرة القلب الدامي) التي تم اكتشافها عام 2014 في مكتبة OpenSSL زوبعة كبيرة في مجال البرمجيات بشكل عام، كما أنها كشفت عن عدة أفكار خاطئة علقت في أذهان الكثيرين مُتعلقة بالبرمجيات مفتوحة المصدر بشكل خاص.

1. قانون لينوس Linus’s Law

ينص قانون لينوس (والذي سُمّي تيمّنا بلينوس تورفالدس ولم يصدر منه مُباشرة) على التالي:

إذا توفر عدد كافٍ من العُيون فإن كل العلل البرمجية ستنتهي بإيجاد حلول لها – إريك ريموند

يدّعي قانون لينوس بأنه في حال ما إذا توفر عدد كافٍ من المُستخدمين لاستخدامها وعدد كافٍ من المُطورين لمُراجعتها فإن مشاكل كل شفرة برمجية مفتوحة المصدر سيتم حلها، وهو ما سينتج عنه برامج أصح وأكثر أمانًا مُقارنة بالتطبيقات مُغلقة المصدر/ التطبيقات المملوكة.

عالج الكتاب “حقائق وُمغالطات حول هندسة البرمجيات” “Facts and fallacies of software engineering” هذه النقطة بالذات في فصله الثامن، حيث يستشهد كاتبه بأقوال باحثين في هذا المجال تشير إلى أن النسبة التي ينمو بها عدد العلل البرمجية التي يتم اكتشافها لا يتناسب طردًا مع عدد المُدققين لهذه الشفرات. يبدو بأن كون البشر قليلي الكفاءة في تصيّد الثغرات البرمجية هي حقيقة يجب أن تبقى راسخة في ذهن كل مُبرمج. في حين أنه من الهيّن اكتشاف الأخطاء المتُعلقة بتراكيب اللغة البرمجية syntax issues أو الأنماط البرمجية الواجب اجتنابها anti-patterns إلا أن قسمًا كبيرًا من هذه العلل يبقى خفيًا عن الأعين ولا تظهر إلا لدى استخدام تلك البرامج بشكل فعلي.

هذا الأمر يجعل من المُستخدم طرفًا مُهمًا في إيجاد العلل البرمجية والتبليغ عنها، وهو ما قد يدفعنا إلى الجزم بأنه حتى ولو لم نكتشف العلل البرمجية لدى مُراجعتنا للشفرة المصدرية فإنه سيتم “إلقاء القبض” عليها لما نشرع في استخدام تلك البرمجيات. لكن للأسف الأمر ليس صحيحًا بالضرورة، حيث أنه -ومثلما هو عليه الحال مع مُراجعة الشفرات المصدرية- لا يتم اكتشاف سوى العلل والأخطاء البسيطة والبديهية، فيكفي أن تشترط علة برمجية جُملة من الشروط حتى يُصبح من المُمكن وقوعها أو أنها تحدث فقط في حالات لا يتوقعها المُستخدم النهائي حتى تعيش هذه العلة مُتخفية ولسنوات طويلة دون أن يتم اكتشافها. أضف إلى ذلك أنه كلما زادت درجة تعقيد البرنامج، وكلما زاد عدد الوظائف التي يُقدّمها للُمستخدم كلما أصبح من الصعب الجزم بأن التطبيق يقوم بالوظائف التي وُكّلت إليه بشكل دقيق. وبحكم أن هذه البرمجيات تقوم عادة بأعمال تستغرق الإنسان وقتًا طويلًا للقيام بها بشكل يدوي، فإنه من الصعب تكرار كل الوظائف التي يقوم بها التطبيق بشكل يدوي للتحقق من صحتها.

تُعتبر ثغرة Heartbleed عينة مثالية لهذا المُشكل، حيث أن عدد الشركات التي تستخدم مكتبة OpenSSL يُقدّر بالملايين من مُختلف بقاع العالم، وتملك العديد من هذه الشركات فرق تطوير مُتخصصة تعمل بدوام كامل على تطوير برمجياتها لتوفرها لملايين المُستخدمين، رغم ذلك فإن هذه الثغرة بقيت نائمة تنتظر من يوقظها طيلة حولين كاملين، وكان من المُحتمل جدًا أن تبقى على هذا الحال لسنوات أخرى لو لم يقم فريق أمني بالكشف عنها.

نشر أحدهم على موقع Hacker News تعليقًا يُلخص هذه القضية بشكل جيد، حيث كتب:

مُغالطة “العدد الكافي من الأعين” لا تخص سوى المُراجعات الرسمية للشفرات المصدرية. كما أنها تدور حول فكرة أنه لما يتم فتح الشفرة المصدرية لتطبيق مُعين فإنه يُفترض بدائرة المراجعين لها أن تتوسع خارج الدائرة الضيقة للمشرفين على المشروع أو للأصدقاء المُقربين لهم والذين سيكون بإمكانهم مُراجعة الشفرة المصدرية سواء فُتحت أو لم تُفتح. ما الذي يحدث حاليا في الأغلبية الساحقة من البرمجيات مفتوحة المصدر هو أن دائرة الذين سيقدرون على فهم الشفرة المصدرية في كل إيداع commit ستكون أوسع بقليل جدًا من نفس الدائرة لو لم يتم فتح الشفرة المصدرية. وبالتالي فإن أثر ذلك على آلية اكتشاف العلل البرمجية سيكون محدودًا جدًا إن لم يكن مُنعدما.

على ضوء هذه النتيجة فإن فائدة البرمجيات مفتوحة المصدر مُقارنة بالتي تبقى مُغلقة من حيث صحتها وأمانها قليلة إلى منعدمة. لكن في المقابل قوة المصادر المفتوحة تكمن في قدرتك على ترقيع الثغرات وتصحيح العلل بنفسك، رغم أنه في حالة ثغرة Heartbleed انتظر أغلب المُستخدمين والمبرمجين أن يتم إصدار ترقيع رسمي لها، حيث أن ترقيع الثغرات الأمنية خاصة لما يتعلق الأمر بمشروع بحجم مكتبة OpenSSL المعروفة بتعقيدها يحتاج إلى مُستوى عال من التقانة لا يتوفر لدى عام المُطورين.

2. يقوم بتطوير أغلب البرمجيات مفتوحة المصدر وصيانتها هواة وليس بالضرورة مُمتهني البرمجة

كشفت ثغرة Heartbleed بأنه حتى البرمجيات بالغة الأهمية كمكتبة OpenSSL والتي يتم استخدامها في قسم كبير من الإنترنت لا تملك الموارد اللازمة ليتم تطويرها وصيانتها بشكل احترافي/مهني (professionally maintained)، فلم يكن يحصل فريق تطوير OpenSSL إلا عن ما لا يزيد عن 2000 دولار من التبرعات بشكل سنوي. كُتبت العديد من المقالات التي نُشرت حول هذه الثغرة بنبرة اتهامية، ولم يطرأ على بال أي من هؤلاء الصحفيين بأن فريق التطوير الذي يتهمونه ما هو سوى مجموعة من المُتطوعين الذين يعملون على هذه المشاريع في أوقات فراغهم، مشاريع أقل ما يُمكن وصفها بأنها تقدم خدمات جليلة للمُجتمع.

فالمُطور الذي كان وراء هذه الثغرة لم يكن حتى مُطورا مُحترفا (أي أنه لا يمتهن البرمجة)، حيث أنه كان طالبًا يُحضر شهادة الدكتوراه. رغم أنه يملك مُستوى يسمح له بالمُساهمة في مشاريع مُعقّدة كمكتبة OpenSSL فإنه من غير المنطقي أن نُحاسب طالبًا بنفس المعايير التي نُحاسب بها مُطورًا مُحترفًا يمتهن البرمجة منذ سنوات، مُبرمج نتوقع بأنه مسؤول عن صيانة برمجيات أمنية شديدة الأهمية.

يُمكن اعتبار هذه النُقطة إحدى أهم نقاط القوة وإحدى أهم نقاط الضعف في البرمجيات مفتوحة المصدر على حد سواء، حيث أنه يُمكن لأي كان -بغَض النظر عن خلفيته أو عن مهارته- في المساهمة. لم يقم بإطلاق العديد من المشاريع مفتوحة المصدر التي نستعملها بشكل دائم سوى مجموعة هُواة فقط، وهو ما يجعل من عالم البرمجيات مفتوحة المصدر رائعًا لكنه يحمل في طياته مخاطر يجب على الجميع أن يأخذها في الحسبان.

في حين أن هناك مشاريع مفتوحة المصدر من العيار الثقيل التي تدعمها العديد من الشركات مما يسمح لها بالحصول على فرق مُطورين مُحترفين لمواصلة العمل عليها بدوام كامل ولصيانتها، إلا أن أغلب المشاريع مفتوحة المصدر لا تُوفق في جمع سوى فتات لا يُسمن ولا يغني من جوع على هيئة تبرعات. يبدو بأن دعم المشاريع مفتوحة المصدر بنفس المصادر التي تتوفر عليها البرمجيات التجارية كفيل بخلق مشاريع مُستدامة عالية الجودة يُمكن للجميع الاستفادة منها.

أما فيما يخص المشاريع مفتوحة المصدر التي لا تحصل على رعاية وهو أمر يصعب التحكم فيه فإنه هناك طُرقًا أخرى يُمكن التربح ونخص بالذكر نموذجيOpen-Core (مثل MySQL) و الخدمات (مثل Red Hat)، حيث أن الاعتماد على التبرعات لوحدها ليس كافيًا في أغلب الحالات.

وعليه فإنه ما لم تقم بعض الأطراف بتبني مشروع OpenSSL نظرا لأهميته البالغة فإنه لا يبقى أمام فريق تطويره سوى الانتقال إلى نظام تجاري يسمح لهم بالتفرغ له بشكل كامل إن كان ذلك أمرًا هم يرغبون في القيام به.

3. كل التطبيقات تحتوي ثغرات. تملك التطبيقات مفتوحة المصدر موارد أقل لإيجادها

لا يزال الكثير من المُستخدمين ينظرون إلى البرمجيات مفتوحة المصدر نظرة المُشتري لسلعة حتى ولو حصلوا عليها بشكل مجاني، وتم نشر العديد من الشكاوى والاتهامات في حق مُطوري OpenSSL رغم أن هؤلاء المُطورين قدموا خدمات جليلة للمُجتمع طيلة سنوات عديدة. قدموا من دون أي مُقابل مكتبة تسمح لمن أراد استخدامها من الأفراد والشركات بتشفير مُحادثاتهم وحماية بياناتهم، وقاموا بكل ذلك في أوقاتهم الخاصة ومن دون أي مُقابل مادي أو حتى معنوي.

بل وصلت الوقاحة ببعضهم إلى أن أشار ضمنيًا إلى احتمال أن تكون هذه الثغرة غير بريئة وأنه تم إدخالها إلى المكتبة عن قصد. ما لم تكن أحد هواة نظريات المؤامرة فإن يُمكن تنصيف مُجرد التفكير في أن الفريق الذي قدم كل قدم من دون أن ينتظر جزاءً ولا شكورا سيعمد إلى إدخال ثغرة بشكل عمدي في خانة السخافة.

في حقيقة الأمر، ستحتوي البرمجيات دائمًا على علل وثغرات وهذا أمر يعلمه كل مُطور منذ اليوم الذي وطأت فيه قدماه عالم البرمجة. أيًا كان عدد التجارب التي قُمت بها أو مدى صرامة التجارب في حد ذاتها فإن بعض الثغرات والعلل ستسقط سهوا. بإمكانك التقليل منها إن كنت تملك موارد أكثر لكنه من المُستبعد جدًا أن تقضي عليها كُلية. هل كان بإمكان فريق عمل OpenSSL تجنب ثغرة Heartbleed لو كانوا يعملون على المشروع بدوام كامل ولو كان لديهم المزيد من الوقت والموارد للقيام بتجارب أكثر صرامة ولمُراجعة الشفرات بشكل أفضل؟ قد يكون ذلك مُمكنًا، لكنه لا يُمكن الجزم بذلك.

هذه نقطة يجب على مُستخدمي التطبيقات مفتوحة المصدر أن يعوها جيدًا، ستكون هناك دائمًا ثغرات وعلل برمجية في جميع البرمجيات بما فيها البرمجيات مفتوحة المصدر، في حين أنه سيكون لمُطوري البرمجيات مفتوحة المصدر وقت وموارد أقل لإيجادها وتصحيحها.

خلاصة القول، بدل أن نتعامل مع هذه البرمجيات مُعاملتنا للسلع التي ندفع مُقابلها وبدل أن نوزع الاتهامات مجانًا فإنه يجب على الأقل أن نُثمن الأدوات المجانية المُتوفرة ما بين أيدينا (تكلفتها واستخدامها). ولو أردت التأثير فيُمكنك أن ترد الجميل لمُطوري ومشرفي هذه البرمجيات وتُبين لهم احترامك لهم وامتنانك لأعمالهم. أما إذا كنت تعتمد بشكل أساسي على المصادر المفتوحة فإن تشجيع مُطوري هذه البرامج للعمل عليها بدوام كامل حتى ولو اقتضى ذلك أن لا تحصل عليها بشكل مجاني هو الخيار الأمثل.

المصادر:

• ترجمة -وبتصرف- للمقال: Heartbleed and the misconceptions about Open Source