How the Security

Development Lifecycle
(SDL) Improved
Windows Vista

Michael Howard
[email protected]
Senior Security Program Manager
Microsoft Corp.
OWAS
P
AppSe Copyright © 2006 - The OWASP Foundation

c
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
Seattl http://creativecommons.org/licenses/by-sa/2.5/

e The OWASP
Oct 2006 http://www.owasp.org/ 1
Foundation
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!)

Prescriptive
Guidance

Mandatory “Quality Central Threat External

Education Gates” analysis analysis Review

Software Security Science

OWASP AppSec Seattle 2006 3

Why All This Security Work?

The threats have changed,

customers are demanding
increased security and
reduced support costs.
There is no one silver
bullet.

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?

OWAS
P
AppSe Copyright © 2006 - The OWASP Foundation

c
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
Seattl http://creativecommons.org/licenses/by-sa/2.5/

e The OWASP
Oct 2006 http://www.owasp.org/ 7
Foundation
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
These two arguments are related,
void FillString( but the compiler does not know!
TCHAR* buf,
size_t cchBuf,
TCHAR ch) {

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

 Element count.
SAL at Work Other example includes
bcount, byte count.

__out_ecount(cchBuf)

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’));
}

ning C6386: Buffer overrun: accessing 'argument 1',

writable size is ‘200*2' bytes, but '420' bytes might be written: Lines: 33

ning C6387: 'argument 1' might be '0': this does not adhere to
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]; char buf[32];
strcpy(buf,src); 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

Tools DO NOT MAKE

SOFTWARE SECURE! They
help scale the process and they
help enforce policy

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

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
[email protected]
http://blogs.msdn.com/michael_how

OWASP AppSec Seattle 2006 32

Backup Slides

OWASP AppSec Seattle 2006 33

Banned APIs

strcpy, strcpyA, strcpyW, wcscpy, wnsprintf, wnsprintfA, wnsprintfW,

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

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