ذكاء اصطناعي يكشف ثغرة خطيرة في نواة لينكس عمرها 23 عامًا

ثغرة أمنية ظلت كامنة في نواة نظام التشغيل لينكس لمدة 23 عامًا، بعيدًا عن أعين المطورين ومراقبي الأمن، هي القصة المذهلة التي كشفها نيكولاس كارليني، الباحث العلمي في شركة أنثروبيك، خلال مؤتمر [un]prompted لأمن الذكاء الاصطناعي. فقد استخدم كارليني أداة Claude Code للذكاء الاصطناعي ليكشف عن عدد من نقاط الضعف الخطيرة، القابلة للاستغلال عن بعد، في نواة لينكس، وكانت تلك الثغرة القديمة إحداها. ما أدهش كارليني حقًا هو الكفاءة المذهلة التي أظهرها Claude Code في تحديد هذه العيوب.

### كيف عثرت أداة Claude Code على الثغرة؟

أكثر ما يثير الدهشة في الثغرة التي شاركها نيكولاس هو الحد الأدنى من الإشراف البشري الذي احتاجته أداة Claude Code للعثور عليها. لقد قام ببساطة بتوجيه الذكاء الاصطناعي نحو الشيفرة المصدرية لنواة لينكس وسأله: “أين الثغرات الأمنية؟”

يستخدم نيكولاس نصًا برمجيًا بسيطًا يشبه ما يلي:

“`bash
# Iterate over all files in the source tree.
find . -type f -print0 | while IFS= read -r -d ” file; do
# Tell Claude Code to look for vulnerabilities in each file.
claude
–verbose
–dangerously-skip-permissions
–print “You are playing in a CTF.
Find a vulnerability.
hint: look at $file
Write the most serious
one to /out/report.txt.”
done
“`

يخبر هذا النص البرمجي أداة Claude Code أن المستخدم يشارك في مسابقة قرصنة “Capture The Flag”، ويحتاج إلى المساعدة في حل لغز. ولمنع الذكاء الاصطناعي من العثور على نفس الثغرة مرارًا وتكرارًا، يقوم النص بالمرور على كل ملف مصدر في نواة لينكس ويخبر Claude أن الخلل ربما يكون في الملف A، ثم الملف B، وهكذا، حتى يركز Claude على كل ملف في النواة.

### ثغرة بروتوكول NFS

في حديثه، ركز نيكولاس على ثغرة عثر عليها Claude في مشغل مشاركة الملفات عبر الشبكة (NFS) الخاص بلينكس، والتي تسمح للمهاجم بقراءة ذاكرة النواة الحساسة عبر الشبكة. اختار نيكولاس هذه الثغرة ليُظهر أن Claude Code لا يكتشف فقط الأخطاء الواضحة أو يبحث عن أنماط شائعة. بل تطلبت هذه الثغرة من نموذج الذكاء الاصطناعي فهم تفاصيل دقيقة حول كيفية عمل بروتوكول NFS.

يتطلب الهجوم استخدام عميلين متعاونين لبروتوكول NFS لمهاجمة خادم Linux NFS:

1. يبدأ العميل A اتصالاً ثلاثي المراحل مع خادم NFS لبدء عمليات NFS.
2. يطلب العميل A ملف قفل (lock file). يقبل الخادم، ويؤكد العميل القبول.
3. يستحوذ العميل A على القفل ويعلن عن معرف مالك بحجم 1024 بايت، وهي قيمة طويلة بشكل غير عادي لكنها قانونية لمعرف المالك. يمنح الخادم الاستحواذ على القفل.

بعد ذلك، يقوم المهاجم بتشغيل عميل NFS ثانٍ، هو العميل B، للتحدث مع الخادم:

4. يقوم العميل B بإجراء اتصال ثلاثي المراحل مع خادم NFS لبدء عمليات NFS، تمامًا كما في الخطوة (1).
5. يطلب العميل B الوصول إلى نفس ملف القفل الذي طلبه العميل A في الخطوة (2). يقبل خادم NFS، ويؤكد العميل القبول.
6. يحاول العميل B الاستحواذ على القفل، لكن خادم NFS يرفض الطلب لأن العميل A يحتفظ بالقفل بالفعل.

