يتضمن إصدار OpenSSH 10.6 تغييرين أمنيَين قد يكسران بعض سيناريوهات الاستخدام السابقة: تعطيل مكوّن LZ77 المسؤول عن بناء قاموس التكرارات في ضغط SSH، ورفض اسمي المستخدمين اللذين يحتويان على الرمزين $ و\ عند تمريرهما عبر سطر الأوامر. اتخذ مطورو المشروع القرار مع معرفتهم بأن بعض البيئات والأدوات ستحتاج إلى تعديل.
لماذا أُضعف ضغط SSH؟
يمكن لجلسة SSH واحدة حمل قناة طرفية تفاعلية، أو إعادة توجيه منافذ، أو وكيل SOCKS ديناميكي. وعند تفعيل الضغط، كانت القنوات تشترك في حالة ضغط واحدة. أظهر الباحثان Fabian Bäumer وMarcus Brinkmann من Ruhr University Bochum أن مهاجماً يستطيع إدخال نص يختاره في قناة ومراقبة حركة المرور المشفرة لاستنتاج بيانات سرية تنتقل عبر قناة أخرى في الجلسة نفسها.
يعتمد الهجوم على ذاكرة LZ77؛ إذ يعيد استخدام تسلسلات ظهرت سابقاً بدلاً من ترميزها بالكامل. وعندما يتطابق تخمين المهاجم مع جزء من السر، قد يصبح الناتج المضغوط أقصر قليلاً، ما يوفر إشارة تساعد على استعادة البيانات. ينتمي هذا الأسلوب إلى عائلة هجمات CRIME وBREACH، لكنه يتطلب إعداداً محدداً: تفعيل ضغط SSH، وإمكانية التحكم في جزء من الحركة، ووجود السر والقناة المهاجم عليها ضمن جلسة SSH متعددة القنوات.
في الاختبارات الأقل ضجيجاً، استعاد الباحثان سراً من ثمانية أحرف من أبجدية تضم 26 حرفاً بوسيط 276 تخميناً عبر 100 تجربة. وفي سيناريو قائم على المتصفح وأكثر ضجيجاً، ارتفع العدد إلى نحو 27,600 تخمين. وبحسب المادة المصدرية، بُنيت نماذج إثبات المفهوم باستخدام Claude Code.
ما الذي يتغير عملياً في الضغط؟
أبقى OpenSSH على ترميز Huffman، لكنه عطّل جزء LZ77 في كل من ssh وsshd. لذلك لا يختفي الضغط بالكامل، لكنه يصبح أقل فعالية. ويقول المشروع إن الجلسات التفاعلية المعتادة لن تلاحظ غالباً فرقاً كبيراً، بينما قد تتأثر المهام الآلية التي تنقل كميات كبيرة من البيانات القابلة للضغط عبر اتصالات محدودة السعة.
توصية OpenSSH هي نقل الضغط إلى طبقة التطبيق، حيث يكون عادة أكثر كفاءة ولا يتعرض لهذا النوع من الهجوم. عملياً، ينبغي لمالكي أنظمة الأتمتة التي تعتمد على ضغط SSH أن يقيسوا حجم النقل ووقت التنفيذ بعد الترقية، ثم يحددوا ما إذا كان ضغط البيانات قبل إرسالها أنسب من الاعتماد على ضغط SSH.
أسماء المستخدمين ومسار الأتمتة
يرفض الإصدار 10.6 الرمزين $ و\ في أسماء المستخدمين الممررة عبر سطر الأوامر. يستهدف ذلك أدوات داخلية ومهام CI والوكلاء التي تبني أمراً مثل ssh "$INPUT_USER@host"، ثم قد يصل اسم المستخدم إلى توجيهات مثل ProxyCommand أو Match exec، حيث يمكن تفسير هذه الرموز كجزء من بناء shell بدلاً من اعتبارها بيانات عادية.
لا ينطبق القيد نفسه عندما يُحدد اسم المستخدم عبر التوجيه User في ملف إعداد SSH. لذلك يمكن للحسابات المشروعة التي تحتوي هذه الرموز أن تظل قابلة للاستخدام بهذه الطريقة، لكن النصوص البرمجية والأدوات التي تمررها مباشرة عبر سطر الأوامر قد تحتاج إلى تغيير. ويأتي ذلك بعد إصلاح ذي صلة في OpenSSH 10.3، إذ كان التحقق من محارف shell يتم في وقت متأخر يسمح بوصولها إلى مسار التوسع في ssh_config.
تغييرات إضافية قد تؤثر في سير العمل
- فقد خوارزمية التوقيع الهجينة لما بعد الكم ssh-mldsa44-ed25519 اللاحقة التجريبية @openssh.com، ما يعني أن المفاتيح المنشأة بالتنفيذ السابق تحتاج إلى إعادة توليد أو إزالة.
- بدأ المشروع تمهيد إيقاف scp -R للنسخ من مضيف بعيد إلى مضيف بعيد. يظل الخيار يعمل في الإصدار 10.6، لكنه يصدر تحذيراً، ومن المقرر تجاهله مستقبلاً.
تُظهر هذه التغييرات أن التوافق مع السلوك السابق لم يعد أولوية مطلقة عندما يكشف الاستخدام الآلي مساراً لتسريب البيانات أو حقن الأوامر. لكن القيود العملية ليست متساوية: خطر تسريب الضغط يتطلب جلسة وشروطاً محددة، بينما قد يظهر رفض أسماء المستخدمين فوراً في نصوص تعتمد على مدخلات خارجية. لذلك تحتاج فرق التشغيل إلى اختبار الترقية، ومراجعة بناء أوامر SSH، والتحقق من المفاتيح وخيارات النسخ قبل اعتماد الإصدار على نطاق واسع.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.