تم ضبط Grok وهو يقوم برفع قاعدة الأكواد البرمجية الخاصة بك بالكامل

BBetter Stack
컴퓨터/소프트웨어경제 뉴스AI/미래기술

스크립트

00:00:00لقد قام Grok برفع دليل المستخدم الخاص بي بالكامل إلى خوادم xAI، وهو يحتوي على مفاتيح SSH وكلمة مروري
00:00:05وقاعدة بيانات المدير ومستنداتي وصوري ومقاطع الفيديو وكل شيء، لقد قام واجهة سطر الأوامر البرمجية الخاصة بـ Grok برفع
00:00:10المستودع بأكمله وسجل git الخاص بك بما في ذلك الملفات التي طُلب منه عدم فتحها والأسرار التي حُذفت من
00:00:16السجل. هذا خطأ فادح وكبير من فريق Grok، لذا دعونا نحلل
00:00:20ما حدث، وكيف يمكنك التحقق مما إذا تم رفع الكود الخاص بك، وما الذي فعلته xAI لإصلاح ذلك
00:00:29لذا فقد اكتشفت هذا الأمر لأول مرة من خلال هذه التغريدة التي تخبر الناس بتشغيل أمر grep هذا لقراءة
00:00:33سجلات Grok التي تقول إنك ستغضب، وهي تعرض صورة للسجل توضح أنه يقوم بوضع مستودع في قائمة الانتظار
00:00:38للرفع إلى خوادم Grok. تحتوي هذه التغريدة على مئات الردود والاقتباسات لأشخاص قاموا بتشغيل هذا الأمر
00:00:42وحصلوا على نتيجة مماثلة، وحتى مستخدم واحد قام بتشغيل Grok في دليله الرئيسي وأبلغ أنهم
00:00:47رفعوا كل شيء. تظهر تحقيقات أخرى أنه يشحن كود جمع خلفي يشبه البرمجيات الخبيثة
00:00:52لذا دعونا نلقي نظرة على ما كان يفعله بالفعل، وهذا تقرير من قبل باحث يدعى cereblab
00:00:56استخدم mitm proxy لفحص حركة المرور التي كانت ترسلها وتستقبلها واجهة سطر أوامر Grok، وقاموا بفتح Grok في
00:01:02مستودع، والمطالبة الوحيدة التي أرسلوها إليه كانت “رد بالموافقة، لا تفتح أي ملفات”. تبين
00:01:07مع ذلك أن تلك التعليمات لا تهم لأن Grok قام برفع المستودع بأكمله على أي حال، كان هناك طلب
00:01:12post تم إرساله يحتوي على حزمة المستودع بالكامل، وهذه الحزمة كان بها كل سجل git
00:01:16وحتى متغيرات البيئة. هذا ما أجده سيئاً للغاية في كل هذا، نعم نعلم جميعاً أنه عندما
00:01:21نستخدم نموذجاً بعيداً، سيتم إرسال الكود إلى خوادمنا، ولكن عادة ما يكون هناك افتراض
00:01:26بأنه يتم إرسال الكود الذي يحتاج فعلياً إلى القراءة فقط، وليس قاعدة الكود بأكملها
00:01:30حتى عندما لا يكون ذا صلة بالمطالبة. لقد أظهروا أيضاً أن هذا نجح عندما كان حجم المستودع 12 جيجابايت
00:01:35ولا يزال يرفع كل شيء. اختبار هذا في أدوات أخرى مثل Claude Code وCodex وGemini
00:01:40يظهر أنه يرسل فقط الملف الذي يقرأه، هذه مشكلة فريدة لواجهة سطر أوامر Grok. حتى أنهم وجدوا
00:01:45أنه إذا قمت بإيقاف تشغيل إعداد “مساعدة في تحسين هذا النموذج”، فسيظل يقوم بذلك ويجلب بيانات المستخدم
00:01:51أنه كان هناك بالفعل علم يسمى trace upload enable والذي كان دائماً مضبوطاً على true. الآن كل
00:01:55هذه التغريدات وهذا المنشور بدأت تنتشر بسرعة، فكيف استجابت xAI؟ حسناً، أولاً قاموا بعمل
00:02:01إصلاح صامت. إذا جربت هذا مرة أخرى بعد يوم من انتشار المنشور، أظهرت الإعدادات أن
00:02:05علم trace upload أصبح الآن معطلاً، وكان هناك بالفعل علم جديد يسمى disable codebase upload
00:02:10والذي تم ضبطه على true على ما يبدو لكل حساب، لذا فقد وضعوا بالفعل مفتاح إيقاف من جانب الخادم
00:02:14لرفع الكود. بعد فترة وجيزة ردوا أيضاً علنًا على تويتر قائلين “نحن نهتم
00:02:19بعمق بخصوص خصوصيتك ونحترم خيار العميل. بالنسبة للفرق التي تستخدم ميزة عدم الاحتفاظ بالبيانات، لا يوجد تتبع و
00:02:24بيانات الكود لا يتم الاحتفاظ بها أبداً. كل استخدام لمفتاح API الخاص بـ Grok يحترم أيضاً عدم الاحتفاظ بالبيانات. إذا تم تعطيل
00:02:30ميزة الاحتفاظ بالبيانات، فإن أمر /privacy متاح في واجهة سطر الأوامر لتعطيل الاحتفاظ بالبيانات
00:02:36والذي يحذف أيضاً البيانات التي تمت مزامنتها مسبقاً. قم بتشغيل أمر /privacy لعرض أو تغيير
00:02:40إعداداتك في أي وقت”. غرد إيلون أيضاً قائلاً إنه كإجراء احترازي، فإن جميع بيانات المستخدم التي تم
00:02:45رفعها إلى خوادم xAI قبل الآن سيتم حذفها بالكامل وبشكل نهائي، ولن يبقى أي شيء على الإطلاق
00:02:51لكنه طلب أيضاً في تغريدة أخرى أن تترك الإعداد قيد التشغيل لأنه مفيد في الواقع
00:02:55لتصحيح المشكلات إذا كان بإمكانهم الاحتفاظ ببعض البيانات، وهو ما يمكنني تصديقه إذا كنا فقط
00:03:00نتحدث عن التتبعات فهذه ممارسة شائعة جداً، ولكن رفع مستودع كامل إلى خوادمهم
00:03:05لا تبدو أياً من هذه الردود تعالج ذلك الجزء، وتحديث واجهة سطر أوامر Grok الجديد أضاف ببساطة أمر خصوصية
00:03:10لكن يجدر بالذكر أن هذا التحديث لم يقم في الواقع بإزالة الكود الذي يرفع مستودعك بالكامل
00:03:14يمكنك في الواقع لا تزال العثور على ذلك في الملف الثنائي، لذا يبدو أن الشيء الوحيد الذي يمنع هذا من العمل
00:03:18مرة أخرى هو ذلك العلم من جانب الخادم الذي يتم التحكم فيه بواسطة xAI. يبدو لي حقاً أن هذا الكود
00:03:23لا ينبغي أن يكون موجوداً هناك، حيث لا توجد أداة أخرى تستخدمه. بالإضافة إلى ذلك، إذا ألقينا نظرة على أمر الخصوصية الجديد هذا
00:03:28فهو يعطل ببساطة التتبعات ويقلب تبديل جانب الخادم المسمى coding data retention opt-out
00:03:33وقد قام الباحث نفسه في الواقع بتحليل هذا الأمر وأظهر أنه لا يفعل شيئاً محلياً. تتبعات جلستك
00:03:38لا تزال تُرسل إلى xAI بالكامل سواء كان قيد التشغيل أو الإيقاف، والفرق الوحيد هو في
00:03:43كيف يستجيب الخادم، إذا كان معطلاً فسيستجيب بـ 200 مما يعني أنه تم تخزينه
00:03:48وإذا كان وضع الخصوصية قيد التشغيل، فإنه يعيد ببساطة 204 للقول “لا يوجد محتوى” وقد تم التخلص من البيانات
00:03:53لذا فهو في الواقع مجرد مفتاح احتفاظ من جانب الخادم ولا يمنعه من جانب العميل، لذا
00:03:58أنت لا تزال ترسل كل شيء، عليك فقط أن تثق بأن خوادم xAI ستقوم بالفعل بـ
00:04:02التخلص منه بدلاً من تخزينه. حتى لو كنت أثق في xAI، فالأمر يزداد سوءاً لأن أمر الخصوصية هذا
00:04:07هو في الواقع مفتاح تبديل احتفاظ لكل جلسة، لذا قد تضطر إلى تبديله في كل جلسة للحفاظ على
00:04:12بياناتك آمنة. يبدو هذا متراجعاً للغاية بالنسبة لي، ولكن هذا هو الوضع الآن. إذا كنت قد استخدمت
00:04:17واجهة سطر أوامر Grok في الماضي وتريد معرفة ما قد يكون قد تسرب من جهازك، يمكنك التحقق من
00:04:21سجلاتك. يوضح أمر grep هذا لك بالضبط أي الجلسات أدت إلى عمليات الرفع. إذا كنت تأخذ الأمن
00:04:26على محمل الجد، فمن المحتمل أنك سترغب في تدوير كل تلك المفاتيح إذا أظهرت أن بعض
00:04:30هذه البيانات قد تم إرسالها، ما لم تكن تثق تماماً بأن xAI قد حذفت كل هذا. أخيراً، إذا كنت تريد
00:04:35الحفاظ على مظهر من الخصوصية أثناء استخدام واجهة سطر أوامر Grok، على الرغم من أنني ربما لا أوصي بذلك
00:04:40هناك مقال جيد جداً هنا حول كيفية تحصين واجهة سطر أوامر Grok، وهو يوضح لك أين
00:04:44تضبط أشياء مثل تعطيل رفع قاعدة الكود في إعداداتك، مما يجب أن يوقف خط أنابيب الرفع ذلك بقوة. لذا
00:04:49هذه هي القصة، لسبب ما كان Grok يرفع مستودعك بالكامل حتى عندما لم يكن بحاجة إليه، وقد
00:04:53حذفوا على ما يبدو كل تلك البيانات الآن وتراجعوا عن الميزة. لكنني أريد أن أعرف، هل
00:04:58تثق بهم وهل ستستخدم واجهة سطر أوامر Grok من الآن فصاعداً بعد أن عرفت هذا؟ أخبرني في
00:05:02التعليقات أدناه. انتظر هناك، اشترك وكما هو الحال دائماً، أراك في المرة القادمة.

