needhelp
← Back to blog

Grok Build CLI নিঃশব্দে আপনার পুরো রিপোজিটরি আপলোড করেছে — .env ফাইল সহ

by needhelp
Security
AI Agent
গোপনীয়তা
xAI

cereblab নামে পরিচিত একজন গবেষক আবিষ্কার করেছেন যে xAI-এর Grok Build CLI, সংস্করণ 0.2.93, পুরো git রিপোজিটরি — গোপনীয়তা, সম্পূর্ণ ইতিহাস, সবকিছু — ব্যবহারকারীকে না জানিয়ে একটি Google Cloud Storage বালতিতে কপি করছিল।

কী ঘটেছে

টুলটি দুই ধরনের আউটবাউন্ড অনুরোধ তৈরি করেছিল। মডেলের টার্নগুলি POST /v1/responses-এ যেত। কিন্তু একটি পৃথক POST /v1/storage কল পুরো ওয়ার্কিং ট্রি এবং সম্পূর্ণ .git ইতিহাস বেঁধে gs://grok-code-session-traces-এ পাঠিয়ে দিয়েছিল।

ওই বালতিটি xAI-এর মালিকানাধীন। আপলোডটি CLI ব্যবহার করার একটি পার্শ্বপ্রতিক্রিয়া হিসেবে চলেছিল — কোনো “এক্সপোর্ট” বোতাম নেই, কোনো প্রম্পট নেই, কোনো সতর্কতা নেই।

সংখ্যাগুলি হতবাক করার মতো। ১২ GB-র একটি টেস্ট রিপোজিটরিতে যেখানে মডেল কোনো ফাইল পড়েনি, /v1/responses ~১৯২ KB ট্রান্সমিট করেছে। /v1/storage ৭৩টি চাঙ্কে ৫.১০ GiB পাঠিয়েছে। এটি ২৭,৮০০× ব্যবধান। মডেল ১৯২ KB প্রসঙ্গ ব্যবহার করেছে; xAI-এর সার্ভারগুলো আপনার পুরো রিপোজিটরি পেয়ে গেছে।

ক্যানারি পরীক্ষা

cereblab একটি অনন্য স্ট্রিং সহ never_read_canary.txt নামের একটি ফাইল রেখেছিলেন। প্রম্পটটি আক্ষরিকভাবে ছিল “Reply with exactly: OK. Do not read or open any files.” মডেল টেক্সট মেনে চলেছিল। ক্যানারি স্ট্রিংটি আপলোড করা বান্ডিল থেকে উদ্ধার করা হয়েছিল।

তাই ডেটা এক্সফিলট্রেশন মডেলের অন-ডিমান্ড ফাইল পড়ার দ্বারা চালিত ছিল না। এটি একটি বিল্ট-ইন পাইপলাইন ছিল যা আপনি যা জিজ্ঞাসা করেন তা নির্বিশেষে চলত।

অপ্ট-আউট কেন কাজ করেনি

“মডেলকে উন্নত করুন” নামে একটি সেটিং আছে। এটি বন্ধ করলে আপনার ডেটার প্রশিক্ষণ ব্যবহার বন্ধ হওয়ার কথা। cereblab-এর ক্যাপচার দেখিয়েছে সার্ভার এখনও trace_upload_enabled: true এবং upload_enabled: true ফেরত দিচ্ছিল। আপলোড চলতেই থাকল।

CLI-তে --deny ফ্ল্যাগ আছে যা সীমাবদ্ধ করে মডেল কোন ফাইল পড়তে পারবে। এটি শুধুমাত্র পড়া ব্লক করে। নেটওয়ার্ক ইগ্রেসের ব্যাপারে এটি কিছুই করে না — বান্ডিলটি ইতিমধ্যেই বেরিয়ে যাচ্ছিল।

gist সিদ্ধান্তটি সরাসরি বলেছে: “অপ্ট-আউট করলে আপনার রিপোজিটরি মেশিন ছেড়ে যাওয়া বন্ধ হয় না।”

ক্রস-টুল লিক

ক্যাপচার দেখিয়েছে টুলটি ~/.claude/-এর অধীনের ফাইলগুলিও সুইপ করেছে। এটি একটি ভিন্ন পণ্যের কনফিগ ডিরেক্টরি। অসম্পর্কিত পরিষেবার কীগুলি — cereblab Baidu Miaoda API কী-র উদ্ধৃতি দিয়েছেন — আপনার রিপোজিটরির সাথে মেশিন ছেড়ে গেছে।

আরেকজন গবেষক যিনি ফলাফলগুলি পুনরুৎপাদন করেছিলেন, নিজের লগে ৩৩৯টি স্বয়ংক্রিয় আপলোড খুঁজে পেয়েছেন। সেই আপলোডগুলির একটিতে ছিল তার পুরো হোম ডিরেক্টরি — সম্ভাব্যভাবে SSH কী, পাসওয়ার্ড ম্যানেজার ডেটা, ব্রাউজার প্রোফাইল, সবকিছু প্রকাশ করে।

রিমোট কিল সুইচ

১২ জুলাই, গল্পটি ভাইরাল হওয়ার সাথে সাথে, এমন কিছু ঘটল যা xAI কখনও ঘোষণা করেনি: একই ক্লায়েন্ট বাইনারি, একই SHA-256 হ্যাশ সহ, হঠাৎ ভিন্ন সার্ভার প্রতিক্রিয়া পেতে শুরু করল।

disable_codebase_upload: true. trace_upload_enabled: false.