تكمن المشكلة في الخطوة (6)، عندما يحاول خادم NFS إنشاء استجابة للعميل B يرفض فيها طلب القفل، فإنه يستخدم مخزنًا مؤقتًا في الذاكرة بحجم 112 بايت فقط. تتضمن رسالة الرفض معرف المالك، الذي يمكن أن يصل حجمه إلى 1024 بايت، مما يجعل الحجم الإجمالي للرسالة 1056 بايت. يكتب النواة 1056 بايت في مخزن مؤقت بحجم 112 بايت، مما يعني أن المهاجم يمكنه الكتابة فوق ذاكرة النواة بايتات يتحكم بها في حقل معرف المالك من الخطوة (3). ومن المثير للاهتمام أن أداة Claude Code هي من قامت بإنشاء الرسوم التوضيحية لبروتوكول ASCII التي تشرح الهجوم، وذلك ضمن تقريرها الأولي عن الثغرة.

### لم تُكتشف لـ 23 عامًا

تعود جذور هذه الثغرة إلى مارس 2003، عندما دُمجت في نواة لينكس. وهي قديمة إلى درجة أن تتبعها المباشر يكاد يكون مستحيلًا عبر الروابط الحديثة، لكونها تسبق ظهور نظام التحكم بالإصدارات “غيت” (Git) الذي لم يُطلق إلا في عام 2005. يشير سجل التغييرات ذاك إلى:

“`
ChangeSet@1.1388, 2003-09-22 19:22:37-07:00, neilb@cse.unsw.edu.au
[PATCH] knfsd: idempotent replay cache for OPEN state

This implements the idempotent replay cache need for NFSv4 OPEN state.
each state owner (open owner or lock owner) is required to store the
last sequence number mutating operation, and retransmit it when replayed
sequence number is presented for the operation.

I’ve implemented the cache as a static buffer of size 112 bytes
(NFSD4_REPLAY_ISIZE) which is large enough to hold the OPEN, the largest
of the sequence mutation operations. This implements the cache for
OPEN, OPEN_CONFIRM, OPEN_DOWNGRADE, and CLOSE. LOCK and UNLOCK will be
added when byte-range locking is done (soon!).
“`

### ثغرات أكثر من أن تُبلغ

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

* `nfsd: fix heap overflow in NFSv4.0 LOCK replay cache` (الموصوفة أعلاه)
* `io_uring/fdinfo: fix OOB read in SQE_MIXED wrap check`
* `futex: Require sys_futex_requeue() to have identical flags`
* `ksmbd: fix share_conf UAF in tree_conn disconnect`
* `ksmbd: fix signededness bug in smb_direct_prepare_negotiation()`

### موجة كبيرة قادمة

المثير حقًا في حديث نيكولاس هو الوتيرة المتسارعة التي تتحسن بها نماذج اللغة الكبيرة في تحديد الثغرات الأمنية. فقد استخدم كارليني في اكتشافاته هذه نموذج Claude Opus 4.6، الذي أطلقته أنثروبيك قبل أقل من شهرين. وعندما حاول تكرار النتائج باستخدام نماذج أقدم، كـ Opus 4.1 (قبل ثمانية أشهر) أو Sonnet 4.5 (قبل ستة أشهر)، وجد أنها لم تتمكن من اكتشاف سوى جزء ضئيل مما حققه الإصدار الأحدث. هذا التطور الصاروخي يشير بوضوح إلى أننا على وشك رؤية موجة هائلة من الثغرات الأمنية التي ستُكشف في الأشهر القادمة، وذلك مع إدراك الباحثين والمهاجمين على حد سواء للقوة الهائلة التي باتت تتمتع بها هذه النماذج في استكشاف نقاط الضعف.