핵심 요약

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

하이라이트

  • قامت واجهة سطر أوامر Grok برفع مستودعات الأكواد البرمجية بالكامل، بما في ذلك ملفات git وسجلات النظام وكلمات المرور، إلى خوادم xAI دون إذن المستخدم.

  • أكد تحليل أمني باستخدام أداة mitm proxy أن واجهة سطر أوامر Grok ترسل حزمة كاملة من المستودع البرمجي حتى عند توجيهها بعدم فتح أي ملفات.

  • استمرت عمليات الرفع غير المصرح بها حتى عند تعطيل إعداد مساعدة تحسين النموذج، وذلك بسبب وجود علم (flag) برمجى يسمى trace_upload_enable مضبوط دائماً على القيمة true.

  • ردت xAI على الواقعة بإضافة أمر /privacy في واجهة سطر الأوامر وإضافة مفتاح تحكم من جانب الخادم لتعطيل رفع قاعدة الكود.

  • أشار تحليل فني إلى أن التحديث الجديد لا يزيل كود الرفع من الملف الثنائي للبرنامج، بل يعتمد فقط على مفتاح تحكم من جانب الخادم لمنع تفعيل الميزة.

  • يؤدي أمر الخصوصية الجديد وظيفة مفتاح تخزين للبيانات من جانب الخادم فقط، بينما تستمر البيانات (التتبعات) في الإرسال من جهاز المستخدم إلى xAI.