আপলোড বন্ধ হয়ে গেল। কোনো ক্লায়েন্ট আপডেট নেই। কোনো চেঞ্জলগ নেই। কোনো নোটিফিকেশন নেই।

এর অর্থ xAI-র সবসময়ই যেকোনো Grok CLI ইনস্টলেশনে, যেকোনো সময়, ব্যবহারকারীর অজান্তে ডেটা সংগ্রহ দূরবর্তীভাবে সক্ষম বা অক্ষম করার ক্ষমতা ছিল। তারা কেবল এটি ডিফল্টভাবে চালু রেখে দেওয়া এবং কখনও উল্লেখ না করাই বেছে নিয়েছে।

মাস্ক সাড়া দিলেন

১৪ জুলাই, ইলন মাস্ক একটি শব্দে বিতর্কের জবাব দিলেন: “True.” তিনি আরও বললেন:

“সতর্কতামূলক ব্যবস্থা হিসেবে, এখন পর্যন্ত SpaceXAI-তে আপলোড করা সমস্ত ব্যবহারকারী ডেটা সম্পূর্ণ এবং পুরোপুরিভাবে মুছে ফেলা হবে। একেবারে কিছুই অবশিষ্ট থাকবে না।”

xAI একইসাথে Grok CLI-র জন্য /privacy কমান্ড ঘোষণা করল:

  • /privacy — আপনার বর্তমান ডেটা ধারণ অবস্থা দেখায়
  • /privacy opt-out — ধারণ নিষ্ক্রিয় করে এবং পূর্বে সিঙ্ক করা ডেটার পূর্ববর্তী বিলোপ ট্রিগার করে

অ্যান্ড্রু মিলিচ, Grok Build-এর প্রধান, নিশ্চিত করেছেন যে গোপনীয়তা সেটিংস পরিবর্তন করলে পূর্বে সিঙ্ক করা ক্লাউড ডেটা মুছে ফেলা ট্রিগার হয়। এন্টারপ্রাইজ গ্রাহকরা “Zero Data Retention” (ZDR) মোড পান।

কিন্তু যা বদলায়নি: কোনো নিরাপত্তা পরামর্শ জারি করা হয়নি। সম্মতি ছাড়া কেন পুরো রিপোজিটরি সংগ্রহ করা হয়েছিল তার কোনো ব্যাখ্যা নেই। বিলোপের কোনো স্বাধীন নিরীক্ষা নেই। v0.2.98 চেঞ্জলগ পুরোপুরিভাবে রিপোজিটরি আপলোডের কোনো উল্লেখ বাদ দিয়েছে।

আপনি প্রভাবিত হয়েছেন কিনা যাচাই করার উপায়

  • CLI একটি MITM প্রক্সির পেছনে চালান: HTTPS_PROXY=http://127.0.0.1:8080grok-code-session-traces বালতিতে POST /v1/storage আঘাত করছে কিনা লক্ষ্য রাখুন।
  • বাইনারি / স্ট্রিংস-এ হার্ডকোড করা বালতির নাম grok-code-session-traces খুঁজুন।
  • cereblab-এর রিপ্রো রিপোজিটরিতে verify.sh আছে যা ফেরত আসা বান্ডিল পুনরায় ডাউনলোড ও আনপ্যাক করে যাতে আপনি দেখতে পারেন ঠিক কী বেরিয়ে গেছে।
  • যেকোনো Grok CLI সেশনের সময় Google Cloud Storage-এর দিকে ট্রাফিকের জন্য আউটবাউন্ড ইগ্রেস লগ পরীক্ষা করুন।
  • আপনার বর্তমান ডেটা ধারণ অবস্থা দেখতে Grok CLI-তে /privacy চালান।
  • আরেকজন গবেষক নিজের লগ চেক করে ৩৩৯টি আপলোড পেয়েছেন — আপনি যদি টুলটি ব্যবহার করেই থাকেন, ধরে নিন আপনার রিপোজিটরি মেশিন ছেড়েছে।

করণীয়

  • আরও ডেটা ধারণ নিষ্ক্রিয় করতে এবং ইতিমধ্যে আপলোড করা ডেটা মুছে ফেলার অনুরোধ করতে অবিলম্বে /privacy opt-out চালান।
  • প্রভাবিত সংস্করণটি (0.2.93) সম্পূর্ণরূপে আনইনস্টল করুন।
  • নেটওয়ার্ক স্তরে Google Cloud Storage-এর দিকে ইগ্রেস ব্লক করুন — একটি ফায়ারওয়াল নিয়ম বা Clash প্রত্যাখ্যান নিয়ম: (PROCESS-NAME,grok.exe) && (DOMAIN-SUFFIX,storage.googleapis.com)
  • যদি আপনাকে এটি ব্যবহার চালিয়ে যেতেই হয়, ~/.grok/config.toml-এ যোগ করুন:
    [harness] disable_codebase_upload = true
    [features] telemetry = false
    [telemetry] trace_upload = false
  • এই সংস্করণ দিয়ে খোলা কোনো রিপোজিটরিতে থাকা প্রতিটি ক্রেডেনশিয়াল রোটেট করুন। .env ফাইলগুলি প্রায়শই ট্র্যাক করা হয় বা ওয়ার্কিং ট্রিতে থাকে, এবং .gitignore আপনাকে রক্ষা করে না — বান্ডিল নির্বিশেষে ট্র্যাক করা ফাইল নিয়ে গেছে। সবকিছু আপসকৃত হিসেবে গণ্য করুন।

ডেটা মুছে ফেলা যায়। বিশ্বাস, এত সহজে নয়।

তথ্যসূত্র

Share this page