Presentation is loading. Please wait.

Presentation is loading. Please wait.

Copyright © 2006 - The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the Creative Commons Attribution-ShareAlike.

Similar presentations


Presentation on theme: "Copyright © 2006 - The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the Creative Commons Attribution-ShareAlike."— Presentation transcript:

1 Copyright © 2006 - The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the Creative Commons Attribution-ShareAlike 2.5 License. To view this license, visit http://creativecommons.org/licenses/by-sa/2.5/ The OWASP Foundation OWASP AppSec Seattle Oct 2006 http://www.owasp.org/ How the Security Development Lifecycle (SDL) Improved Windows Vista Michael Howard mikehow@microsoft.com Senior Security Program Manager Microsoft Corp. 1

2 OWASP AppSec Seattle 2006 Who is this Guy? mikehow@microsoft.com Microsoft employee for 14 years Always in security A pragmatist!

3 OWASP AppSec Seattle 2006 Windows Vista Engineering Process (from 35,000ft!) 3 Prescriptive Guidance External Review Mandatory Education Quality Gates Central analysis Threat analysis Software Security Science

4 OWASP AppSec Seattle 2006 Why All This Security Work? 4 The threats have changed, customers are demanding increased security and reduced support costs. There is no one silver bullet. The threats have changed, customers are demanding increased security and reduced support costs. There is no one silver bullet.

5 OWASP AppSec Seattle 2006 Guidance and Education All engineers must attend The Basics – Introductory secure design, coding and testing On-going yearly security education required for all engineers – Over a dozen in-depth classes Raise awareness, set expectations, realize what you dont know Learn to not make mistakes! Writing Secure Code 2nd is required reading 5

6 OWASP AppSec Seattle 2006 Quality Gates Stop the Bleeding Catch bugs early Battery of tools run on the check-in that look for: – Banned APIs Enforce use of safer C runtime functions – Correct use of Standard Annotation Language (SAL) – Banned crypto – Buffer overruns – Integer arithmetic issues (overflow, underflow, truncation, signedness) – Weak ACLs – … and much, much more Other quality gates include privacy, reliability etc. 6

7 Copyright © 2006 - The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the Creative Commons Attribution-ShareAlike 2.5 License. To view this license, visit http://creativecommons.org/licenses/by-sa/2.5/ The OWASP Foundation OWASP AppSec Seattle Oct 2006 http://www.owasp.org/ Hang on … Whats SAL? 7

8 OWASP AppSec Seattle 2006 8 Standard Annotation Language Used by static analysis tools such as PREfast and /analyze (Visual Studio 2005) Benefits of adding annotations to your code: – Help the tools find harder to find bugs – The process of adding annotations finds bugs! – Bugs found are low noise

