امنیت مبتنی بر زبان های برنامه سازی

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

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)

در سطح آتوماتا •

یک سیاست ایمنی چگونه بیان می شود؟)ادامه(

S Xsend

sendreadread

11

کدام سیاست ها قابل تعریف هستند؟

safety properties

Information Flow

liveness properties“bad thing never happens”

ارسال بعد از خواندن، قفل کردن درخواست مجدد، تخطی از محدودیت منابع

“good thing eventually happens” محرمانگی در برابر درستی در اجراآزاد کردن منابع در بند، اجرای درخواست ها

فقط سطو:ح دسترسی کافی نخواهد بود

12

انواع رویکرد ها در اجرای سیاست های ایمنی (Enforcement)(آنالیز ایستاStatic Analysis قبل از اجرای :)

برنامه(آنالیز پویاDynamic Analysis در هنگام اجرای :)

برنامه(آنالیز پس از اجراpost-mortem Analysis)

دانستن در مورد شکاف ها بهتر از هیچی است!!!

چگونگی اجرای سیاست های ایمنی

13

اجزایی از سیستم که شکست آنها باعث به خطر افتادن امنیت کل سیستم می شود:

TCB یک سیستم عامل شامل کرنل، سیستم محافظت از حافظه و مدیریت دیسک است.

یکی از چالش ها انتخاب سایزTCB با توجه به کاربرد موجود است.

Trusted Computing Base (TCB)

14

TCBکوچک یا بزرگ؟

TCB بزرگ و پیچیده خطر وجود باگ ها در سیستم را افزایش داده و همچنین سیستم را

ممکن است با مشکالت امنیتی روبرو سازدTCB ساده و کوچک می تواند راحت تر تست و

چک شود و قابلیت اطمینان بیشتری را ایجاد می کند.

TCBاندازه

15

به چه کد هایی می توان اعتماد کرد؟ قابلیت اعتماد یعنی اینکه تا چه اندازه می توان به

درستی کد ها اطمینان داشت. همواره حداقلی برای اعتماد به کد ها در نظر

گرفته می شود. اصل اعتماد: هر چه کمتر اعتماد کنیم امنیت

سیستم باالتر خواهد بود. راه حل کلیدی داشتن کامپایلر های امن با قابلیت

اعتماد باال میباشد.

قابلیت اعتماد

16

Least Privileges هر قسمت برای اجرای درست عملیات خود می

بایست یکسری امتیازات جهت دسترسی به منابع و امکانات سیستم داشته باشد.

در بعد سیستم عامل این اختیارات به صورتدر اختیار کاربران قرار می گیرند.دانه درشت

در زبان های برنامه سازی مدرن این سطوح زبان مربوط، انواع داده ایامنیتی با توجه به

مدلسازی و اجرا می شوند.

امتیازات حداقلی

17

پیش از اجرا: شامل آنالیز کد، رد کردن کد وبازنویسی

( در حال اجرا: بازرسی، الگ، ایستhaltو تغییر )( پس از اجرا: باز گرداندن به عقبroll back ،)

( restoreبازرسی، بازیابی کردن )

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

18

مقادیر پیاده سازی شده توسط برنامه، به طور مرeبوط به آن زبان بستگی دارد.DTمستقیم به

ADT انواع داده ای که فقط به وسیله یک سری :واسط های خاص مورد دسترسی قرار می گیرند.

انواع داده ای می توانند از داده های ذخیره شده(.Private Dataداخلی خود محافظت نمایند )

Type Safety

19

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

Type Safety

20

In-line Referenced Monitor (IRM)Typed Assembly Language (TAL)Proof-carrying Code (PCC)Certifying compilation

آنالیز ایمنی

21

مشاهده اجرای یک برنامه و ایست برنامه در صورت نقض سیاست های ایمنی

مثال :حفاظت از حافظهکنترل سطح دسترسیدیوار آتش... و

Referenced Monitor

22

سیستم عامل نمی تواند RMنکته مهم اینجاست که همه وقایع سیستم را مورد ارزیابی و بازرسی قرار

دهد!نیاز به یک مفسر برای اجرای دینامیک داردکارایی را به نوبه خود کاهش می دهد بیشتر مکانیزم های موجود جهت اجرای سیاست

استفاده می کنند.RMهای ایمنی از در نهایت مونیتور ها در دستورات ادغام می

گردند.

Referenced Monitor

23

Referenced Monitor

Extension

EMBase system

Reference monitorEM

Extension

Base system

InterpreterExtension

Base system

EM

Program instrumentation

24

RM را ببیند و در نتیجه نمی گذشته فقط می تواند ها را نیز اجرا نماید.liveness policyتواند

برای مثال محاسبه اینکه چه موقعی سیستم باید( قرار گیرد.haltبه طور دقیق در حالت ایست )

در این موقع بحثSoftware Fault Isolation (SFI) مطرح می گردد.

فضای کامپوننت های نرم افزاری را در هماننگه می دارد در این شرایط آدرس سخت افزاری

برنامه ها می توانند از کد های نا امن بدون ایجاد سربار حفاظت از حافظه استفاده کنند.

Inlined Reference Monitor

25

:ایده- ادغام یک سری سیاست های ایمنی دلخواه در کد

های نا مطمئن در زمان اجرا:نتایج حاصله

اجرا سربار- کاهش - سیاست های ایمنی می توانند متناسب با

برنامه های کاربردی و حتی متناسب با خصوصیاتکاربران خاص اعمال شوند. )با توجه به اینکه در

