Date post: | 29-Mar-2015 |
Category: |
Documents |
Upload: | chaya-fillmore |
View: | 212 times |
Download: | 0 times |
Copyright © 2006 - The OWASP FoundationPermission 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 [email protected] Security Program ManagerMicrosoft Corp.
1
OWASP AppSec Seattle 2006
Who is this Guy?
[email protected] Microsoft employee for 14 years Always in security A pragmatist!
OWASP AppSec Seattle 2006
Windows Vista Engineering Process (from 35,000ft!)
3
PrescriptiveGuidance
ExternalReview
MandatoryEducation
“QualityGates”
Centralanalysis
Threatanalysis
Software Security Science
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.
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 don’t know
• Learn to not make mistakes!• Writing Secure Code 2nd is required
reading
5
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
Copyright © 2006 - The OWASP FoundationPermission 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 … What’s SAL?
7
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
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!
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; } }
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 NULLMust check return value
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’));
}
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);
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
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
Tools DO NOT MAKE SOFTWARE SECURE! They
help scale the process and they help enforce policy
OWASP AppSec Seattle 2006
Threat Analysis
Threat models help find design issues All components in Windows Vista are
threat modeled We’ve learned a great deal about making
TMs easier to create by non-security expertsWe’ve moved away from threat trees to
patterns of threatsRisk heuristics instead of risk calculations
16
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 designsReview codeReview threat modelsPerform black-box testing
17
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
OWASP AppSec Seattle 2006
Windows Vista Defenses
Four broad categoriesSecurity FeaturesService Hardening IsolationMemory defenses
19
OWASP AppSec Seattle 2006
Windows Vista DefensesSecurity Features (1 of 2)
Windows Vista firewall is integrated with IPSecBi-directionalOn by default
BitLocker full volume drive encryptionOnly in Windows Vista Ultimate and EnterpriseMitigate the stolen laptop scenarioProvides integrity for the boot processCan use TPM 1.2 or USB
Windows DefenderCan be disabled by ISVs
20
OWASP AppSec Seattle 2006
Windows Vista DefensesSecurity 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
OWASP AppSec Seattle 2006
Windows Vista DefensesService Hardening (1 of 2)
Services (daemons) are attractive targetsNo need for user interactionLong-livedOften run elevatedMalware often:
Alters the OS Opens network ports
22
OWASP AppSec Seattle 2006
Windows Vista DefensesService 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
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
OWASP AppSec Seattle 2006
Windows Vista DefensesMemory 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
OWASP AppSec Seattle 2006
Windows Vista DefensesMemory 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 it’s enabled in the
BIOS
OWASP AppSec Seattle 2006
Windows Vista DefensesMemory 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
OWASP AppSec Seattle 2006
Windows Vista DefensesMemory 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
OWASP AppSec Seattle 2006
Default Exploit Mitigations on Popular Client Operating Systems
29
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
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
OWASP AppSec Seattle 2006
Backup Slides
33
OWASP AppSec Seattle 2006
Banned APIs
strcpy, strcpyA, strcpyW, wcscpy, _tcscpy, _mbscpy, StrCpy, StrCpyA, StrCpyW, lstrcpy, lstrcpyA, lstrcpyW, _tccpy, _mbccpystrcat, strcatA, strcatW, wcscat, _tcscat, _mbscat, StrCat, StrCatA, StrCatW, lstrcat, lstrcatA, lstrcatW, StrCatBuff, StrCatBuffA, StrCatBuffW, StrCatChainW, _tccat, _mbccatstrncpy, wcsncpy, _tcsncpy, _mbsncpy, _mbsnbcpy, StrCpyN, StrCpyNA, StrCpyNW, StrNCpy, strcpynA, StrNCpyA, StrNCpyW, lstrcpyn, lstrcpynA, lstrcpynWstrncat, wcsncat, _tcsncat, _mbsncat, _mbsnbcat, StrCatN, StrCatNA, StrCatNW, StrNCat, StrNCatA, StrNCatW, lstrncat, lstrcatnA, lstrcatnW, lstrcatnCharToOem, CharToOemA, CharToOemW, OemToChar, OemToCharA, OemToCharW, CharToOemBuffA, CharToOemBuffWalloca, _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, wvnsprintfWstrtok, _tcstok, wcstok, _mbstokmakepath, _tmakepath, _makepath, _wmakepath, _splitpath, _tsplitpath, _wsplitpathscanf, wscanf, _tscanf, sscanf, swscanf, _stscanf, snscanf, snwscanf, _sntscanf_itoa, _itow, _i64toa, _i64tow, _ui64toa, _ui64tot, _ui64tow, _ultoa, _ultot, _ultowgets, _getts, _gettwsIsBadWritePtr, IsBadHugeWritePtr, IsBadReadPtr, IsBadHugeReadPtr, IsBadCodePtr, IsBadStringPtrstrlen, wcslen, _mbslen, _mbstrlen, StrLen, lstrlen
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”