বিচ্ছিন্ন স্ক্রিন সেশনে কোনও রুট শেলটি চালানো কি নিরাপদ?


20

আমি বিচ্ছিন্ন স্ক্রিন সেশনের অভ্যন্তরে একটি রুট শেল ছেড়ে যাওয়ার সুরক্ষা সম্পর্কে আগ্রহী। আমি সাধারণত কখনই এটি করি না।

আমার অ-রুট ব্যবহারকারীর অ্যাকাউন্টের আপোস হওয়ার সম্ভাবনা বাদ দিয়ে (পাসওয়ার্ড উন্মুক্ত, এসএস কী কী আপোসড ইত্যাদি), সেখানে কি আলাদা হওয়া, পাসওয়ার্ড-সুরক্ষিত স্ক্রিন সেশনে আমার প্রবেশের অন্যান্য ভেক্টর রয়েছে যা আমি উদ্বিগ্ন হওয়া উচিত, বা একটি বিচ্ছিন্ন স্ক্রিন করতে পারি? অধিবেশন জড় বিবেচনা?


এটি কোনও উত্তর নয় কারণ আমি এটি জানি না, তবে আমি মনে করি না যে এটি আপনার কথা মতো কাজ করা এবং কাজ ছেড়ে দেওয়ার মধ্যে কোনও পার্থক্য করে sudo
ফোনেহেহে 4'11

7
@ ফুনেহে একটি পার্থক্য আছে কারণ যখন একটি কাজ সম্পূর্ণ হয়, sudoনিষ্ক্রিয় হয় যখন সত্যিকারের শেল খোলা থাকে।
মাইকেল

উত্তর:


5

আমি মনে করি এটি একটি সুরক্ষা ইস্যু, কারণ "আমার অ-রুট ব্যবহারকারী অ্যাকাউন্টের সাথে আপোস হওয়ার সম্ভাবনা বাদ দিয়ে" আরও বড় হতে পারে।

তবে এর বাইরেও আরও বর্ধিত ঝুঁকি রয়েছে। উদাহরণস্বরূপ, আপনি এখন নিজেকে একটি তাত্ত্বিক শোষণের জন্য উন্মুক্ত করেছেন যা স্ক্রিন সকেট দির ( /var/run/screenআমার সিস্টেমে তবে কখনও কখনও /tmpব্যবহৃত হয়) এর অনুমতি পরিবর্তন করতে দেয় one সেই শোষণের এখন রুট হওয়ার পথে রয়েছে, যা অন্যথায় তা নাও হতে পারে।

sudoঅন্যান্য সুবিধাগুলি রয়েছে, যদি আপনি প্রতিটি কমান্ড না করে বরং এটি ব্যবহার করার জন্য নিজেকে প্রশিক্ষণ দিতে পারেন sudo su -। এটা তোলে কর্ম লগ (যা, যদি না আপনি দূরবর্তী অবস্থান থেকে লগ-ইন করছি, অর্থপূর্ণ নিরাপত্তা বৃদ্ধি করে না, কিন্তু কি আপনি একটি লেজ দিতে না আপনি থাকেন সম্পন্ন)। এবং এটি সম্পূর্ণ-সুবিধাপূর্ণ অধিবেশনে স্যুইচ না করে প্রতিটি কমান্ডের জন্য ইচ্ছাকৃতভাবে বর্ধনের প্রয়োজনে দুর্ঘটনা রোধে সহায়তা করে।


1
যদিও এই জাতীয় কোনও শোষণ এখন জানা যায় নি, আমি স্ক্রিনে রুট শেলগুলি খোলা না রেখেই চলেছি । ব্যবহারকারীর অ্যাকাউন্টে ঝুঁকি যেমন রয়েছে তেমন যথেষ্ট। ধন্যবাদ।
মাইকেল

-1 আমার যদি এমন শোষণ হয় যা ফাইল অনুমতিগুলি পরিবর্তন করতে পারে তবে আমার কিছু চলমান স্ক্রিন হ্যাক করার দরকার নেই। আমি সিস্টেমের সাথে যা চাই তা করতে পারি।
যাক_আমি_পুন