سطح کرنل و یا سیستم عامل عمومی و کلی تعریف میشدند(

Inlined Reference Monitor

26

ایمنی حافظه نداشتن مشکالتی از قبیل کد های خود اصالح گر

(self-modifying Codes ) ( نداشتن مشکالت پرش های غیر منطقیWild

Jumps )-Typeجاوا به عنوان یک زبان برنامه نویسی

Safe های به حافظه اشاره گر برنامه ها نمی توانند از

را جعل کنند. فیلد ها و متد های خصوصی هر شی فقط

توسط همان شی مورد دسترسی قرار می گیرند.

-Typeزبان های برنامه سازی Safe

27

بر 1998سابقه استفاده از آن به سال می گردد.

دو ایده در ایجادTAL: در خالص شدن ا:ز شر کامپایلر ها یا مفسر ها

پروسه اعمال سیاست های ایمنی فراهم کردن( نوع داده کلیGeneric Data Type )

برای کد کردن انواع داده های سیستمی سطح باال

بیت اینتل قابل 32در عمل بر روی پردازند های استفاده می باشد.

TAL

28

Review on JVM

29

Type-Based Protection (JVM)

Java Source

javac

JVM bytecodes

JVM verifier System Interface

Binary

JIT compiler

SystemBinary

JVMInterpreter

Trusted Computing Base

30

Ideal

Your favoritelanguage

Low-Level IL)SSA(

optimizer

machine code

verifier System Interface

SystemBinary“Kernel”

TAL در عمل بسیار شبیه JVM عمل می کندCLRو حتی

31

Proof-Carrying Code (PCC)

Your favoritelanguage

Low-Level IL

optimizer

machine code

verifier SecurityPolicy

SystemBinary

trusted computing base

پیدا کردنProof ها سخت است

اماverify کردن آنها راحت است!

32

Certifying Compiler

Source

Certifying Compiler

VC Generator

VC

Native Code

Annotations

Proof

VC

Axioms & Rules

Proof Generator

Axioms & Rules

Proof Checker

VC Generator

Code Producer Code Consumer

33

کامپایلر هایی که به طور اتوماتیکPCC را تولید می کنند

VC در معماری قبل :Verification Condition ایمنی کد را پیش بینی می نماید.

VC Generator شرایط تصدیق یک کد را تولید می :کند.

Proof تصدیق هایی که امنیت هر کد را تضمین :می نماید.

بیت اینتل قابل 32در عمل بر روی پردازند های استفاده می باشد.

Certifying Compilers

34

PCCمزایای

Type-specialized PCC Foundational PCC

- Relies on VCgen- First-order logic- Built-in understanding of systems- Large (~23000 LOC in Cedilla Systems)

- No VCgen- Higher-order logic- Allows novel type system or safety arguments- Minimal proof checker(2700 LOC)

35

رویکرد سخت افزاریهدف: باال بردن سرعت

پردازشایده: افزایش سرعت

با یک سری Proofعملیات طراحی سخت افزاری

اعمال سیاست های گانه با 4ایمنی در چرخه

استفاده از پیاده سازی HDLروی سخت افزار

نتیجه: باال رفتن سرعت Proof

رویکرد های دیگر

36

زبان های مکملهدف: تضمین یک سری

شروط پیش از اجرای هر بالک از کد ها

ایده: باال بردن قابلیت های ایمنی در اجرای

کدها و تضمین شروط SFI

تعریف یک سری دستورات مکمل جهت باال

بردن انعطاف برنامه نویسی با رویکرد امنیتی

رویکرد های دیگر

37

Java Modeling Language

است که متد های اعمال رفتارگرایک زبان رابط ها را در کد های برنامه قبل و یا بعد از شرط شده

توصیف می کند. و سیاست requiresمتدهای پیش شرط با عبارت

ها بیان می گردند. ensuresهای ایمنی در قالب

JMLزبان مدلسازی جاوا

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

کامپایلر شبکه

ProducerTrusted

Compiler Consumer

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.

منابع