عجیب ترین نکته در مورد اشکال امنیتی اپل چقدر ساده است

توسط irmusic4, آگوست 2, 2021


عجیب ترین نکته در مورد اشکال امنیتی اپل چقدر ساده است
اکثر دستگاه های iPhone ، iPad و iPod Touch و همچنین تعداد بسیار زیادی از Mac هایی که نسخه های فعلی و جدید OS X را اجرا می کنند (هر نسخه از نسخه 10.9 Mavericks) تحت تأثیر قرار گرفتند. (می توانید به سایت gotofail.com مراجعه کنید تا ببینید آیا دستگاه شما تحت تأثیر قرار گرفته است یا نه).
این آسیب پذیری فوق العاده بد و در همه جا وجود دارد ، اما هنوز هم همان اشکالی است که به طور مداوم در بخش های مختلف نرم افزار وصله می شود و گروه های هکر دائماً مراقب آنها هستند.
جدا از شدت آن ، این اشکال کیفیت فوق العاده دیگری نیز دارد: بسیار ساده است. (به اندازه کافی ساده که اشکال روی تی شرت است.) احمقانه ، حتی. در نود و نه درصد از مواقع ، این نوع اشتباهات احمقانه ضرری ندارد. اما این 1 درصد مواقع ، خدایان شما را نجات نمی دهند.
از آنجا که کد مورد نظر منبع باز بود ، برخی از افراد در YCombinator به سرعت آن را پیدا کردند. آنها آن را به عنوان ظاهر شدن اولین بار در انتشار 10.9 کد OS X ثابت کردند. آدام لانگلی ، استاد راهنمای امنیت وب وب ، تحلیل تکنیکی خوبی از این اشکال ارسال کرد. اما غیر رمزگذارها نیز باید در این مورد چیزی بدانند ، زیرا این اشکال یک درس شی در مورد شکننده بودن کدی است که به طور فزاینده ای می تواند زندگی ما را کنترل کند. سادگی با یک خط کد نادرست به یکی از بزرگترین حفره های امنیتی که تاکنون ایجاد شده است ، ترس را به قلب مهندسان وارد می کند. خوب زیرپوش نگاه کنید.
در زیر کد C حاوی اشکال وجود دارد که در عمق کارکرد امنیتی موسوم به SSLVerifySignedServerKeyExchange رخ می دهد. این عملکرد مطمئن می شود سایتی که رایانه شما از طریق یک خط رمزگذاری شده با آن صحبت می کند (مانند google.com یا chase.com) واقعاً همان سایت است ، به جای اینکه “مردی در وسط” وانمود کند که آن سایت است. اشکال باعث می شود عملکرد ادعا کند که سایت قانونی است ، حتی اگر اینگونه نباشد.
خطای OSStatus؛
if ((err = ReadyHash (& SSLHashSHA1 ، & hashCtx))! = 0)
شکست خوردن
if ((err = SSLHashSHA1.update (& hashCtx، & clientRandom))! = 0)
شکست خوردن
if ((err = SSLHashSHA1.update (& hashCtx، & serverRandom))! = 0)
شکست خوردن
if ((err = SSLHashSHA1.update (& hashCtx و signParams))! = 0)
شکست خوردن
شکست خوردن
if ((err = SSLHashSHA1.final (& hashCtx و hashOut))! = 0)
شکست خوردن
مردود شدن:
بازگشت اشتباه
حتی اگر قبلاً کدی را ندیده باشید ، ممکن است در اینجا یک ناهنجاری ساختاری آشکار مشاهده کنید ، یعنی این که یک عبارت “اگر” به جای یک عبارت ، دو “شکست خورده” دنبال می شود. اگر این موضوع به سمت شما پرید ، تبریک می گویم! اشکال را پیدا کردید
بگذارید کمی کد را ساده کنم تا به اصل اشکال پی ببرم:
وضعیت OSStatus = EVERYTHING_IS_GREAT؛
بیشتر if ((status = DoSomeSecurityStuff) خطرناک است)
شکست خوردن
if ((status = KeepDoingSecurityStuff) خطرناک است)
شکست خوردن
شکست خوردن
if ((status = DoTheMostImportantSecurityStuff) خطرناک است)
شکست خوردن
مردود شدن:
وضعیت بازگشت
این خط ها برخی محاسبات را انجام می دهند که اعتبار داده های تأیید اعتبار را که سرور (واقعی یا جعلی) برای شما مشتری ارسال کرده است ، آزمایش می کنند. در هر خط “اگر” ، یک متغیر با عنوان “وضعیت” یا EVERYTHING_IS_GREAT یا DANGER تنظیم شده است. اگر وضعیت در پایان کد هنوز EVERYTHING_IS_GREAT باشد ، این تابع به بقیه برنامه می گوید که همه چیز در واقع عالی است و احراز هویت انجام شده است. اگر مشکلی پیش آمد ، خطر را به بقیه برنامه برمی گرداند. هر زمان که بخشی از چک خطر را برمی گرداند ، کد برای خاتمه بررسی امنیتی اذیت نمی کند – قبلاً شکست خورده است ، پس چرا مزاحم می شوید؟ این فقط از طریق عبارت “goto fail” به انتهای کد می پرد ، که باعث می شود کامپیوتر با برچسب “fail:” درست بالای آن به انتهای کد بپرد.
تا زمانی که وضعیت EVERYTHING_IS_GREAT باقی بماند ، رایانه عبارات “اگر” را ادامه می دهد و چون خطری وجود ندارد ، از عبارات “شکست خوردن” عبور می کند.
مگر نه آنچه کامپیوتر از آن کد بالا می سازد در واقع این است:
وضعیت OSStatus = EVERYTHING_IS_GREAT؛
if ((status = DoSomeSecurityStuff) خطرناک است)
شکست خوردن
if ((status = KeepDoingSecurityStuff) خطرناک است)
شکست خوردن
شکست خوردن
if ((status = DoTheMostImportantSecurityStuff) خطرناک است)
شکست خوردن
مردود شدن:
وضعیت بازگشت
جمله “اگر” فقط اولین عبارت بعد از آن را کنترل می کند. بنابراین اگر یک مورد بعد از آن وجود داشته باشد – مانند یک دوم “از کار بیفتد” – این عبارت تمام مدت اجرا خواهد شد. به عبارت دیگر ، جمله آخر “اگر” ، با DoTheMostImportantSecurityStuff در آن ، هرگز اجرا نمی شود (به همین دلیل من آن را خط زدم). از آن بدتر ، اگر KeepDoingSecurityStuff همه چیز را برگرداند _ آنقدر بزرگ است ، آنگاه وضعیت EVERYTHING_IS_GREAT خواهد بود ، حتی اگر DoTheMostImantantSecurityStuff هرگز اتفاق بیشتر بخوانید نیفتاده باشد. و بنابراین بررسی امنیتی در مواقعی که لازم نبوده “موفقیت آمیز است”.
این یک کد مهم برای ماموریت است و من نمی توانم باور کنم که اپل با اره برقی به سراغش می آمد.
چگونه روی زمین به آن دومین “شکست” اضافه شد؟ برخی از علاقه مندان به توطئه پیشنهاد کرده اند که این یک هک هوشمندانه آژانس امنیت ملی است تا بتواند آنها را راحت تر از همه جاسوسی کند. نمیخرمش من همچنین فکر نمی کنم که مهندسی این تغییر را در ویرایش دستی ایجاد کرده باشد – امیدوارم به هیچ وجه نباشد. تغییرات افزایشی در کد امنیتی حیاتی معمولاً با دقت زیادی انجام می شود و در هر محیط حرفه ای ، تغییرات همیشه توسط مهندس دیگری بررسی می شود. لغزش هایی مانند این موارد معمولاً بیشتر دیده می شوند که یک برنامه نویس در واقع به طور جدی روی کد کار نمی کند بلکه به نوعی نگهداری یا نگهداری از خانه را روی آن انجام می دهد.
به احتمال زیاد (بر اساس این تفاوت ، یا مجموعه ای از تغییرات ، بین نسخه های بدون اشکال و باگ کد) ، خط اضافی وقتی که یک برنامه نویس ادغام نسبی خودکار دو نسخه مختلف از این کد منبع را انجام می دهد ، و فایل نتیجه ، رخ می دهد تصویب شد بدون اینکه کسی خیلی دقیق به آن نگاه کند پایگاه های کد شامل “نسخه” ها و “شاخه های” مختلف کد هستند تا افراد بتوانند روی پروژه های بلند مدت و اصلاحات کوتاه مدت کار کنند بدون اینکه روی انگشتان پای یکدیگر قدم بگذارند. هر از گاهی ، باید تغییرات ایجاد شده بین شاخه ها را ادغام کنید. بنابراین اگر من در اپل بودم ، ممکن بود مجبور باشم دو نسخه مختلف از این پرونده را ادغام کنم ، و برای اطمینان از خوب بودن آن ، آن را جستجو کردم. من ممکن است خیلی جدی به هر تغییری توجه نکنم ، زیرا تصور می کنم که یک تغییر تفاوت بین این دو نسخه را منعکس می کند ، و نه معرفی کد جدید باگی. من می توانم اشتباه کنم ، اما این یک کد مهم برای مأموریت است و من نمی توانم باور کنم که اپل با اره برقی به آن می پرداخت.
جلوگیری از اشکالاتی از این دست یکی از بزرگترین چالشهای مهندسی نرم افزار است و این اتفاق باید لعنتی بودن دلیل آن را روشن کند. یک خط کد اضافی امنیت میلیون ها و میلیون ها نفر را به خطر انداخته است و هیچ کس بیش از یک سال آن را گرفت.
حتی در یک محیط دقیق بررسی کد ، تست خودکار و توسعه با کیفیت بالا ، اشکالاتی از این دست از بین می روند. اما پیچیدگی مطلق کد امروز ، گرفتن همه چیز را بسیار دشوار می کند. برخی از افراد این کد را زیر پا گذاشته اند و می گویند این کد بیش از حد شلخته و بی دقت است. گرچه من از همه انتخاب های سبک و ساختاری هیجان زده نیستم ، اما به نظر من کد با استانداردهای امروزی بسیار مناسب است. اگر اپل خوب نبود این کد را به عنوان منبع آزاد منتشر نمی کرد و حتی اگر آنها هم بودند ، اگر آنها این کد را بررسی می کردند و متوجه می شدند که این یک زباله است ، اعتراض زیادی از سوی جامعه منبع باز صورت می گرفت. . افرادی که آن را نوشتند می دانستند که چه می کنند. این اشکال در واقع ناشی از سهل انگاری است ، اما نکته غم انگیز و ترسناک این است که ، برای توسعه دهندگان نرم افزار ، این “آنچه آنها فکر می کردند” نیست. لحظه این لحظه “اوه خدای من ، که می توانست من باشم” است.
دیوید اورباخ نویسنده و مهندس نرم افزار مستقر در نیویورک است. وب سایت وی
برای اعلان های Insider ثبت نام کنید! با آنچه می خواهید بدانید به روز باشید. برای اطلاع رسانی های فشرده مشترک شوید

دیدگاه شما چیست؟

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *