القيامة الرقمية الآن – أو كيف تتعامل مع مشكلة عام 2038

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

المعيار الضمني لحقبة Unix

تُعد حقبة Unix نظام توقيت اعتمدته أنظمة تشغيل Unix، ثم شاع استخدامه في قطاع تقنية المعلومات بأكمله. ويعتمد النظام على حساب عدد الثواني بدءًا من التوقيت العالمي المنسق (UTC) في تمام الساعة 00:00:00 من يوم 1 يناير 1970، والذي يُعتبر نقطة الصفر. ويتم تمثيل أي لحظة زمنية بعدد الثواني التي انقضت منذ ذلك التاريخ. وتُستخدم القيم السالبة للتواريخ التي تسبق عام 1970. وقد اختار مطورو Unix هذا النهج لبساطته؛ فبدلاً من تخزين السنة والشهر واليوم والوقت بشكل منفصل، لا يلزم سوى رقم واحد فقط. ويسهل هذا عمليات مثل فرز البيانات أو حساب الفترات الزمنية بين التواريخ. واليوم، يتجاوز استخدام حقبة Unix حدود أنظمة Unix ليشمل قواعد البيانات ولغات البرمجة وبروتوكولات الشبكات والهواتف الذكية التي تعمل بنظامي iOS وAndroid.

القنبلة الموقوتة لعام 2038

في البداية، عند تطوير نظام Unix، اتُّخذ قرار بتخزين الوقت كعدد صحيح موقّع بصيغة 32 بت. وقد أتاح ذلك تمثيل نطاق زمني يمتد تقريبًا من عام 1901 إلى 2038. وتكمن المشكلة في أنه في 19 يناير 2038، تمام الساعة 03:14:07 بالتوقيت العالمي المنسق، سيصل هذا الرقم إلى قيمته القصوى (2,147,483,647 ثانية) ثم يتجاوز سعتها، ليصبح رقمًا سالبًا، مما سيؤدي إلى انتقال أجهزة الكمبيوتر زمنيًا من يناير 2038 والعودة بها إلى 13 ديسمبر 1901. ومع ذلك، قد يحدث في بعض الحالات “سفر عبر الزمن” لفترة أقصر، وتحديدًا إلى نقطة الصفر، وهي عام 1970.

قد يؤدي هذا الحدث، المعروف باسم “مشكلة عام 2038” أو “القيامة الرقمية” أو “Y2K38″، إلى حدوث أعطال في الأنظمة التي لا تزال تعتمد على تمثيل الوقت بصيغة 32 بت؛ بدءًا من أجهزة نقاط البيع والأنظمة المدمجة وأجهزة التوجيه وصولاً إلى السيارات والمعدات الصناعية. وقد عالجت الأنظمة الحديثة هذه المشكلة باستخدام 64 بت لتخزين الوقت. ويمتد هذا النطاق الزمني ليشمل مئات المليارات من السنين في المستقبل. ومع ذلك، لا تزال ملايين الأجهزة التي تعمل بتواريخ بصيغة 32 بت قيد التشغيل، وسوف تتطلب تحديثًا أو استبدالاً قبل حلول “اليوم الموعود”.

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

في الحالات التي لا تتطلب التعامل مع تواريخ تسبق عام 1970، يتم تخزين التاريخ كعدد صحيح غير موقّع بصيغة 32 بت. ويمكن لهذا النوع من الأرقام تمثيل التواريخ من عام 1970 إلى عام 2106؛ مما يعني أن المشكلة ستحدث في مستقبل أبعد.

أوجه الاختلاف عن مشكلة عام 2000

كانت مشكلة عام 2000 (Y2K) الشهيرة في أواخر القرن العشرين مشابهة، حيث كانت الأنظمة التي تخزن السنة في خانتين فقط معرضة للخلط بين التاريخ الجديد وعام 1900. وقد خشي الخبراء ووسائل الإعلام آنذاك من وقوع قيامة رقمية، لكن في نهاية المطاف، لم تظهر سوى مظاهر خلل معزولة ومتفرقة لم تؤدِّ إلى إخفاقات كارثية عالمية.

يكمن الفرق الجوهري بين أزمتي عام 2038 وعام 2000 في حجم التحول الرقمي الذي يحيط بحياتنا اليوم. ويعتبر عدد الأنظمة التي ستحتاج إلى تحديث أكبر بكثير مما كان عليه عدد أجهزة الكمبيوتر في القرن العشرين، كما أن حجم المهام والعمليات اليومية التي تدار حاسوبيًا بات يفوق الحصر. وفي الوقت الذي تم فيه – أو سيتم قريبًا – إصلاح مشكلة عام 20238 في أجهزة الكمبيوتر العادية وأنظمة التشغيل عبر تحديثات برمجية بسيطة. ومع ذلك، فإن أجهزة الكمبيوتر الدقيقة التي تدير أجهزة تكييف الهواء والمصاعد والمضخات وأقفال الأبواب وخطوط التجميع في المصانع، قد تستمر في العمل طوال العقد القادم بإصدارات برمجية قديمة وهشة أمام ثغرة عام 2038.

المشكلات المحتملة المترتبة على القيامة الرقمية

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

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