@ লেট_মে_বি - এটি আপনার শোষণের জন্য কোন ফাইলের অনুমতি অনুমতি দেয় তার উপর নির্ভর করে । হতে পারে আপনি নির্দিষ্ট শ্রেণিবদ্ধের অধীনে কেবলমাত্র কয়েকটি নির্দিষ্ট কাজ করতে পারেন। এতো দূরের কথা নয়।
ম্যাটডেম

স্ক্রিনে নিজেই একটি বড় আক্রমণ পৃষ্ঠ রয়েছে। আমার কাছে দেখাতে পুরো আক্রমণ নেই , তবে স্পষ্ট দুর্বলতা রয়েছে।
গিলস 21'16

আমি ভুল হলে আমাকে সংশোধন করুন, তবে পর্দার অ্যাপ্লিকেশনটি শেল সেশনের মাধ্যমে (সরাসরি সিস্টেম কনসোলে, অথবা কোনও এসএস সেশনের মাধ্যমে) ইন্টারফেস করা হয়। আমি যতদূর জানি এটি কোনও নেটওয়ার্কিং প্রোটোকল নয়। সুতরাং এটি আপনার এসএস সেশন বা টার্মিনাল সেশনের মতোই সুরক্ষিত। কারও কাছে যদি ssh সেশন, বা আপনার শারীরিক মেশিনে অ্যাক্সেস থাকে তবে সমস্ত বেট বন্ধ রয়েছে। যদি কোনও ব্যবহারকারীর অ্যাকাউন্টের অধীনে কোনও ধরণের কমান্ড লাইন পেতে তাদের যদি পর্যাপ্ত অ্যাক্সেস থাকে তবে আপনি পাশাপাশি আপনার মেশিনের সুরক্ষা দূরে ফেলে দিতে পারেন।
অবিচ্ছিন্ন ized

10

যদি আপনার কোনও স্ক্রিন সেশনে রুট শেল থাকে (বিচ্ছিন্ন বা না, পাসওয়ার্ড-সুরক্ষিত বা না) এবং আপনার screenএক্সিকিউটেবল সেটেক্সিড না হয়, তবে কোনও আক্রমণকারী যে আপনার সুযোগসুবিধা অর্জন করে that শেলটিতে কমান্ড চালাতে পারে। আর কিছু না হলে তারা স্ক্রিন প্রক্রিয়া ptracing করে এটি করতে পারে।

যদি স্ক্রিন সেটুইড বা সেটজিড হয় এবং সেশনটি আলাদা করে রাখা হয় এবং পাসওয়ার্ড-সুরক্ষিত থাকে, তবে নীতিগতভাবে এটি শেলের কমান্ডগুলি চালাতে স্ক্রিনের পাসওয়ার্ড নেয়। যদি এই নীতিটি ধরে রাখে তবে যে কেউ আপনার অ্যাকাউন্টে কেবল আপস করেছেন সেটিকে একটি ট্রোজান রাখতে হবে এবং আপনার পাসওয়ার্ডটি টাইপ করার জন্য অপেক্ষা করতে হবে। তবে আক্রমণ পৃষ্ঠ (যেমন কোনও বাগ বা ভুল কনফিগারেশনের কারণে জিনিসগুলি ভুল হতে পারে এমন জায়গাগুলির সংখ্যা) অস্বস্তিকরভাবে বড়। বেসিক সিস্টেম সুরক্ষা বৈশিষ্ট্যগুলি ছাড়াও, আপনি বিশ্বাস করছেন:

  • পাসওয়ার্ড চেক করতে ডান স্ক্রিন।
  • স্ক্রিনটি অন্য উপায়ে সেশনে অ্যাক্সেস রোধ করতে।
  • ওএস অ্যাক্সেস নিয়ন্ত্রণ ব্যবস্থাকে সঠিকভাবে ব্যবহার করতে পর্দা (যেমন পাইপগুলিতে অনুমতি)।
  • সঠিকভাবে ptrace সুরক্ষা পরীক্ষা করার কর্নেলটি (এটি ঘন ঘন দুর্বলতার উত্স)।
  • বোকা কিছু করতে না চলমান শেল।
  • আপনাকে কামড় না দেওয়ার মতো আরও কিছু বৈশিষ্ট্য।

