امنیت مبتنی بر زبان های برنامه سازی مهران علیدوست نیا

1. Software Security & Secure Software Engineering امنیت مبتنی بر زبان های برنامه سازیمهران علیدوست نیا

2. فهرست مطالب مقدمه ای بر LBS سیاست های ایمنی و تحلیل آن امن کردن زبان های برنامه سازی کامپایلر های خبره و تصدیق گر کد ها روش های امن سازی انواع داده ای(Data Type)

3. چرا زبان های برنامه سازی؟ به دلایل زیر زبان های برنامه سازی یک ابزار قوی جهت تامین امنیت نرم افزار است: • طراحی زبان های برنامه سازی امن تر • جلوگیری از تولید برنامه های مخرب در زمان کامپایل و پیش از اجرا • بازنویسی کد های برنامه • بازرسی و بازبینی برنامه ها

4. چرا زبان های برنامه سازی (ادامه) • فقط کافی است تصور کنید که یک برنامه با 20.000.000 خط کد داشته باشیم. • 1000برنامه نویساز 100 نقطه مختلف دنیا بر روی آن کار کنند. • و در نهایت روی 100.000.000 کامپیوتر این برنامه اجرا شود و یا دست کم این تعداد کامپیوتر در اجرای آن نقش داشته باشند • در حالی که هر یک خط از برنامه می تواند تاثیرات دلخواه داشته باشد! • این ها همه در شرایطی است که حداقل امتیازات مورد نیاز را در اختیار برنامه قرار می دهیم! اصلاح کدها در تامین امنیت تا چه حد می تواند مفید باشد؟!!

5. چرا زبان های برنامه سازی (ادامه) دیدگاه های مختلف امنیت در سیستم های رایانه ای: • سخت افزار (Hardware) • سیستم عامل و کرنل(OS) • زبان های برنامه سازی (PL) • نرم افزار (Software)

6. امنیت در سطح زبان های برنامه سازی لازمه برقراری امنیت در زبان های برنامه سازی اطمینان از اجرای یک سری قوانین است. • ایجاد سیاست های ایمنی (Safety Policy) • هر سیستمی در ابتدا به یک سری قوانین نیاز دارد • قانون گذار و اجرا کننده قانون • وظیفه قانون گذار وضع قوانین درست و وظیفه مجری، اطمینان از اجرای کامل قوانین است

7. اهداف سیاست های ایمنی جلوگیری از وقوع رخداد های بد • سرویس های حیاتی سیستم غیر فعال شود • نشت اطلاعات محرمانه • اطلاعات مهم سیستمی آسیب ببینند • سیستم برای شکستن کپی رایت استفاده شود • و ...

8. سیاست های ایمنی (Safety Policy) در این قسمت می بایست به این سوالات پاسخ دهیم: • یک سیاست ایمنی چگونه بیان می شود؟ • کدام سیاست ها قابل تعریف هستند؟ • چه چیزهایی اجرای سیاست های ایمنی را ضمانت می کند؟ • به چه چیزهایی می توان اعتماد کرد؟ • اجبار به اعمال سیاست های ایمنی چگونه انجام می گیرد؟

9. یک سیاست ایمنی چگونه بیان می شود؟ • سیاست ایمنی: عملیات خواندن داده ها و ارسال آن به طور هم زمان انجام نشود! • بیان سیاست های ایمنی در سطوح مختلف • در سطح کد void safesend(){if(disk_read) die();…}

10. یک سیاست ایمنی چگونه بیان می شود؟(ادامه) • در سطح منطقی states s. read(s)  (forever(not(send)))(s) • در سطح آتوماتا read send read send S X

11. کدام سیاست ها قابل تعریف هستند؟ safety properties liveness properties Information Flow “good thing eventually happens” آزاد کردن منابع در بند، اجرای درخواست ها “bad thing never happens” ارسال بعد از خواندن، قفل کردن درخواست مجدد، تخطی از محدودیت منابع محرمانگی در برابر درستی در اجرا فقط سطوح دسترسی کافی نخواهد بود

12. چگونگی اجرای سیاست های ایمنی انواع رویکرد ها در اجرای سیاست های ایمنی (Enforcement) • آنالیز ایستا(Static Analysis): قبل از اجرای برنامه • آنالیز پویا(Dynamic Analysis): در هنگام اجرای برنامه • آنالیز پس از اجرا(post-mortem Analysis) دانستن در مورد شکاف ها بهتر از هیچی است!!!

13. Trusted Computing Base (TCB) اجزایی از سیستم که شکست آنها باعث به خطر افتادن امنیت کل سیستم می شود: • TCB یک سیستم عامل شامل کرنل، سیستم محافظت از حافظه و مدیریت دیسک است. • یکی از چالش ها انتخاب سایز TCB با توجه به کاربرد موجود است.

