Transcript OWASPAppSec2006Seattle_SecurityEngineeringInVista

How the Security Development
Lifecycle (SDL) Improved
Windows Vista
OWASP
AppSec
Seattle
Oct 2006
Michael Howard
[email protected]
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?
[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
Education
“Quality
Gates”
Central
analysis
Threat
analysis
External
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?
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_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’));
}
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
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
Apple Mac OS X
OpenBSD 3.x
Heap
RedHat Enterprise Linux 4
Stack
Windows XP SP2
Windows Vista
Images
Section Reordering
EXE Randomization
DLL Randomization
Frame Protection
Exception Protection
Local Variable Protection
Randomization
Non-Executable
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
[email protected]
http://blogs.msdn.com/michael_howard
OWASP AppSec Seattle 2006
32
Backup Slides
OWASP AppSec Seattle 2006
33
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
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