9 OWASP AppSec Seattle 2006 9 SAL at Work void FillString( TCHAR* buf, size_t cchBuf, TCHAR ch) { for (size_t i = 0; i < cchBuf; i++) { buf[i] = ch; } These two arguments are related, but the compiler does not know!

10 OWASP AppSec Seattle 2006 10 SAL at Work void FillString( __out_ecount(cchBuf) TCHAR* buf, size_t cchBuf, TCHAR ch) { for (size_t i = 0; i < cchBuf; i++) { buf[i] = ch; }

11 OWASP AppSec Seattle 2006 11 SAL at Work __out_ecount(cchBuf) Out buffer, function will write to the buffer. Other examples include __in and __inout Element count. Other example includes bcount, byte count. __checkReturn __bcount_opt(_Size) malloc(__in size_t _Size); Optional, can be NULL Must check return value

12 OWASP AppSec Seattle 2006 12 SAL at Work Warning C6386: Buffer overrun: accessing 'argument 1', the writable size is 200*2' bytes, but '420' bytes might be written: Lines: 33, 34 Warning C6387: 'argument 1' might be '0': this does not adhere to the specification for the function 'FillString': Lines: 33, 34 void FillString( __out_ecount(cchBuf) TCHAR* buf, size_t cchBuf, TCHAR ch) { for (size_t i = 0; i < cchBuf; i++) { buf[i] = ch; } void main() { TCHAR *buff = malloc(200 * sizeof(TCHAR)); FillString(buff,210,_T(x)); }

13 OWASP AppSec Seattle 2006 Central Analysis (1 of 2) Inter-procedural static analysis Binary analysis detects compiler and linker requirements Attack Surface Analysis – Weak ACLs, Service configuration, etc. Central removal of banned APIs and weak crypto – ~50% of banned APIs removed automatically – Large % automatically migrated by compiler if destination buffer size is known at compile time 13 char buf[32]; strcpy(buf,src); char buf[32]; strcpy_s(buf,src,32);

14 OWASP AppSec Seattle 2006 Central Analysis (2 of 2) A HUGE quantity of bugs found in the wild today are due to malformed data – Fuzz testing can find these bugs Central fuzz-testing team – Performed primarily by our group Identify and fuzz all file formats consumed by the operating system – Minimum 100,000 malformed files per parser Fuzz many networking protocols, including RPC 14

15 OWASP AppSec Seattle 2006 A Note About Tools 15 Tools DO NOT MAKE SOFTWARE SECURE! They help scale the process and they help enforce policy

16 OWASP AppSec Seattle 2006 Threat Analysis Threat models help find design issues All components in Windows Vista are threat modeled Weve learned a great deal about making TMs easier to create by non-security experts Weve moved away from threat trees to patterns of threats Risk heuristics instead of risk calculations 16

17 OWASP AppSec Seattle 2006 External Review Most security work is performed by core Windows Vista engineers Our team and external security consultants also: Review feature designs Review code Review threat models Perform black-box testing 17

18 OWASP AppSec Seattle 2006 If all the upfront engineering fails… Windows Vista Defenses Core assumptions – Code is never perfect – Designs are never perfect – We must protect customers Remember, security is Man vs. Man – Security is a never-ending arms race – You can never be done with security so long as the adversary is still breathing Windows Vista includes numerous defenses 18

19 OWASP AppSec Seattle 2006 Windows Vista Defenses Four broad categories Security Features Service Hardening Isolation Memory defenses 19

20 OWASP AppSec Seattle 2006 Windows Vista Defenses Security Features (1 of 2) Windows Vista firewall is integrated with IPSec Bi-directional On by default BitLocker full volume drive encryption Only in Windows Vista Ultimate and Enterprise Mitigate the stolen laptop scenario Provides integrity for the boot process Can use TPM 1.2 or USB Windows Defender Can be disabled by ISVs 20

21 OWASP AppSec Seattle 2006 Windows Vista Defenses Security Features (2 of 2) PatchGuard X64 only (a tiny market today) – In Windows XP SP2 and Windows Server 2003 – Rootkits are a huge threat to systems Often load in the kernel Hard to detect Hard to remove – Only load signed code in the kernel – Prevents code from patching the kernel in unsupported ways – Increased stability and security Windows Security Center – Provides holistic security state – Customers understand it – Extensible by ISVs 21

22 OWASP AppSec Seattle 2006 Windows Vista Defenses Service Hardening (1 of 2) Services (daemons) are attractive targets No need for user interaction Long-lived Often run elevated Malware often: Alters the OS Opens network ports 22

23 OWASP AppSec Seattle 2006 Windows Vista Defenses Service Hardening (2 of 2) Many existing services moved out of SYSTEM Describe the privileges you need Per-service identity (SID) Protect objects for just that service Stricter service restart policy Restrict network behavior Eg: foo.exe can only open port TCP/123 inbound |Action=Allow|Dir=In|LPORT=123|Protocol=17 |App=%SystemRoot%\foo.exe 23

24 OWASP AppSec Seattle 2006 Windows Vista Defenses Isolation Users are no longer admins (by default) – Even an admin is not an admin (by default) Integrity levels help contain damage – IE7 runs in low integrity (by default) Protected Mode – Most parts of the operating system are medium integrity – Restricts Write-Up – Helps defend integrity of the operating system 24

25 OWASP AppSec Seattle 2006 Windows Vista Defenses Memory defenses (1 of many) Stack protection (aka /GS, enabled by default) – Detects stack-based overruns – Re-arranges the stack so buffers are in higher memory (helps protect variables) – Moves various arguments to lower memory Stack is randomized for each thread (by default) Heap is randomized (by default) Exception handler protection (aka /SafeSEH, enabled by default) – Exception addresses are verified at runtime 25

26 OWASP AppSec Seattle 2006 Windows Vista Defenses Memory defenses (2 of many) Data Execution Protection (aka NX/XD, enabled by default) Harder to execute data In Windows Vista, DEP cannot be disabled once turned on for a process 26 Most CPUs today support DEP, but make sure its enabled in the BIOS

27 OWASP AppSec Seattle 2006 Windows Vista Defenses Memory defenses (3 of many) Heap defenses (all by default) – Lookasides no longer used – Arrays of free lists no longer used – Early detection of errors due to block header integrity check ENTRY->Flink->Blink == ENTRY->Blink->Flink == ENTRY – Heap TerminateOnCorruption – Dynamic adjustment of algorithms based upon the usage – All enabled by default Integer overflow calling operator::new automatically detected at runtime (by default) 27

28 OWASP AppSec Seattle 2006 Windows Vista Defenses Memory defenses (4 of many) Image randomization (ASLR) – System images are loaded randomly into 1 of 256 slots – Changes on each boot – To be effective, ASLR requires DEP – Enabled by default – Link with /dynamicbase for non-system images Long-lived pointers are encoded and decoded – A successful pointer overwrite must survive the decoding process (XOR with a random number) 28

29 OWASP AppSec Seattle 2006 Default Exploit Mitigations on Popular Client Operating Systems 29 Windows Vista Windows XP SP2 RedHat Enterprise Linux 4 OpenBSD 3.x Apple Mac OS X ImagesSection Reordering EXE Randomization DLL Randomization StackFrame Protection Exception Protection Local Variable Protection Randomization Non-Executable HeapMetadata Protection Randomization Non-Executable Full Coverage Partial Coverage No Coverage

30 OWASP AppSec Seattle 2006 Software Security Science Security is Man vs. Man We must continue to innovate We must continue to learn more about attackers – And how to thwart them We perform root-cause analysis of each security bug We analyze bugs from around the industry We work closely with security researchers Feeds back into the SDL twice a year 30

31 OWASP AppSec Seattle 2006 Summary Threats have evolved Customers are asking Microsoft to provide a more secure base operating system We have substantially improved our development process We have added many defenses to the OS We will continue to provide fundamental security functionality that protects users while still providing opportunities for developers 31

32 OWASP AppSec Seattle 2006 mikehow@microsoft.com http://blogs.msdn.com/michael_howard 32

33 OWASP AppSec Seattle 2006 Backup Slides 33

34 OWASP AppSec Seattle 2006 Banned APIs strcpy, strcpyA, strcpyW, wcscpy, _tcscpy, _mbscpy, StrCpy, StrCpyA, StrCpyW, lstrcpy, lstrcpyA, lstrcpyW, _tccpy, _mbccpy strcat, strcatA, strcatW, wcscat, _tcscat, _mbscat, StrCat, StrCatA, StrCatW, lstrcat, lstrcatA, lstrcatW, StrCatBuff, StrCatBuffA, StrCatBuffW, StrCatChainW, _tccat, _mbccat strncpy, wcsncpy, _tcsncpy, _mbsncpy, _mbsnbcpy, StrCpyN, StrCpyNA, StrCpyNW, StrNCpy, strcpynA, StrNCpyA, StrNCpyW, lstrcpyn, lstrcpynA, lstrcpynW strncat, wcsncat, _tcsncat, _mbsncat, _mbsnbcat, StrCatN, StrCatNA, StrCatNW, StrNCat, StrNCatA, StrNCatW, lstrncat, lstrcatnA, lstrcatnW, lstrcatn CharToOem, CharToOemA, CharToOemW, OemToChar, OemToCharA, OemToCharW, CharToOemBuffA, CharToOemBuffW alloca, _alloca wnsprintf, wnsprintfA, wnsprintfW, sprintfW, sprintfA, wsprintf, wsprintfW, wsprintfA, sprintf, swprintf, _stprintf, _snwprintf, _snprintf, _sntprintf, wvsprintf, wvsprintfA, wvsprintfW, vsprintf, _vstprintf, vswprintf, _vsnprintf, _vsnwprintf, _vsntprintf, wvnsprintf, wvnsprintfA, wvnsprintfW strtok, _tcstok, wcstok, _mbstok makepath, _tmakepath, _makepath, _wmakepath, _splitpath, _tsplitpath, _wsplitpath scanf, wscanf, _tscanf, sscanf, swscanf, _stscanf, snscanf, snwscanf, _sntscanf _itoa, _itow, _i64toa, _i64tow, _ui64toa, _ui64tot, _ui64tow, _ultoa, _ultot, _ultow gets, _getts, _gettws IsBadWritePtr, IsBadHugeWritePtr, IsBadReadPtr, IsBadHugeReadPtr, IsBadCodePtr, IsBadStringPtr strlen, wcslen, _mbslen, _mbstrlen, StrLen, lstrlen

35 OWASP AppSec Seattle 2006 No Weak Crypto No new code must use: MD4, MD5, SHA1 (use SHA2 suite) DES (use AES) RC4 (without crypto review) No symmetric keys <128 bits No RSA keys < 1024 bits No weak random number generation No embedded secrets Be crypt agile


Download ppt "Copyright © 2006 - The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the Creative Commons Attribution-ShareAlike."

Similar presentations


Ads by Google