14. اندازه TCB TCB کوچک یا بزرگ؟ • TCB بزرگ و پیچیده خطر وجود باگ ها در سیستم را افزایش داده و همچنین سیستم را ممکن است با مشکلات امنیتی روبرو سازد • TCB ساده و کوچک می تواند راحت تر تست و چک شود و قابلیت اطمینان بیشتری را ایجاد می کند.

15. قابلیت اعتماد به چه کد هایی می توان اعتماد کرد؟ • قابلیت اعتماد یعنی اینکه تا چه اندازه می توان به درستی کد ها اطمینان داشت. • همواره حداقلی برای اعتماد به کد ها در نظر گرفته می شود. • اصل اعتماد: هر چه کمتر اعتماد کنیم امنیت سیستم بالاتر خواهد بود. • راه حل کلیدی داشتن کامپایلر های امن با قابلیت اعتماد بالا میباشد.

16. امتیازات حداقلی Least Privileges • هر قسمت برای اجرای درست عملیات خود می بایست یکسری امتیازات جهت دسترسی به منابع و امکانات سیستم داشته باشد. • در بعد سیستم عامل این اختیارات به صورت دانه درشت در اختیار کاربران قرار می گیرند. • در زبان های برنامه سازی مدرن این سطوح امنیتی با توجه به انواع داده ای زبان مربوط، مدلسازی و اجرا می شوند.

17. بهترین زمان برای اعمال سیاست ها؟ • پیش از اجرا: شامل آنالیز کد، رد کردن کد و بازنویسی • در حال اجرا: بازرسی، لاگ، ایست (halt) و تغییر • پس از اجرا: باز گرداندن به عقب (roll back)، بازرسی، بازیابی کردن (restore)

18. Type Safety • مقادیر پیاده سازی شده توسط برنامه، به طور مستقیم به DT مربوط به آن زبان بستگی دارد. • ADT: انواع داده ای که فقط به وسیله یک سری واسط های خاص مورد دسترسی قرار می گیرند. • انواع داده ای می توانند از داده های ذخیره شده داخلی خود محافظت نمایند (Private Data).

19. Type Safety امنیت انواع داده ای به سه طریق قابل اجرا خواهند بود: • در زمان اجرا • در زمان کامپایل (ML) • به طور تلفیقی (JAVA)

20. آنالیز ایمنی • In-line Referenced Monitor (IRM) • Typed Assembly Language (TAL) • Proof-carrying Code (PCC) • Certifying compilation

21. Referenced Monitor مشاهده اجرای یک برنامه و ایست برنامه در صورت نقض سیاست های ایمنی مثال : • حفاظت از حافظه • کنترل سطح دسترسی • دیوار آتش • و ...

22. Referenced Monitor نکته مهم اینجاست که RM سیستم عامل نمی تواند همه وقایع سیستم را مورد ارزیابی و بازرسی قرار دهد! • نیاز به یک مفسر برای اجرای دینامیک دارد • کارایی را به نوبه خود کاهش می دهد • بیشتر مکانیزم های موجود جهت اجرای سیاست های ایمنی از RM استفاده می کنند. • در نهایت مونیتور ها در دستورات ادغام می گردند.

23. Reference monitor Interpreter Program instrumentation Extension EM Extension Extension EM Base system Base system EM Base system Referenced Monitor

24. Inlined Reference Monitor RM فقط می تواند گذشته را ببیند و در نتیجه نمی تواند liveness policy ها را نیز اجرا نماید. • برای مثال محاسبه اینکه چه موقعی سیستم باید به طور دقیق در حالت ایست (halt) قرار گیرد. • در این موقع بحث Software Fault Isolation (SFI) مطرح می گردد. • کامپوننت های نرم افزاری را در همان فضای آدرس سخت افزاری نگه می دارد در این شرایط برنامه ها می توانند از کد های نا امن بدون ایجاد سربار حفاظت از حافظه استفاده کنند.

25. Inlined Reference Monitor • ایده: - ادغام یک سری سیاست های ایمنی دلخواه در کد های نا مطمئن در زمان اجرا • نتایج حاصله: - کاهش سرباراجرا - سیاست های ایمنی می توانند متناسب با خصوصیات برنامه های کاربردی و حتی متناسب با کاربران خاص اعمال شوند. (با توجه به اینکه در سطح کرنل و یا سیستم عامل عمومی و کلی تعریف میشدند)

26. زبان های برنامه سازی Type-Safe • ایمنی حافظه • نداشتن مشکلاتی از قبیل کد های خود اصلاح گر (self-modifying Codes ) • نداشتن مشکلات پرش های غیر منطقی (Wild Jumps) جاوا به عنوان یک زبان برنامه نویسیType-Safe • برنامه ها نمی توانند از اشاره گر های به حافظه را جعل کنند. • فیلد ها و متد های خصوصی هر شی فقط توسط همان شی مورد دسترسی قرار می گیرند.

27. TAL • سابقه استفاده از آن به سال 1998 بر می گردد. • دو ایده در ایجاد TAL: • خلاص شدن از شر کامپایلر ها یا مفسر ها در پروسه اعمال سیاست های ایمنی • فراهم کردن نوع داده کلی (Generic Data Type) برای کد کردن انواع داده های سیستمی سطح بالا • در عمل بر روی پردازند های 32 بیت اینتل قابل استفاده می باشد.

