OWASP
AppSec
Seattle
Oct 2006
How the Security Development
Lifecycle (SDL) Improved
Windows Vista
Michael Howard mikehow@microsoft.com
Senior Security Program Manager
Microsoft Corp.
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 http://www.owasp.org/ 1

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

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

Why All This Security Work?
OWASP AppSec Seattle 2006
4

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
OWASP AppSec Seattle 2006
5

“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.
OWASP AppSec Seattle 2006
6

Hang on … What’s SAL?
OWASP
AppSec
Seattle
Oct 2006
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 http://www.owasp.org/ 7

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
8

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

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
10

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

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;
}
} void main() {
TCHAR *buff = malloc(200 * sizeof(TCHAR));
FillString(buff,210,_T(’x’));
}
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
OWASP AppSec Seattle 2006
12

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 char buf[32]; strcpy(buf,src); char buf[32]; strcpy_s(buf,src,32);
OWASP AppSec Seattle 2006
13

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
OWASP AppSec Seattle 2006
14

A Note About Tools
OWASP AppSec Seattle 2006
15

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 experts
 We’ve moved away from threat trees to patterns of threats
 Risk heuristics instead of risk calculations
OWASP AppSec Seattle 2006
16

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
OWASP AppSec Seattle 2006
17

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
OWASP AppSec Seattle 2006
18

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

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
OWASP AppSec Seattle 2006
20

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
OWASP AppSec Seattle 2006
21

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
OWASP AppSec Seattle 2006
22

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
OWASP AppSec Seattle 2006
23

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
OWASP AppSec Seattle 2006
24

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
OWASP AppSec Seattle 2006
25

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
† Most CPUs today support DEP, but make sure it’s enabled in the BIOS
OWASP AppSec Seattle 2006
26

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)
OWASP AppSec Seattle 2006
27

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)
OWASP AppSec Seattle 2006
28

Default Exploit Mitigations on Popular Client
Operating Systems
Images Section Reordering
EXE Randomization
Stack
DLL Randomization
Frame Protection
Exception Protection
Local Variable Protection
Randomization
Non-Executable
Heap Metadata Protection
Randomization
Non-Executable
Full Coverage
Partial Coverage
No Coverage
OWASP AppSec Seattle 2006
29

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
OWASP AppSec Seattle 2006
30

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
OWASP AppSec Seattle 2006
31

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

Backup Slides
OWASP AppSec Seattle 2006
33

Banned APIs
_tcscpy, _mbscpy, StrCpy, StrCpyA,
StrCpyW, lstrcpy, lstrcpyA, lstrcpyW,
_tccpy, _mbccpy strcat, strcatA, strcatW, wcscat,
StrCatChainW, _tccat, _mbccat strncpy, wcsncpy, _tcsncpy, _mbsncpy,
_mbsnbcpy, StrCpyN, StrCpyNA,
StrCpyNW, StrNCpy, strcpynA, lstrcpynA, lstrcpynW strncat, wcsncat, _tcsncat, _mbsncat,
StrNCatW, lstrncat, lstrcatnA, lstrcatnW, lstrcatn
CharToOem, CharToOemA,
CharToOemW, OemToChar,
CharToOemBuffA, CharToOemBuffW alloca, _alloca sprintfW, sprintfA, wsprintf, wsprintfW, wsprintfA, sprintf, swprintf, _stprintf, wvnsprintf, wvnsprintfA, wvnsprintfW strtok, _tcstok, wcstok, _mbstok
_wmakepath, _splitpath, _tsplitpath,
_wsplitpath
_stscanf, snscanf, snwscanf, _sntscanf
_itoa, _itow, _i64toa, _i64tow,
_ultot, _ultow gets, _getts, _gettws
IsBadCodePtr, IsBadStringPtr
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”
OWASP AppSec Seattle 2006