Post by Leo
I just wrote on my blog: 10 (real) reasons to use ubuntu linux. I
decided to write that to stand out points where linux takes advantage
on windows in real life.
I would like you guys to give it a read, comment, and eventually point
Here you moron, because you don't know jack about Vista.
I don't see post about malware issues posted by posters anymore in the
Address Space Load Randomization
Despite measures like Data Execution Prevention and enhanced compiler
error checking, malware authors continue to find buffer overflow
vulnerabilities that allow them to infect network-facing processes like
Internet Explorer®, Windows services, and third-party applications to
gain a foothold on a system. Once they have managed to infect a process,
however, they must use Windows APIs to accomplish their ultimate goal of
reading user data or establishing a permanent presence by modifying user
or system configuration settings.
Connecting an application with API entry points exported by DLLs is
something usually handled by the operating system loader, but these
types of malware infection don't get the benefit of the loader's
services. This hasn't posed a problem for malware on previous versions
of Windows because for any given Windows release, system executable
images and DLLs always load at the same location, allowing malware to
assume that APIs reside at fixed addresses.
The Windows Vista Address Space Load Randomization (ASLR) feature makes
it impossible for malware to know where APIs are located by loading
system DLLs and executables at a different location every time the
system boots. Early in the boot process, the Memory Manager picks a
random DLL image-load bias from one of 256 64KB-aligned addresses in the
16MB region at the top of the user-mode address space. As DLLs that have
the new dynamic-relocation flag in their image header load into a
process, the Memory Manager packs them into memory starting at the
image-load bias address and working its way down.
Executables that have the flag set get a similar treatment, loading at a
random 64KB-aligned point within 16MB of the base load address stored in
their image header. Further, if a given DLL or executable loads again
after being unloaded by all the processes using it, the Memory Manager
reselects a random location at which to load it. Figure 7 shows an
example address-space layout for a 32-bit Windows Vista system,
including the areas from which ASLR picks the image-load bias and
executable load address.
To help prevent malicious software from silently installing and causing
computer-wide infection, Microsoft developed the UAC feature. Unlike
previous versions of Windows, when an administrator logs on to a
computer running Windows Vista, the user’s full administrator access
token is split into two access tokens: a full administrator access token
and a standard user access token. During the logon process,
authorization and access control components that identify an
administrator are removed, resulting in a standard user access token.
The standard user access token is then used to start the desktop, the
Explorer.exe process. Because all applications inherit their access
control data from the initial launch of the desktop, they all run as a
standard user as well.
After an administrator logs on, the full administrator access token is
not invoked until the user attempts to perform an administrative task
The admin approval mode in Windows Vista illustrates how the security
features of the operating system have evolved beyond Windows XP. The
administrator approval mode is active by default for all the users that
are members of the local administrator group.
With the introduction of the User Account Control in Windows Vista,
Microsoft has labored to deliver a balance between security via
privilege limitations and functionality. In Windows XP, a standard user
found that the actions they were able to perform were confined to the
point of lost functionality.
This is also one of the reasons why in Windows XP, standard user
accounts are less than popular. In this aspect, the security delivered
by limiting the administrator privileges was traded off for complete
functionality. In Windows Vista, Microsoft has integrated a common
denominator in the UAC settings: the admin approval mode.
"In this mode (which is on by default for all members of the local
administrators group), every user with administrator privileges runs
normally as a standard user; but when an application or the system needs
to do something that requires administrator permissions, the user is
prompted to approve the task explicitly. Unlike the "super user on"
function from UNIX that leaves the process elevated until the user
explicitly turns it off, admin approval mode enables administrator
privileges for just the task that was approved, automatically returning
the user to standard user when the task is completed," explained Jim
Allchin, Microsoft Co-President, Platform and Services Division.
Allchin went on to explain that the functionality is simply a
convenience feature designed for administrators. The admin approval mode
does not create a security boundary between processes. In this context,
in the absence of process isolation, interference is possible.
"If an administrator performs multiple tasks on the same desktop, then
malware may potentially be able to inject or interfere with an elevated
process from a non-elevated process. Thus, the most secure configuration
for Windows Vista is to run processes in two separate accounts, with
only administrator tasks performed using an administrator account and
all other tasks performed under the standard user account," added Allchin.
To accommodate existing software for Windows that writes to protected
file directories, Microsoft provides a backward compatibility technology
known as Virtualization. While virtualization enables older applications
to run without programmer intervention, it does not guarantee correct
behaviour, and many applications will need to be updated to comply with
UAC restrictions. Virtualization is often referred to as data
redirection because it functions by funnelling attempted access to
protected locations to new locations stored under user profiles. For
example, if a legacy application attempts to write to the Program Files
directory, UAC silently redirects that operation to an unprotected
When an application installer attempts to write a file called Entry.txt
in C:\Program Files, it is silently redirected to a Virtual Store
directory located inside the current user's account. To the application,
things proceed as normal, and it has no idea that it is being
redirected. To the user, the application, too, still appears to be
located at the old, expected location. But because the application is
not access system-wide file locations, it cannot be used to harm the
system. And on multi-user systems, each user will have isolated, local
copies of redirected files. When this action is being invoked by a admin
user, the file entry is done in Program Files itself. This is depicted
in the figures below.
Applications should not attempt to modify WRP-protected resources
because these are used by Windows and other applications. If an
application attempts to modify a WRP-protected resource, it can have the
Application installers that attempt to replace, modify, or delete
critical Windows files or registry keys may fail to install the
application and will receive an error message stating that access to the
resource was denied.
Applications that attempt to add or remove sub-keys or change the values
of protected registry keys may fail and will receive an error message
stating that access to the resource was denied.
Applications that rely on writing any information into protected
registry keys, folders, or files may fail.
Permission for full access to modify WRP-protected resources is
restricted to TrustedInstaller. WRP-protected resources can be changed
only using the Supported Resource Replacement Mechanisms with the
Windows Modules Installer service.
WRP protects files with the following extensions that are installed by
Windows Server 2008 or Windows Vista: .dll, .exe, .ocx, and .sys.
WRP protects critical files that are installed by Windows Server 2008 or
Windows Vista with the following extensions: .acm, .ade, .adp, .app,
.asa, .asp, .aspx, .ax, .bas, .bat, .bin, .cer, .chm, .clb, .cmd, .cnt,
.cnv, .com, .cpl, .cpx, .crt, .csh, .dll, .drv, .dtd, .exe, .fxp, .grp,
.h1s, .hlp, .hta, .ime, .inf, .ins, .isp, .its, .js, .jse, .ksh, .lnk,
.mad, .maf, .mag, .mam, .man, .maq, .mar, .mas, .mat, .mau, .mav, .maw,
.mda, .mdb, .mde, .mdt, .mdw, .mdz, .msc, .msi, .msp, .mst, .mui, .nls,
.ocx, .ops, .pal, .pcd, .pif, .prf, .prg, .pst, .reg, .scf, .scr, .sct,
.shb, .shs, .sys, .tlb, .tsp, .url, .vb, .vbe, .vbs, .vsmacros, .vss,
.vst, .vsw, .ws, .wsc, .wsf, .wsh, .xsd, and .xsl.
WRP protects critical folders. A folder containing only WRP-protected
files may be locked so that only the Windows trusted installer is able
to create files or subfolders in the folder. A folder may be partially
locked to enable Administrators to create files and subfolders in the
User Account Control (UAC) is, arguably, one of the most controversial
features in Windows Vista. Why did Microsoft add all those popups to
Windows? Does it actually improve security? Doesn’t everyone just click
“continue”? Has anyone in Redmond heard the feedback on users and
reviewers? Has anyone seen a tv commercial about this feature?
In the course of working on Windows 7 we have taken a hard look at UAC –
examining customer feedback, volumes of data, the software ecosystem,
and Windows itself. Let’s start by looking at why UAC came to be and our
approach in Vista.
And finally, last week's attack report, but hey, nothing is bullet proof.