28. Review on JVM

29. Type-Based Protection (JVM) Trusted Computing Base JVM verifier System Interface JVM Java Source Interpreter javac JIT compiler JVM bytecodes System Binary Binary

30. Ideal verifier System Interface Your favorite language Low-Level IL (SSA) System Binary “Kernel” optimizer TAL در عمل بسیار شبیه JVM و حتی CLR عمل می کند machine code

31. Proof-Carrying Code (PCC) trusted computing base Security Policy Your favorite language verifier System Binary Low-Level IL optimizer • پیدا کردن Proof ها سخت است • اما verify کردن آنها راحت است! machine code

32. Certifying Compiler Source Certifying VC Generator Native Code Compiler Annotations VC Generator Axioms VC & Rules Axioms VC & Rules Proof Proof Proof Checker Generator Code Producer Code Consumer

33. Certifying Compilers • کامپایلر هایی که به طور اتوماتیک PCC را تولید می کنند • VC: در معماری قبل Verification Condition ایمنی کد را پیش بینی می نماید. • VC Generator: شرایط تصدیق یک کد را تولید می کند. • Proof: تصدیق هایی که امنیت هر کد را تضمین می نماید. • در عمل بر روی پردازند های 32 بیت اینتل قابل استفاده می باشد.

34. مزایای PCC

35. رویکرد های دیگر • رویکرد سخت افزاری هدف: بالا بردن سرعت پردازش ایده: افزایش سرعت عملیات Proof با یک سری طراحی سخت افزاری اعمال سیاست های ایمنی در چرخه 4 گانه با استفاده از پیاده سازی HDL روی سخت افزار نتیجه: بالا رفتن سرعت Proof

36. رویکرد های دیگر • زبان های مکمل هدف: تضمین یک سری شروط پیش از اجرای هر بلاک از کد ها ایده: بالا بردن قابلیت های ایمنی در اجرای کدها و تضمین شروط SFI تعریف یک سری دستورات مکمل جهت بالا بردن انعطاف برنامه نویسی با رویکرد امنیتی

37. زبان مدلسازی جاوا JML • Java Modeling Language یک زبان رابط رفتارگرا است که متد های اعمال شده قبل و یا بعد از شرط ها را در کد های برنامه توصیف می کند. متدهای پیش شرط با عبارت requiresو سیاست های ایمنی در قالب ensuresها بیان می گردند.

38. یک مثال ساده class Stack { private int L=0; int b[]=new int [20]; public void push (int x) { b[L++]=x; } public int pop () { int y=0; y=b[--L]; return y; } }//end of class public class Implement { public static void main(String args[]) { Stack st=new Stack(); st.push(2); st.push(3); int n=st.pop(); System.out.println(n); …. }//end of main }//end of class class Stack { private int L=0; Int b[]=new int [20]; /*@ normal behavior @ requires L>0; @ ensures (\result) >= 2 | | @ (\result) <= 18 @*/ public void push (int x) { b[L++]=x; } public int pop () { int y=0; y=b[--L]; return y; } }//end of class

39. کامپایلر شبکه • کامپایلر هایی که وظیفه تولید کد ها تحت شبکه را دارند. • ایده: اجرای کد های امن در بستر شبکه • ابزار مورد استفاده • امنیت برای تولید کننده و مصرف کننده • راه حل: Trusted Compilers Trusted Compiler Consumer Producer

40. پرسش و پاسخ mehran.alidoost.nia@gmail.com

41. منابع [1] B. Schneider, D. Kozen, G. Morrisett, and A. C. Myers, Language-based security for malicious mobile code. In Department of Defense Sponsored Information Security Research: New Methods for Protecting against Cyber Threats, pages 477-494.Wiley, 2007. [2] M.Warnier, Language Based Security for Java and JML, PhD thesis, Radboud University Nijmegen, 2006. [3] D.Kozen. Language-based security, Proc. Conf. Mathematical Foundations of Computer Science (MFCS'99), volume 1672 of Lecture Notes in Computer Science, pages 284-298. Springer-Verlag, September 1999. [4] M. Bartoletti, Static analysis for Java security. Master Thesis, 2001. [5] M. Bartoletti, G. Costa, P. Degano, G. L. Ferrari, F. Martinelli and R. Zunino, Securing Java with local policies, In Workshop on Formal Techniques for Java-like Programs, 2008. [6] K. Marriott, P. J. Stuckey, and M. Sulzmann, Resource usage verification, In Proc, First Asian Programming Languages Symposium, 2003. [7] D. Grossman, Overview of Language-Based Security, 2008. [8] E. Love, Y. Jiny, Y. Makris, Proof-Carrying Hardware Intellectual Property: A Pathway to Trusted Module Acquisition, IEEE Transactions on Information Forensics and Security - Part 1 Volume 7 Issue 1, February 2012.