Transcript Document

‫‪Software Security & Secure Software Engineering‬‬
‫امنیت مبتنی بر زبان های برنامه سازی‬
‫مهران علیدوست نیا‬
‫فهرست مطالب‬
‫مقدمه ای بر ‪LBS‬‬
‫سیاست های ایمنی و تحلیل آن‬
‫امن کردن زبان های برنامه سازی‬
‫کامپایلر های خبره و تصدیق گر کد ها‬
‫روش های امن سازی انواع داده ای(‪)Data Type‬‬
‫‪2‬‬
‫چرا زبان های برنامه سازی؟‬
‫به دالیل زیر زبان های برنامه سازی یک ابزار قوی جهت تامین امنیت نرم افزار‬
‫است‪:‬‬
‫• طراحی زبان های برنامه سازی امن تر‬
‫• جلوگیری از تولید برنامه های مخرب در زمان کامپایل و پیش از اجرا‬
‫• بازنویس ی کد های برنامه‬
‫• بازرس ی و بازبینی برنامه ها‬
‫‪3‬‬
‫چرا زبان های برنامه سازی (ادامه)‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫فقط کافی است تصور کنید که یک برنامه با ‪ 20.000.000‬خط کد داشته‬
‫باشیم‪.‬‬
‫‪ 1000‬برنامه نویس از ‪ 100‬نقطه مختلف دنیا بر روی آن کار کنند‪.‬‬
‫و در نهایت روی ‪ 100.000.000‬کامپیوتر این برنامه اجرا شود و یا دست کم‬
‫این تعداد کامپیوتر در اجرای آن نقش داشته باشند‬
‫در حالی که هر یک خط از برنامه می تواند تاثیرات دلخواه داشته باشد!‬
‫این ها همه در شرایطی است که حداقل امتیازات مورد نیاز را در اختیار برنامه‬
‫قرار می دهیم!‬
‫‪4‬‬
‫چرا زبان های برنامه سازی (ادامه)‬
‫دیدگاه های مختلف امنیت در سیستم های رایانه‬
‫ای‪:‬‬
‫‪ ‬سخت افزار (‪)Hardware‬‬
‫‪ ‬سیستم عامل و کرنل(‪)OS‬‬
‫‪ ‬زبان های برنامه سازی (‪)PL‬‬
‫‪ ‬نرم افزار (‪)Software‬‬
‫‪5‬‬
‫امنیت در سطح زبان های برنامه سازی‬
‫الزمه برقراری امنیت در زبان های برنامه سازی اطمینان از اجرای یک‬
‫سری قوانین است‪.‬‬
‫‪ ‬ایجاد سیاست های ایمنی (‪)Safety Policy‬‬
‫‪ ‬هر سیستمی در ابتدا به یک سری قوانین نیاز دارد‬
‫‪ ‬قانون گذار و اجرا کننده قانون‬
‫‪ ‬وظیفه قانون گذار وضع قوانین درست و وظیفه مجری‪ ،‬اطمینان از‬
‫اجرای کامل قوانین است‬
‫‪6‬‬
‫اهداف سیاست های ایمنی‬
‫جلوگیری از وقوع رخداد های بد‬
‫‪ ‬سرویس های حیاتی سیستم غیر فعال شود‬
‫‪ ‬نشت اطالعات محرمانه‬
‫‪ ‬اطالعات مهم سیستمی آسیب ببینند‬
‫‪ ‬سیستم برای شکستن کپی رایت استفاده شود‬
‫‪ ‬و ‪...‬‬
‫‪7‬‬
‫سیاست های ایمنی (‪)Safety Policy‬‬
‫در این قسمت می بایست به این سواالت پاسخ دهیم‪:‬‬
‫•‬
‫•‬
‫•‬
‫•‬
‫•‬
‫یک سیاست ایمنی چگونه بیان می شود؟‬
‫کدام سیاست ها قابل تعریف هستند؟‬
‫چه چیزهایی اجرای سیاست های ایمنی را ضمانت می کند؟‬
‫به چه چیزهایی می توان اعتماد کرد؟‬
‫اجبار به اعمال سیاست های ایمنی چگونه انجام می گیرد؟‬
‫‪8‬‬
‫یک سیاست ایمنی چگونه بیان می شود؟‬
‫• سیاست ایمنی‪ :‬عملیات خواندن داده ها و ارسال آن به طور هم زمان‬
‫انجام نشود!‬
‫• بیان سیاست های ایمنی در سطوح مختلف‬
‫• در سطح کد‬
‫)‪void safesend(){if(disk_read‬‬
‫}…;)(‪die‬‬
‫‪9‬‬
‫یک سیاست ایمنی چگونه بیان می شود؟(ادامه)‬
‫• در سطح منطقی‬
‫)‪ states s. read(s)  (forever(not(send)))(s‬‬
‫• در سطح آتوماتا‬
‫‪read‬‬
‫‪X‬‬
‫‪send‬‬
‫‪send‬‬
‫‪read‬‬
‫‪S‬‬
‫‪1‬‬
‫کدام سیاست ها قابل تعریف هستند؟‬
‫‪safety‬‬
‫‪properties‬‬
‫‪liveness‬‬
‫‪Information‬‬
‫‪“good thing eventually happens”properties‬‬
‫‪Flow‬‬
‫ها‬
‫خواست‬
‫”‪ happens‬در بند‪،‬‬
‫آزاد کردن منابع‬
‫اجرای در‬
‫‪“bad‬‬
‫‪thing‬‬
‫‪never‬‬
‫محرمانگی در برابر درستی در اجرا‬
‫ارسال بعد از خواندن‪ ،‬قفل کردن درخواست مجدد‪ ،‬تخطی از محدودیت منابع‬
‫فقط سطوح دسترس ی کافی نخواهد بود‬
‫‪11‬‬
‫چگونگی اجرای سیاست های ایمنی‬
‫انواع رویکرد ها در اجرای سیاست های ایمنی (‪)Enforcement‬‬
‫‪ ‬آنالیز ایستا(‪ :)Static Analysis‬قبل از اجرای برنامه‬
‫‪ ‬آنالیز پویا(‪ :)Dynamic Analysis‬در هنگام اجرای برنامه‬
‫‪ ‬آنالیز پس از اجرا(‪)post-mortem Analysis‬‬
‫دانستن در مورد شکاف ها بهتر از هیچی است!!!‬
‫‪12‬‬
‫)‪Trusted Computing Base (TCB‬‬
‫اجزایی از سیستم که شکست آنها باعث به خطر افتادن امنیت کل سیستم‬
‫می شود‪:‬‬
‫‪ TCB ‬یک سیستم عامل شامل کرنل‪ ،‬سیستم محافظت از حافظه و‬
‫مدیریت دیسک است‪.‬‬
‫‪ ‬یکی از چالش ها انتخاب سایز ‪ TCB‬با توجه به کاربرد موجود است‪.‬‬
‫‪13‬‬
‫اندازه ‪TCB‬‬
‫‪ TCB‬کوچک یا بزرگ؟‬
‫‪ TCB ‬بزرگ و پیچیده خطر وجود باگ ها در سیستم را افزایش داده و‬
‫همچنین سیستم را ممکن است با مشکالت امنیتی روبرو سازد‬
‫‪ TCB ‬ساده و کوچک می تواند راحت تر تست و چک شود و قابلیت‬
‫اطمینان بیشتری را ایجاد می کند‪.‬‬
‫‪14‬‬
‫قابلیت اعتماد‬
‫به چه کد هایی می توان اعتماد کرد؟‬
‫‪ ‬قابلیت اعتماد یعنی اینکه تا چه اندازه می توان به درستی کد ها‬
‫اطمینان داشت‪.‬‬
‫‪ ‬همواره حداقلی برای اعتماد به کد ها در نظر گرفته می شود‪.‬‬
‫‪ ‬اصل اعتماد‪ :‬هر چه کمتر اعتماد کنیم امنیت سیستم باالتر خواهد بود‪.‬‬
‫‪ ‬راه حل کلیدی داشتن کامپایلر های امن با قابلیت اعتماد باال میباشد‪.‬‬
‫‪15‬‬
‫امتیازات حداقلی‬
‫‪Least Privileges‬‬
‫‪ ‬هر قسمت برای اجرای درست عملیات خود می بایست یکسری امتیازات‬
‫جهت دسترس ی به منابع و امکانات سیستم داشته باشد‪.‬‬
‫‪ ‬در بعد سیستم عامل این اختیارات به صورت دانه درشت در اختیار‬
‫کاربران قرار می گیرند‪.‬‬
‫‪ ‬در زبان های برنامه سازی مدرن این سطوح امنیتی با توجه به انواع‬
‫داده ای زبان مربوط‪ ،‬مدلسازی و اجرا می شوند‪.‬‬
‫‪16‬‬
‫بهترین زمان برای اعمال سیاست ها؟‬
‫‪ ‬پیش از اجرا‪ :‬شامل آنالیز کد‪ ،‬رد کردن کد و بازنویس ی‬
‫‪ ‬در حال اجرا‪ :‬بازرس ی‪ ،‬الگ‪ ،‬ایست (‪ )halt‬و تغییر‬
‫‪ ‬پس از اجرا‪ :‬باز گرداندن به عقب (‪ ،)roll back‬بازرس ی‪ ،‬بازیابی کردن‬
‫(‪)restore‬‬
‫‪17‬‬
‫‪Type Safety‬‬
‫‪ ‬مقادیر پیاده سازی شده توسط برنامه‪ ،‬به طور مستقیم به ‪ DT‬مربوط‬
‫به آن زبان بستگی دارد‪.‬‬
‫‪ :ADT ‬انواع داده ای که فقط به وسیله یک سری واسط های خاص‬
‫مورد دسترس ی قرار می گیرند‪.‬‬
‫‪ ‬انواع داده ای می توانند از داده های ذخیره شده داخلی خود محافظت‬
‫نمایند (‪.)Private Data‬‬
‫‪18‬‬
‫‪Type Safety‬‬
‫امنیت انواع داده ای به سه طریق قابل اجرا خواهند بود‪:‬‬
‫‪ ‬در زمان اجرا‬
‫‪ ‬در زمان کامپایل (‪)ML‬‬
‫‪ ‬به طور تلفیقی (‪)JAVA‬‬
‫‪19‬‬
‫آنالیز ایمنی‬
In-line Referenced Monitor (IRM)
Typed Assembly Language (TAL)
Proof-carrying Code (PCC)
Certifying compilation
20
‫‪Referenced Monitor‬‬
‫مشاهده اجرای یک برنامه و ایست برنامه در صورت نقض سیاست های‬
‫ایمنی‬
‫مثال ‪:‬‬
‫‪ ‬حفاظت از حافظه‬
‫‪ ‬کنترل سطح دسترس ی‬
‫‪ ‬دیوار آتش‬
‫‪ ‬و ‪...‬‬
‫‪21‬‬
‫‪Referenced Monitor‬‬
‫نکته مهم اینجاست که ‪ RM‬سیستم عامل نمی تواند همه وقایع سیستم‬
‫را مورد ارزیابی و بازرس ی قرار دهد!‬
‫‪ ‬نیاز به یک مفسر برای اجرای دینامیک دارد‬
‫‪ ‬کارایی را به نوبه خود کاهش می دهد‬
‫‪ ‬بیشتر مکانیزم های موجود جهت اجرای سیاست های ایمنی از ‪ RM‬استفاده می‬
‫کنند‪.‬‬
‫‪ ‬در نهایت مونیتور ها در دستورات ادغام می گردند‪.‬‬
‫‪22‬‬
Referenced Monitor
Reference monitor
Extension
EM
Base system
23
Interpreter
EM
Extension
Base system
Program instrumentation
Extension
EM
Base system
‫‪Inlined Reference Monitor‬‬
‫‪ RM‬فقط می تواند گذشته را ببیند و در نتیجه نمی تواند ‪liveness‬‬
‫‪ policy‬ها را نیز اجرا نماید‪.‬‬
‫‪ ‬برای مثال محاسبه اینکه چه موقعی سیستم باید به طور دقیق در حالت ایست‬
‫(‪ )halt‬قرار گیرد‪.‬‬
‫‪ ‬در این موقع بحث )‪ Software Fault Isolation (SFI‬مطرح می گردد‪.‬‬
‫‪ ‬کامپوننت های نرم افزاری را در همان فضای آدرس سخت افزاری نگه می دارد در‬
‫این شرایط برنامه ها می توانند از کد های نا امن بدون ایجاد سربار حفاظت از‬
‫حافظه استفاده کنند‪.‬‬
‫‪24‬‬
‫‪Inlined Reference Monitor‬‬
‫‪ ‬ایده‪:‬‬
‫ ادغام یک سری سیاست های ایمنی دلخواه در کد های نا مطمئن در زمان‬‫اجرا‬
‫‪ ‬نتایج حاصله‪:‬‬
‫ کاهش سربار اجرا‬‫ سیاست های ایمنی می توانند متناسب با خصوصیات برنامه های کاربردی و حتی‬‫متناسب با کاربران خاص اعمال شوند‪( .‬با توجه به اینکه در سطح کرنل و یا سیستم‬
‫عامل عمومی و کلی تعریف میشدند)‬
‫‪25‬‬
‫زبان های برنامه سازی ‪Type-Safe‬‬
‫‪ ‬ایمنی حافظه‬
‫‪ ‬نداشتن مشکالتی از قبیل کد های خود اصالح گر ( ‪self-modifying‬‬
‫‪) Codes‬‬
‫‪ ‬نداشتن مشکالت پرش های غیر منطقی (‪)Wild Jumps‬‬
‫جاوا به عنوان یک زبان برنامه نویس ی ‪Type-Safe‬‬
‫‪ ‬برنامه ها نمی توانند از اشاره گر های به حافظه را جعل کنند‪.‬‬
‫‪ ‬فیلد ها و متد های خصوص ی هر ش ی فقط توسط همان ش ی مورد دسترس ی قرار‬
‫می گیرند‪.‬‬
‫‪26‬‬
‫‪TAL‬‬
‫‪ ‬سابقه استفاده از آن به سال ‪ 1998‬بر می گردد‪.‬‬
‫‪ ‬دو ایده در ایجاد ‪:TAL‬‬
‫‪ ‬خالص شدن از شر کامپایلر ها یا مفسر ها در پروسه اعمال سیاست های ایمنی‬
‫‪ ‬فراهم کردن نوع داده کلی (‪ )Generic Data Type‬برای کد کردن انواع‬
‫داده های سیستمی سطح باال‬
‫‪ ‬در عمل بر روی پردازند های ‪ 32‬بیت اینتل قابل استفاده می باشد‪.‬‬
‫‪27‬‬
Review on JVM
28
Type-Based Protection (JVM)
Trusted Computing Base
JVM verifier
JVM
Java Source
javac
System
Interface
JIT compiler
Interpreter
JVM bytecodes
Binary
29
System
Binary
Ideal
Your favorite
language
Low-Level IL
(SSA)
verifier
“Kernel”
System
Interface
System
Binary
optimizer
machine code
30
JVM ‫ در عمل بسیار شبیه‬TAL
‫ عمل می کند‬CLR ‫و حتی‬
Proof-Carrying Code (PCC)
trusted computing base
Your favorite
language
Low-Level IL
optimizer
machine code
31
verifier
Security
Policy
System
Binary
‫ ها سخت است‬Proof ‫ پیدا کردن‬
!‫ کردن آنها راحت است‬verify ‫ اما‬
Certifying Compiler
Source
VC Generator
Native Code
Certifying
Compiler
Annotations
VC Generator
VC
Axioms
& Rules
VC
Proof
Checker
Code Consumer
32
Proof
Axioms
& Rules
Proof
Generator
Code Producer
‫‪Certifying Compilers‬‬
‫‪ ‬کامپایلر هایی که به طور اتوماتیک ‪ PCC‬را تولید می کنند‬
‫‪ :VC ‬در معماری قبل ‪ Verification Condition‬ایمنی کد را پیش بینی می‬
‫نماید‪.‬‬
‫‪ :VC Generator ‬شرایط تصدیق یک کد را تولید می کند‪.‬‬
‫‪ :Proof ‬تصدیق هایی که امنیت هر کد را تضمین می نماید‪.‬‬
‫‪ ‬در عمل بر روی پردازند های ‪ 32‬بیت اینتل قابل استفاده می باشد‪.‬‬
‫‪33‬‬
PCC ‫مزایای‬
Type-specialized PCC
- Relies on VCgen
- First-order logic
- Built-in understanding of
systems
- Large (~23000 LOC in
Cedilla Systems)
34
Foundational PCC
- No VCgen
- Higher-order logic
- Allows novel type system
or safety arguments
- Minimal proof checker
(2700 LOC)
‫رویکرد های دیگر‬
‫‪ ‬رویکرد سخت افزاری‬
‫هدف‪ :‬باال بردن سرعت پردازش‬
‫ایده‪ :‬افزایش سرعت عملیات ‪ Proof‬با‬
‫یک سری طراحی سخت افزاری‬
‫اعمال سیاست های ایمنی در چرخه ‪ 4‬گانه‬
‫با استفاده از پیاده سازی ‪ HDL‬روی‬
‫سخت افزار‬
‫نتیجه‪ :‬باال رفتن سرعت ‪Proof‬‬
‫‪35‬‬
‫رویکرد های دیگر‬
‫‪ ‬زبان های مکمل‬
‫هدف‪ :‬تضمین یک سری شروط پیش از‬
‫اجرای هر بالک از کد ها‬
‫ایده‪ :‬باال بردن قابلیت های ایمنی در اجرای‬
‫کدها و تضمین شروط ‪SFI‬‬
‫تعریف یک سری دستورات مکمل جهت‬
‫باال بردن انعطاف برنامه نویس ی با رویکرد‬
‫امنیتی‬
‫‪36‬‬
‫زبان مدلسازی جاوا ‪JML‬‬
‫‪ Java Modeling Language‬‬
‫یک زبان رابط رفتارگرا است که متد های اعمال شده قبل و یا بعد از شرط ها را در‬
‫کد های برنامه توصیف می کند‪.‬‬
‫متدهای پیش شرط با عبارت ‪ requires‬و سیاست های ایمنی در قالب ‪ensures‬‬
‫ها بیان می گردند‪.‬‬
‫‪37‬‬
‫یک مثال ساده‬
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
38
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
‫کامپایلر شبکه‬
‫‪ ‬کامپایلر هایی که وظیفه تولید کد ها تحت شبکه را دارند‪.‬‬
‫‪ ‬ایده‪ :‬اجرای کد های امن در بستر شبکه‬
‫‪ ‬ابزار مورد استفاده‬
‫‪ ‬امنیت برای تولید کننده و مصرف کننده‬
‫‪ ‬راه حل‪Trusted Compilers :‬‬
‫‪Consumer‬‬
‫‪Trusted‬‬
‫‪Compiler‬‬
‫‪Producer‬‬
‫‪39‬‬
‫پرسش و پاسخ‬
[email protected]
40
‫منابع‬
[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.
41