للأسف، لا يمكن تحديد النطاق الكامل للعواقب إلا من خلال إجراء اختبارات منضبطة لكافة الأنظمة، مع إجراء تحليل منفصل لاحتمالية حدوث انهيارات متسلسلة.

الاستغلال الخبيث لأزمة عام 2038

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

• التداخل مع بيانات بروتوكول NTP عبر تزويد النظام المُستهدف بخادم وقت زائف
• انتحال إشارات نظام تحديد المواقع (GPS) – في حال اعتماد النظام على توقيت الأقمار الصناعية

يُعد استغلال هذا الخطأ أكثر احتمالاً في أنظمة التقنيات التشغيلية (OT) وإنترنت الأشياء (IoT)، حيث تتسم معالجة الثغرات تاريخيًا بالبطء، وتكون عواقب الفشل فيها أكثر جسامة بكثير.

ومن الأمثلة على الثغرات الأمنية التي يمكن استغلالها بسهولة والمتعلقة بعد الوقت، الثغرة رقم CVE-2025-55068 (بدرجة خطورة 8.2 وفق معيار CVSSv3، و8.8 وفق CVSSv4) والموجودة في وحدات التحكم الآلية لقياس خزانات الوقود من طراز Dover ProGauge MagLink LX4. ويمكن أن يؤدي التلاعب بالوقت إلى حجب الخدمة في محطة الوقود، ومنع الوصول إلى لوحة إدارة الجهاز عبر الويب. وقد استدعى هذا الخلل إصدار تنبيه أمني خاص من وكالة CISA.

الوضع الراهن لإجراءات التخفيف من آثار أزمة عام 2038

تم بنجاح وضع الحجر الأساس لحل مشكلة عام 2038 في أنظمة التشغيل الرئيسية. وأضافت نواة Linux  دعمًا للوقت بصيغة 64 بت حتى في البنى المعمارية ذات صيغة 32 بت، وذلك بدءًا من الإصدار 5.6 في عام 2020، علمًا بأن إصدارات Linux بصيغة 64 بت كانت دائمًا محمية من هذه المشكلة. وتعتمد عائلة أنظمة BSD وmacOS وiOS توقيت 64 بت في كافة الأجهزة الحديثة. أما جميع إصدارات Windows التي صدرت في القرن الحادي والعشرين، فهي غير عرضة لمشكلة عام 2038.

أما على مستوى تخزين البيانات والتطبيقات، فإن الوضع أكثر تعقيداً بكثير. وصُممت أنظمة الملفات الحديثة مثل ZFS وNTFS مع طوابع زمنية بصيغة 64 بت، بينما تظل الأنظمة الأقدم مثل ext2 وext3 عرضة للخطر. وتطلب أنظمة Ext4 وXFS تمكين علامات محددة (inode الموسعة لنظام ext4 وbigtime لنظام XFS)، وقد تحتاج إلى عملية تحويل لأنظمة الملفات الحالية في وضع عدم الاتصال. ولا يزال تنسيق تخزين الوقت القديم قائماً في بروتوكولات NFSv2 وNFSv3. ويتكرر هذا المشهد المتفاوت في قواعد البيانات؛ حيث يقتصر نوع البيانات TIMESTAMP في MySQL بشكل أساسي على عام 2038، ويتطلب الهجرة إلى DATETIME، بينما تُعد أنواع الطوابع الزمنية القياسية في PostgreSQL آمنة. وبالنسبة للتطبيقات المكتوبة بلغة C، فقد تم توفير مسارات لاستخدام وقت 64 بت على معمارية 32 بت، لكن تتطلب جميع المشاريع إعادة تجميع. وتستخدم لغات مثل Java وPython وGo عادةً أنواعًا تتجنب مشكلة تجاوز السعة، إلا أن سلامة المشاريع المُجمّعة تعتمد على مدى تفاعلها مع مكتبات برمجية مكتوبة بلغة C وقد تكون غير محصنة.

تظل أعداد هائلة من أنظمة 32 بت والأجهزة المدمجة والتطبيقات عرضة للثغرة إلى أن يتم إعادة بنائها واختبارها، ومن ثم تثبيت التحديثات اللازمة من قِبل جميع مستخدميها.

تحاول منظمات وجهات تطوعية مختلفة تصنيف المعلومات المتعلقة بهذا الشأن، إلا أن جهودها لا تزال مشتتة. ونتيجة لذلك، لا توجد “قاعدة بيانات مشتركة للثغرات الأمنية لعام 2038 متاحة حتى الآن (1، 2، 3، 4، 5).

نهج معالجة أزمة عام 2038

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

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

عند اختبار الأنظمة المؤسسية، من الضروري اتخاذ احتياطات خاصة:

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

إذا تبيّن أن النظام عرضة لثغرة عام 2038، يجب طلب جدول زمني للإصلاح من المورّد. وأما إذا كان الإصلاح مستحيلاً، فيتعين التخطيط لعملية ترحيب؛ ولحسن الحظ، فإن الوقت المتبقي لا يزال يسمح بتحديث الأنظمة، حتى تلك المعقدة والمكلفة منها.

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