سلام

لطفاً از این جلسه «فیلم» بگیرین برای امثال بنده که نمی‌تونن بیان!
فقط چون نمی‌تونم بیام نظرم رو همین الآن می‌گم:

این متن طولانیست!

در علم امنیت و امنیت اطّلاعات یه قاعده وجود داره که می‌گه هر چی مشکل
> ساده‌تر باشه احتمال کشفش کم‌تره!
> و اگه دقّت کرده باشین ایده این اکسپلویت خیلی ساده هست! (درخواست حجم نا
> معتری داده از سرور)
> بنده فکر می‌کنم این باگ در حقیقت یه اشتباه برنامه‌نویسی دانشجویی بوده باشه
> (با توجّه به سابقه کسی که اوّلین نویسنده کد باگ‌خور بوده) ولی سیستم‌های
> امنیتی، که کاملاً با قاعده‌ای که اوّل میل گفتم آشنایی دارن، از «خیلی» وقت
> پیش از وجود چنین باگی خبر داشتن و چیزی نگفتن!
> البته تعجّب اصلی بنده از امنیت کار ها و امنیتی‌های ایرانه که چرا متوجّه
> چنین مشکلی نشدن! (بنده خیلی سواد نوشتن raw packet ندارم ولی از خیلی وقت پیش
> فکر می‌کردم با یه همچین ایده‌هایی چه کارها که نمی‌شه کرد! تو پانویس یه مثال
> می‌گم براتون)
> البته بد هم نیست تو این جلسه یه نگاهی هم به سایت‌های دولتی و سازمانی
> ایرانی که قربانی این باگ شدن بندازین! (مثل ایرنیک و شاپرک و ... )
> یه بررسی هم رو این موضوع کنین که «وقتی یه برنامه متن‌باز که کلّی آدم
> حرفه‌ای دارن روش کار می‌کنن این طوری باگ می‌خوره دیگه برنامه‌هایی که کدشون
> بستس چی دارن بگن؟؟» به نظرم بد نباشه! :دی
> -------
> پ.ن.
> این صرفاً یه حدسه و شاید اصلاً درست نیاشه! به عنوان یه penetration
> scenario بهش نگاه کنین!
> مثلاً اگه کسی برای یه وب سرور یه فایلی قرار باشه آپلود کنه بعد بیاد تو هدر
> پکت content-size رو مثلاً بده ۵۱۲ بعد بیاد ۳۱ بایت داده بفرسته بعدش سریع
> EOF و بعد GEF (Group Execution Flag) بعد بقیه ۴۷۸ بایت باقی مونده رو raw
> shell code بفرسته بعد دوباره EOF و بعد EOT (End Of Transmit) خب اون شل کد
> رو سروره اجرا می‌شه!
> بنده فکر می‌کنم برای همینه که وب سرور ها اگه EOF بگیرن ولی حجم داده با حجم
> اعلام شده مطابقت نداشته‌باشه سریع NACK می‌فرستن!
> پ.ن.۲: می‌بخشین اگه طولانی شد!


التماس دعا!
_______________________________________________
general mailing list
[email protected]
http://lists.tehlug.org/mailman/listinfo/general
unsubscribe: http://lists.tehlug.org/mailman/options/general

Reply via email to