타임라인

اكتشاف عملية رفع غير مصرح بها

  • رفعت واجهة سطر أوامر Grok مستودعات المستخدمين، بما في ذلك مفاتيح SSH وكلمات المرور ووثائق حساسة.
  • انتشرت التقارير عن هذه الثغرة عبر تويتر بعد أن شارك مستخدمون أمراً برمجياً يسمى grep يكشف سجلات تؤكد بدء رفع المستودعات.
  • أبلغ مستخدمون عن رفع جميع محتويات أدلة الجذر (home directories) الخاصة بهم.

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

التحليل التقني لسلوك واجهة سطر أوامر Grok

  • استخدم باحثون أداة mitm proxy لفحص حركة المرور واكتشفوا إرسال حزم برمجية تحتوي على المستودع كاملاً.
  • فشلت تعليمات المستخدم الصريحة بمنع فتح الملفات في إيقاف عملية الرفع التلقائي.
  • استمرت عملية الرفع حتى في المستودعات الكبيرة التي يصل حجمها إلى 12 جيجابايت.
  • تجاهل البرنامج إعدادات تعطيل تحسين النموذج لأن علم trace_upload_enable كان مفعلاً بشكل دائم.

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

رد فعل xAI والحلول المقدمة

  • طبقت xAI إصلاحاً صامتاً عبر إضافة علم جديد لتعطيل رفع قاعدة الكود من جانب الخادم.
  • تعهد إيلون ماسك بحذف كافة بيانات المستخدمين التي تم رفعها سابقاً بشكل نهائي.
  • أضاف التحديث الجديد أمر /privacy الذي لا يمنع إرسال البيانات من جهاز المستخدم بل يطلب من الخادم عدم تخزينها.
  • لا يزال الكود المسؤول عن عملية الرفع موجوداً داخل الملف الثنائي للبرنامج.

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

خطوات حماية البيانات للمستخدمين

  • يمكن فحص السجلات المحلية باستخدام أمر grep لتحديد الجلسات التي تضمنت عمليات رفع.
  • يوصى بتغيير مفاتيح الوصول (SSH keys) التي قد تكون تسربت خلال عمليات الرفع السابقة.
  • توجد إعدادات إضافية يمكن ضبطها محلياً لتعطيل مسار رفع قاعدة الكود بشكل جذري.

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

커뮤니티 글

모든 글 보기