Transcript Operating System Security
Chapter 12 Operating System Security
Operating System
each layer of code needs measures in place to provide appropriate security services
each layer is vulnerable to attack from below if the lower layers are not secured appropriately
Measures
the 2010 Australian Defense Signals Directorate (DSD) list the “Top 35 Mitigation Strategies”
over 70% of the targeted cyber intrusions investigated by DSD in 2009 could have been prevented
the top four measures for prevention are:
patch operating systems and applications using auto-update
patch third-party applications
restrict admin privileges to users who need them
white-list approved applications
Operating System Security
possible for a system to be compromised during the installation process before it can install the latest patches
building and deploying a system should be a planned process designed to counter this threat
process must:
assess risks and plan the system deployment
secure the underlying operating system and then the key applications
ensure any critical content is secured
ensure appropriate network protection mechanisms are used
ensure appropriate processes are used to maintain security
System Security Planning Process
the purpose of the system, the type of information stored, the applications and services provided, and their security requirements who will administer the system, and how they will manage the system (via local or remote access) any additional security measures required on the system, including the use of host firewalls, anti-virus or other malware protection mechanisms, and logging the categories of users of the system, the privileges they have, and the types of information they can access what access the system has to information stored on other hosts, such as file or database servers, and how this is managed how the users are authenticated how access to the information stored on the system is managed
Operating Systems Hardening
first critical step in securing a system is to secure the base operating system
basic steps
install and patch the operating system
harden and configure the operating system to adequately address the indentified security needs of the system
install and configure additional security controls, such as anti virus, host-based firewalls, and intrusion detection system (IDS)
test the security of the basic operating system to ensure that the steps taken adequately address its security needs
Initial Setup and Patching
system security begins with the installation of the operating system ideally new systems should be constructed on a protected network initial installation should install the minimum necessary for the desired system overall boot process must also be secured full installation and hardening process should occur before the system is deployed to its intended location the integrity and source of any additional device driver code must be carefully validated should stage and validate all patches on the test systems before deploying them in production critical that the system be kept up to date, with all critical security related patches installed
Remove Unnecessary Services, Applications, Protocols
if fewer software packages are available to run the risk is reduced system planning process should identify what is actually required for a given system
when performing the initial installation the supplied defaults should not be used
default configuration is set to maximize ease of use and functionality rather than security
if additional packages are needed later they can be installed when they are required
Configure Users, Groups, and Authentication
not all users with access to a system will have the same access to all data and resources on that system
elevated privileges should be restricted to only those users that require them, and then only when they are needed to perform a task
system planning process should consider:
categories of users on the system
privileges they have
types of information they can access
how and where they are defined and authenticated
default accounts included as part of the system installation should be secured
those that are not required should be either removed or disabled
policies that apply to authentication credentials configured
Configure Resource Controls Install Additional Security Controls
once the users and groups are defined, appropriate permissions can be set on data and resources many of the security hardening guides provide lists of recommended changes to the default access configuration
further security possible by installing and configuring additional security tools:
anti-virus software
host-based firewalls
IDS or IPS software
application white-listing
Test the System Security
final step in the process of initially securing the base operating system is security testing goal:
ensure the previous security configuration steps are correctly implemented
identify any possible vulnerabilities
checklists are included in security hardening guides
there are programs specifically designed to:
review a system to ensure that a system meets the basic security requirements
scan for known vulnerabilities and poor configuration practices
should be done following the initial hardening of the system
repeated periodically as part of the security maintenance process
Application Configuration
may include:
creating and specifying appropriate data storage areas for application
making appropriate changes to the application or service default configuration details
some applications or services may include:
default data
scripts
user accounts
of particular concern with remotely accessed services such as Web and file transfer services
risk from this form of attack is reduced by ensuring that most of the files can only be read, but not written, by the server
Encryption Technology
is a key enabling technology that may be used to secure data both in transit and when stored must be configured and appropriate cryptographic keys created, signed, and secured if secure network services are provided using TLS or IPsec suitable public and private keys must be generated for each of them if secure network services are provided using SSH, appropriate server and client keys must be created cryptographic file systems are another use of encryption
Security Maintenance
process of maintaining security is continuous
security maintenance includes:
monitoring and analyzing logging information
performing regular backups
recovering from security compromises
regularly testing system security
using appropriate software maintenance processes to patch and update all critical software, and to monitor and revise configuration as needed
automated analysis is preferred can only inform you about bad things that have already happened generates significant volumes of information and it is important that sufficient space is allocated for them
Logging
in the event of a system breach or failure, system administrators can more quickly identify what happened range of data acquired should be determined during the system planning stage information can be generated by the system, network and applications key is to ensure you capture the correct data and then appropriately monitor and analyze this data
Data Backup and Archive
performing regular backups of data is a critical control that assists with maintaining the integrity of the system and user data
•may be legal or
operational requirements for the retention of data backup
•the process of
making copies of data at regular intervals archive
•the process of retaining
copies of data over extended periods of time in order to meet legal and operational requirements to access past data needs and policy relating to backup and archive should be determined during the system planning stage
•kept online or offline •stored locally or transported to a
remote site
• trade-offs include ease of
implementation and cost versus greater security and robustness against different threats
Linux/Unix Security
patch management
keeping security patches up to date is a widely recognized and critical control for maintaining security
application and service configuration
most commonly implemented using separate text files for each application and service
generally located either in the /etc directory or in the installation tree for a specific application
individual user configurations that can override the system defaults are located in hidden “dot” files in each user’s home directory
most important changes needed to improve system security are to disable services and applications that are not required
Linux/Unix Security
users, groups, and permissions
access is specified as granting read, write, and execute permissions to each of owner, group, and others for each resource
guides recommend changing the access permissions for critical directories and files
local exploit
software vulnerability that can be exploited by an attacker to gain elevated privileges
remote exploit
software vulnerability in a network server that could be triggered by a remote attacker
Linux/Unix Security
remote access controls
• several host firewall programs
may be used
• most systems provide an
administrative utility to select which services will be permitted to access the system logging and log rotation
• should not assume that the
default setting is necessarily appropriate
Linux/Unix Security
chroot jail
restricts the server’s view of the file system to just a specified portion
uses chroot system call to confine a process by mapping the root of the filesystem to some other directory
file directories outside the chroot jail aren’t visible or reachable
main disadvantage is added complexity
Windows Security
patch management
• “Windows Update” and
“Windows Server Update Service” assist with regular maintenance and should be used
• third party applications
also provide automatic update support users administration and access controls
• systems implement
discretionary access controls resources
• Vista and later systems
include mandatory integrity controls
• objects are labeled as being of
low, medium, high, or system integrity level
• system ensures the subject’s
integrity is equal or higher than the object’s level
• implements a form of the Biba
Integrity model
Windows Security Users Administration and Access Controls
Windows systems also define privileges
• system wide and granted to user
accounts combination of share and NTFS permissions may be used to provide additional security and granularity when accessing files on a shared resource User Account Control (UAC)
• provided in Vista and later systems • assists with ensuring users with
administrative rights only use them when required, otherwise accesses the system as a normal user Low Privilege Service Accounts
• used for long-lived service
processes such as file, print, and DNS services
Windows Security application and service configuration
• much of the configuration information is
centralized in the Registry
• forms a database of keys and values that may
be queried and interpreted by applications
• registry keys can be directly modified
using the “Registry Editor”
• more useful for making bulk changes
Windows Security
other security controls
essential that anti-virus, anti-spyware, personal firewall, and other malware and attack detection and handling software packages are installed and configured
current generation Windows systems include basic firewall and malware countermeasure capabilities
important to ensure the set of products in use are compatible
Windows systems also support a range of cryptographic functions:
encrypting files and directories using the Encrypting File System (EFS)
full-disk encryption with AES using BitLocker
“Microsoft Baseline Security Analyzer”
free, easy to use tool that checks for compliance with Microsoft’s security recommendations
Virtualization
a technology that provides an abstraction of the resources used by some software which runs in a simulated environment called a virtual machine (VM)
benefits include better efficiency in the use of the physical system resources
provides support for multiple distinct operating systems and associated applications on one physical system
raises additional security concerns
Virtualization Alternatives
application virtualization full virtualization allows applications written for one environment to execute on some other operating system multiple full operating system instances execute in parallel virtual machine monitor (VMM) hypervisor coordinates access between each of the guests and the actual physical hardware resources
Native Virtualization Security Layers
Hosted Virtualization Security Layers
Virtualization Security Issues
security concerns include:
guest OS isolation
ensuring that programs executing within a guest OS may only access and use the resources allocated to it
guest OS monitoring by the hypervisor
which has privileged access to the programs and data in each guest OS
virtualized environment security
particularly image and snapshot management which attackers may attempt to view or modify
Hypervisor Security
should be
secured using a process similar to securing an operating system
installed in an isolated environment
configured so that it is updated automatically
monitored for any signs of compromise
accessed only by authorized administration
may support both local and remote administration so must be configured appropriately
remote administration access should be considered and secured in the design of any network firewall and IDS capability in use
Access to VM image and snapshots must be carefully controlled
Linux Security
Linux Security
Linux has evolved into one of the most popular and versatile operating systems
many features mean broad attack surface
can create highly secure Linux systems
will review:
Discretionary Access Controls
typical vulnerabilities and exploits in Linux
best practices for mitigating those threats
new improvements to Linux security model
Linux’s traditional security model is:
people or proceses with “root” privileges can do anything
other accounts can do much less
hence attacker’s want to get root privileges
can run robust, secure Linux systems
crux of problem is use of Discretionary Access Controls (DAC)
Linux Security Transactions
File System Security
in Linux everything as a file
e.g. memory, device-drivers, named pipes, and other system resources
hence why filesystem security is so important
I/O to devices is via a “special” file
e.g. /dev/cdrom
have other special files like named pipes
a conduit between processes / programs
Users and Groups
a user-account (user)
represents someone capable of using files
associated both with humans and processes
a group-account (group)
is a list of user-accounts
users have a main group
may also belong to other groups
users & groups are not files
Users and Groups
user's details are kept in /etc/password maestro:x:200:100:Maestro Edward Hizzersands:/home/maestro:/bin/bash
additional group details in /etc/group conductors:x:100: pianists:x:102:maestro,volodya
use useradd, usermod, userdel to alter
File Permissions
files have two owners: a user & a group
each with its own set of permissions
with a third set of permissions for other
permissions are to read/write/execute in order user/group/other, cf.
-rw-rw-r- 1 maestro user 35414 Mar 25 01:38 baton.txt
set using chmod command
Directory Permissions
read = list contents
write = create or delete files in directory
execute = use anything in or change working directory to this directory
e.g.
$ chmod g+rx extreme_casseroles $ ls -l extreme_casseroles drwxr-x--- 8 biff drummers 288 Mar 25 01:38 extreme_casseroles
Sticky Bit
originally used to lock file in memory
now used on directories to limit delete
if set must own file or dir to delete
other users cannot delete even if have write
set using chmod command with +t flag, e.g.
chmod +t extreme_casseroles
directory listing includes t or T flag drwxrwx--T 8 biff drummers 288 Mar 25 01:38 extreme_casseroles
only apply to specific directory not child dirs
SetUID and SetGID
setuid bit means program "runs as" owner
no matter who executes it
setgid bit means run as a member of the group which owns it
again regardless of who executes it
"run as" = "run with same privileges as”
are very dangerous if set on file owned by root or other privileged account or group
only used on executable files, not shell scripts
setuid has no effect on directories. setgid does and causes any file created in a directory to inherit the directory's group
useful if users belong to other groups and routinely create files to be shared with other members of those groups
instead of manually changing its group
Numeric File Permissions
Kernel vs User Space
Kernel space
refers to memory used by the Linux kernel and its loadable modules (e.g., device drivers)
User space
refers to memory used by all other processes
since kernel enforces Linux DAC and security critical to isolate kernel from user
so kernel space never swapped to disk
only root may load and unload kernel modules
setuid root Vulnerabilities
a setuid root program runs as root
no matter who executes it
used to provide unprivileged users with access to privileged resources
must be very carefully programmed
if can be exploited due to a software bug
may allow otherwise-unprivileged users to use it to wield unauthorized root privileges
distributions now minimise setuid-root programs
system attackers still scan for them!
Web Vulnerabilities
a very broad category of vulnerabilities
because of ubiquity of world wide web have big and visible attack surfaces
when written in scripting languages
not as prone to classic buffer overflows
can suffer from poor input-handling
few “enabled-by-default” web applications
but users install vulnerable web applications
or write custom web applications having easily identified and easily-exploited flaws
Rootkits
allow attacker to cover their tracks
if successfully installed before detection, all is very nearly lost
originally collections of hacked commands
hiding attacker’s files, directories, processes
now use loadable kernel modules
intercepting system calls in kernel-space
hiding attacker from standard commands
may be able to detect with chkrootkit
generally have to wipe and rebuild system
Linux Hardening - OS Installation
security begins with O/S installation
especially what software is run
since unused applications liable to be left in default, un hardened and un-patched state
generally should not run:
X Window system, RPC services, R-services, inetd, SMTP daemons, telnet etc
also have some initial system s/w configuration:
setting root password
creating a non-root user account
setting an overall system security level
enabling a simple host-based firewall policy
enabling SELinux
Patch Management
installed server applications must be:
configured securely
kept up to date with security patches
patching can never win “patch rat-race”
have tools to automatically download and install security updates
e.g. up2date, YaST, apt-get
note should not run automatic updates on change-controlled systems without testing
Network Access Controls
network a key attack vector to secure
TCP wrappers a key tool to check access
originally tcpd inetd wrapper daemon
before allowing connection to service checks
if requesting host explicitly in hosts.allow is ok
if requesting host explicitly in hosts.deny is blocked
if not in either is ok
checks on service, source IP, username
now often part of app using libwrappers
Network Access Controls
also have the very powerful netfilter Linux kernel native firewall mechanism
and iptables user-space front end
as useful on firewalls, servers, desktops
direct config tricky, steep learning curve
do have automated rule generators
typically for “personnal” firewall use will:
allow incoming requests to specified services
block all other inbound service requests
allow all outbound (locally-originating) requests
if need greater security, manually config
Antivirus Software
historically Linux not as vulnerable to viruses
more to lesser popularity than security
prompt patching was effective for worms
but viruses abuse users privileges
non-root users have less scope to exploit
but can still consume resources
growing Linux popularity mean exploits
hence antivirus software will more important
various commercial and free Linux A/V
User Management
guiding principles in user-account security:
need care setting file / directory permissions
use groups to differentiate between roles
use extreme care in granting / using root privs
commands: chmod, useradd/mod/del, groupadd/mod/del, passwd, chage
info in files /etc/passwd & /etc/group
manage user’s group memberships
set appropriate password ages
Root Delegation
have "root can to anything, users do little” issue
“su” command allows users to run as root
either root shell or single command
must supply root password
means likely too many people know this
SELinux RBAC can limit root authority, complex
“sudo” allows users to run as root
but only need their password, not root password
/etc/sudoers file specifies what commands allowed
or configure user/group perms to allow, tricky
Logging
effective logging a key resource
Linux logs using syslogd or Syslog-NG
receive log data from a variety of sources
sorts by facility (category) and severity
writes log messages to local/remote log files
Syslog-NG preferable because it has:
variety of log-data sources / destinations. much more flexible “rules engine” to configure
Log Management………
can log via TCP which can be encryptedbalance number of log files used
size of few to finding info in many
manage size of log files
must rotate log files and delete old copies. typically use logrotate utility run by cron
to manage both system and application logs
must also configure application logging
Running As Unprivileged User/Group
every process “runs as” some user
extremely important this user is not root
since any bug can compromise entire system
may need root privileges, e.g. bind port
have root parent perform privileged function
but main service from unprivileged child
user/group used should be dedicated
easier to identify source of log messages
Running in chroot Jail
chroot confines a process to a subset of /
maps a virtual “/” to some other directory
useful if have a daemon that should only access a portion of the file system, e.g. FTP
directories outside the chroot jail aren’t visible or reachable at all
contains effects of compromised daemon
complex to configure and troubleshoot
must mirror portions of system in chroot jail
Modularity
applications running as a single, large, multipurpose process can be:
more difficult to run as an unprivileged user
harder to locate / fix security bugs in source
harder to disable unnecessary functionality
hence modularity a highly prized feature
providing a much smaller attack surface
cf. postfix vs sendmail, Apache modules
Encryption
sending logins & passwords or application data over networks in clear text exposes them to network eavesdropping attacks
hence many network applications now support encryption to protect such data
often using OpenSSL library
may need own X.509 certificates to use
can generate/sign using openssl command
may use commercial/own/free CA
Logging
applications can usually be configured to log to any level of detail (debug to none)
need appropriate setting
must decide if use dedicated file or system logging facility (e.g. syslog)
central facility useful for consistent use
must ensure any log files are rotated
Mandatory Access Controls
Linux uses a DAC security model
but Mandatory Access Controls (MAC) impose a global security policy on all users
users may not set controls weaker than policy
normal admin done with accounts without authority to change the global security policy
but MAC systems have been hard to manage
Novell’s SuSE Linux has AppArmor
RedHat Enterprise Linux has SELinux
pure SELinux for high-sensitivity, high-security
Windows Security
Windows is the world’s most popular O/S
advantage is that security enhancements can protect millions of nontechnical users
challenge is that vulnerabilities in Windows can also affect millions of users
will review overall security architecture of Windows
then security defenses built into Windows
Windows Security Architecture
Security Reference Monitor (SRM)
a kernel-mode component that performs access checks, generates audit log entries, and manipulates user rights (privileges)
Local Security Authority (LSA)
responsible for enforcing local security policy
Security Account Manager (SAM)
a database that stores user accounts and local users and groups security information
local logins perform lookup against SAM DB
passwords are stored using MD4
Windows Security Architecture
Active Directory (AD)
Microsoft ’s LDAP directory
all Windows clients can use AD to perform security operations including account logon
authenticate using AD when the user logs on using a domain rather than local account user ’s credential information is sent securely across the network to be verified by AD
WinLogon (local) and NetLogon (net) handle login requests
Local vs Domain Accounts
a networked Windows computer can be:
domain joined
can login with either domain or local accounts
if local may not access domain resources
centrally managed and much more secure
in a workgroup
a collection of computers connected together
only local accounts in SAM can be used
no infrastructure to support AD domain
Domain Login Example
domain admin adds user’s account info (name, account, password, groups, privileges)
account is represented by a Security ID (SID)
unique to each account within a domain
of form: S-1–5–21-AAA-BBB-CCC-RRR
Breakdown: S means SID; 1 is version number; 5 is identifier authority (here is SECURITY_NT_AUTHORITY); 21 means “not unique”, although always unique within a domain; AAA-BBB CCC is unique number representing domain; and RRR is a relative id (increments by 1 for each new account)
Domain Login Example (cont.)
username in one of two forms:
SAM format: DOMAIN\Username
User Principal Name (UPN): [email protected]
login using username & password or smartcard
assuming login is correct, token is generated and assigned to the user
contains user’s SID, group membership info, and privileges
assigned to every process run by user, and used for access checks
Windows Privileges
are systemwide permissions assigned to user accounts – over 45 total
e.g. backup computer, or change system time
some are deemed “dangerous” such as:
act as part of operating system privilege
debug programs privilege
backup files and directories privilege
others are deemed “benign” such as
bypass traverse checking privilege
Access Control Lists
two forms of access control list (ACL):
Discretionary ACL (DACL)
grants or denies access to protected resources such as files, shared memory, named pipes etc
System ACL (ACL)
used for auditing and in Windows Vista to enforce mandatory integrity policy
objects needing protection are assigned a DACL (and possible SACL) that includes
SID of the object owner. list of access control entries (ACEs)
each ACE includes a SID & access mask
access mask could include ability to:
read, write, create, delete, modify, etc
access masks are object-type specific
e.g. service abilities are create, enumerate
Security Descriptor (SD)
data structure with object owner, DACL, & SACL
e.g.
Owner: CORP\Blake ACE[0]: Allow CORP\Paige Full Control ACE[1]: Allow Administrators Full Control ACE[2]: Allow CORP\Cheryl Read, Write and Delete
have no implied access, if there is no ACE for requesting user, then access is denied
applications must request correct type of access
if just request “all access” when need less (e.g. read) some user’s who should have access will be denied
More SD’s & Access Checks
each ACE in the DACL determines access
an ACE can be an allow or a deny ACE
Windows evaluates each ACE in the ACL until access is granted or explicitly denied
so deny ACEs come before allow ACEs
default if set using GUI
explicitly order if create programmatically
when user attempts to access a protected object, the O/S performs an access check
comparing user/group info with ACE’s in ACL
Application access
Note that when an application requests access, it must also request an access level.
Initially (before XP), most applications just requested “all access”, which is only given to owner or admin accounts.
This is the reason so many applications failed on Windows XP unless they ran at admin level – essentially, poor coding.
Interacting with SDs
Powershell to get an object’s SD:
get-acl c:\folder\file.txt | format-list
use set-acl to set DACL or SACL
Can also use Security Descriptor Definition Language (SDDL):
Example function: ConvertStringSecurityDescriptorToSecurityDescriptor()
Impersonation
process can have multiple threads
common for both clients and servers
impersonation allows a server to serve a user, using their access privileges
e.g. ImpersonateNamedPipeClient function sets user’s token on the current thread
then access checks for that thread are performed against this token not server’s
with user’s access rights
Mandatory Access Control
have Integrity Control in Windows Vista (and later) that limits operations changing an object’s state
objects and principals are labeled (using SID):
Low integrity (S-1-16-4096)
Medium integrity (S-1-16-8192)
High integrity (S-1-16-12288)
System integrity (S-1-16-16384)
when write operation occurs first check subject’s integrity level dominates object’s integrity level
much of O/S marked medium or higher integrity
Vista User Account
Windows Vulnerabilities
Windows, like all O/S’s, has security bugs
and bugs have been exploited by attackers to compromise customer operating systems
Microsoft now uses process improvement called the Security Development Lifecycle
net effect approx 50% reduction in bugs
Windows Vista used SDL start to finish
IIS v6 (in Windows Server 2003) had only 3 vulnerabilities in 4 years, none critical
Security Development Lifecycle (SDL)
Requirements:
Mandatory security education
Security design requirements
Threat modeling
Attack surface analysis and reduction
Secure coding
Secure testing
Security push
Final security review
Security response
Patch Management
At first, patches were released at all times. Now, they release on the second Tuesday of each month (Patch Tuesday).
More recently, they even announce the expected load the Thursday before, which has been popular with sys admins.
Windows System Hardening
process of shoring up defenses, reducing exposed functionality, disabling features known as attack surface reduction
use 80/20 rule on features
not always achievable
e.g. requiring RPC authentication in XP SP2
e.g. strip mobile code support on servers
1.
servers easier to harden: are used for very specific and controlled purposes 2.
server users are administrators with (theoretically) better computer configuration skills than typical users
Windows Security Defenses
Have 4 broad categories of security defenses:
account defenses
network defenses
buffer overrun defenses.
browser defenses
Account Defenses
user accounts can have privileged SIDs
least privilege dictates that users operate with just enough privilege for tasks
Windows XP users in local Administrators
for application compatibility reasons
can use “Secondary Logon” to run applications
also restricted tokens reduce per-thread privilege
Windows Vista onwards reverses default with UAC
users prompted to perform a privileged operation
unless admin on Server
Low Privilege Service Accounts
Windows services are long-lived processes started after booting
many ran with elevated privileges
but many do not need elevated requirements
Windows XP added Local Service and Network service accounts
allow a service local or network access
otherwise operate at much lower privilege level
Windows XP SP2 split RPC service (RPCSS) in two (RPCSS and DCOM Server Process)
example of least privilege in action, see also IIS6
direct result of Blastr worm
Stripping Privileges
another defense is to strip privileges from an account soon after an application starts
e.g. Index server process runs as system to access all disk volumes
but then sheds any unneeded privileges as soon as possible
using AdjustTokenPrivileges
Windows Vista can define privileges required by a service
using ChangeServiceConfig2
Network Defenses
have IPSec and IPv6 with authenticated network packets enabled by default in Windows Vista
IPv4 also enabled by default, expect less use
E.g. Windows Xbox live network ----- ipsec
have built-in software firewall
block inbound connections on specific ports
Vista can allow local net access only
optionally block outbound connections
default was off (XP) but now default on
Buffer Overrun Defenses
many compromises exploit buffer overruns
Windows Vista has “Stack-Based Buffer Overrun Detection (/GS)” default enabled
source code compiled with special /GS option
does not affect every function; only those with at least 4 bytes of contiguous stack data and that takes a pointer or buffer as an argument
defends against “classic stack smash”
Windows Stack and /GS flag
Buffer Overrun Defenses
No eXecuteNamed (NX) / Data Execution Prevention (DEP) / eXecution Disable (XD)
prevent code executing in data segments
as commonly used by buffer overrun exploits
applications linked with /NXCOMPAT option
Stack Randomization (Vista only)
randomizes thread stack base addresses
Heap-based buffer overrun defenses:
add and check random value on each heap block
heap integrity checking
heap randomization (Vista only)
Other Defenses
Image Randomization
O/S boots in one of 256 configurations
makes O/S less predictable for attackers
Service Restart Policy
services can be configured to restart if fail
great for reliability but lousy for security
Vista sets some critical services so can only restart twice, then manual restart needed
gives attacker only two attempts
Encrypted File System…..EFS, Bitlocker
Browser Defenses
web browser is a key point of attack
via script code, graphics, helper objects
Microsoft added many defenses to IE7 onwards
ActiveX opt-in
unloads ActiveX controls by default
when any then first run prompts user to confirm
protected mode
IE runs at low integrity level (see earlier)
so more difficult for malware to manipulate O/S