"আপনাকে কামড়াতে না পারে এমন আরও কিছু বৈশিষ্ট্য": হ্যাঁ, এটি অস্পষ্ট। তবে এটি সুরক্ষার ক্ষেত্রে সর্বদা উদ্বেগের বিষয়। আপনি এটিকে কেবল সরল ইচ্ছাকৃত চিন্তাভাবনা হিসাবে প্রত্যাখ্যান করার জন্য প্রলুব্ধ হতে পারেন, তবে আপনি কি সত্যিই সবকিছু ভেবেছিলেন? উদাহরণ স্বরূপ…

যতক্ষণ আপনি টার্মিনাল ডিভাইসে লিখতে পারেন, আপনি সেই শেলের ইনপুটটিতে ডেটা ইনজেক্ট করতে পারেন can আমার মেশিনে স্ক্রিনের ডিফল্ট কনফিগারেশন অনুসারে:

printf '\ekfoo\017bar\e\\' >/dev/pts/33
printf '\e[21t' >/dev/pts/33

এটি ␛]lfoobar␛lশেলের ইনপুট প্রবাহে সন্নিবেশ করায় । \ekনিয়ন্ত্রণ ক্রম যা কোনও অ্যাপ্লিকেশনকে (বা যে কোনও কিছুই টার্মিনাল ডিভাইসে লিখতে পারে) উইন্ডো শিরোনাম সেট করে ( স্ক্রিন ম্যানুয়ালটিতে "নামকরণ উইন্ডোজ" বিভাগটি দেখুন ), এবং \e[21tটার্মিনালটিকে অ্যাপ্লিকেশনটির স্ট্যান্ডার্ড ইনপুটটিতে তার শিরোনাম প্রতিবেদন করে তোলে ( পর্দা এই ক্রম নথি যাবে না, তবে তা বাস্তবায়ন আছে; আপনি অধীনে তা খুঁজে পেতে পারেন CSI Ps ; Ps ; Ps ; txterm নিয়ন্ত্রণ সিকোয়েন্স তালিকা বস্তুত, পর্দা 4.0.3 অধীনে কমপক্ষে, সমস্ত কন্ট্রোল ক্যারেক্টার রিপোর্ট শিরোনাম থেকে ছিনতাই, তাই শেল পড়ে। lfoobar(ধরে ␛]নেওয়া কোনও এডিটিং কমান্ডের সাথে আবদ্ধ নয়) এবং কোনও নতুন লাইন নেই So সুতরাং আক্রমণকারী আসলে কোনও কমান্ড কার্যকর করতে পারে না, তবে একটি কমান্ডের মতো করতে পারেchmod u+s /bin/sh এর পরে প্রচুর স্পেস এবং সম্ভাব্য চেহারার প্রম্পট।

স্ক্রিন অন্যান্য বেশ কয়েকটি অনুরূপ ঝুঁকিপূর্ণ নিয়ন্ত্রণ ক্রম প্রয়োগ করে, দুর্বলতার জন্য তাদের সম্ভাবনা কী তা আমি জানি না। তবে আশা করি এখনই আপনি দেখতে পাবেন যে স্ক্রিন সেশন পাসওয়ার্ড দ্বারা প্রদত্ত সুরক্ষাটি এটি দুর্দান্ত নয়। সুডোর মতো একটি উত্সর্গীকৃত সুরক্ষা সরঞ্জামের দুর্বলতা হওয়ার সম্ভাবনা অনেক কম।


+1 দুর্দান্ত উত্তর। সব কিছু ব্যাখ্যা করার জন্য সময় দেওয়ার জন্য ধন্যবাদ।
মাইকেল

1

পর্দার দ্বারা তৈরি পাইপগুলি কেবলমাত্র মালিকের দ্বারা অ্যাক্সেসযোগ্য, তাই এটি কোনও সুরক্ষা সমস্যা হওয়া উচিত নয়।


5
আপনি আপনার বাক্যটির প্রথম অংশে "আছেন" ব্যবহার করেছেন যেখানে আপনি সম্ভবত "হওয়া উচিত" বোঝাতে চেয়েছিলেন। আসুন অনুমান করা অভ্যাসে না get
শাদুর

1
উহ? পর্দার দ্বারা তৈরি পাইপগুলি কেবলমাত্র মালিকের দ্বারা অ্যাক্সেসযোগ্য (যদি আপনি ম্যানুয়ালি সেগুলি chmod না করেন)।
যাক_আমি_পুন
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.