ISBN: 0735623937
Autori: Michael Howard, David LeBlanc
Editore: Microsoft Press
Lingua: English
Anno: 2007
Pagine: 196 + XXII
Allegati: Nessuno

Whilst previous editions of classic Writing Secure Code presented security fundamentals along with design and coding best practices, and they were a lecture suggested for any and each developer (even if not primarily concerned with Microsoft technologies development), this book is very code-heavy and specially targeted to developers building software for Windows Vista who want and take advantages of unnumbered improvements in platform, even if the text presents some design considerations, so designers and architects will get some benefit.

All this said, this agile volume (two hundred pages about) has to be considered an adjunct to Writing Secure Code, and due it assumes you have some knowledge of Windows authentication and authorization along with way objects are protected in Windows, probably Windows Internals, Fourth Edition by Russinovich and Solomon is also a suggested previous reading.

Whilst coding practices are the most, if not only, of the book, who would think Windows Vista improvements are just the product of technology evolution would get wrong. In five years spent between XP and Vista release not only technical knowledge grew up; attack landscape moved from romantic rebels or experienced hackers aiming and improving their knowledge of system internals to well-organized criminal organization, and where the computer evolution is often a persons vs. computers field; security is a very apart world where field begins a persons vs. persons fighting. Persons aren't entirely related with technology, they require a process. Since 2001, year of Windows XP release, the main event in Microsoft security was born: growth and company-wide evolution of Trustworthy Computing and the enourmous effort of Security Development Lifecycle (SDL) development process; Windows Vista is, first of all, the main goal and demonstration of SDL effectiveness.

Along with this new book, a companion Website travels, with all code samples; they were created using Visual Studio Team System Service Pack 1 and the huge Windows Vista SDK, and detailed changes are required to compile environment for C/C++ code, starting including the magic line #define _WIN32_WINNT 0x0600 related to Vista major version (precisely 6.0) in any header file, better in stdafx.h. On the other hand, as a matter of fact C# code requires no change to development environment, and a definitive homage to its portability.

First three chapters are an obliged lecture since they explain bases of all Vista security improvements, although other focus on more specialized topics, and the last one is a miscellaneous chapter. The first chapter focuses on Code Quality goals aimed at for Vista release, with special attention for security ones of course. Main effort in this direction aimed to remove any banned API and cryptography from the Vista codebase (you can find a list in cited Security Development Lifecycle book), and adding Standard Annotation Language (SAL) annotations to C functions and C++ methods, namely every and each function that read from or write to a buffer. SAL is, fundamentally, a declarative paradigm to define proper use of buffers, and for Windows Vista development was used the declspec syntax, whilst Visual Studio 2005 supports attribute syntax too. Chapter explains in details a lot of SAL macros, but essentially you can find the same list on cited post on Dr. Howard's blog.

In addition to using SAL, proper use of Hungarian notation around string buffers helped prevent problems. Other described improvements cover use of static code analysis with PREfast (embedded in Visual Studio 2005 through the /analyze compile switch), FxCop and Application Verifier; other than using GS compiler option and SafeSEH (specific for structured exception handlers bugs), DynamicBase and NXCompat (especially related to Data Execution Prevention) linking switch for all unmanaged C/C++ code. MSDN furnishes a complete list of C/C++ warnings.

New code had to pass the quality gate before it could be accepted into Windows Vista source code tree, and this became an obliged step thanks to VSTS check-in policies. In effect, many of quality requirements for Vista code go above and beyond the SDL requirements. First chapter is focused on code aspects and is not concerned on such a fundamental topic as threat modeling, for which quoted SDL book is an invaluable reference. As any other chapter, first one ends with a paragraph Call to Action listing procedures developers will have and follow to take advantage of new features available in Vista, and with references.

The new features of User Account Control (UAC) (look in particular to this overview), along with changes to security tokens and new integrity levels in Vista, are the argument of second chapter. Discussion starts from beginning, explaining Windows security tokens, investigating their structure from output of whoami /fo list /all command, and explaining how their structure has been changed to accommodate requirements of now familiar Run as Administrator, using linked token and have more than a token for user (differently from Windows XP), and switching between tokens when administrative privileges are required. Included code, also available on companion Website, explains how to determine token content, and how to prompt for credential or consent to elevate privileges (both in C++, and in scripting, PowerShell or managed .NET code); creation of an XML application manifest to cause Vista display elevation dialog is also explained.

Sometime you don't need a whole process and run in elevated mode, but just a single component of it or even a single dialog; in such cases, you can use a new Vista features, the COM Elevation Moniker, and authors show us a simple example in SAL-annotated C++. Finally, a post of Christophe Wille is referenced to show how to start elevated managed code. Next argument in chapter is virtualization: Vista ability and automatically map access attempt to forbidden file system or registry locations to a safe, virtualized structure under %userprofile% subfolder. This capability has quite a number of limitations (it isn't available for 64-bit or administrator processes, for services, and doesn't allow impersonation), can't be used to acquire logo-certification for Windows Vista, and Microsoft proposes and eliminates in future, so it can be intended just as a bridge to assist migration and a very transitory measure. Chapter explains how it hacks, but also how to disable it, both in declarative and programming mode. At time, developers would especially take care and use just UAC-friendly storage locations for data: %appdata% for roaming users data, %localappdata% for user data and %programdata% for machine data.

Important protection mechanism of Integrity, new to Vista, is then explained. Fundamentally speaking, any protected object is labeled with an integrity level in Vista, and a process of a lower integrity level can't write to an object of an higher integrity level; a thumb rule mnemonically known as write-down, no write-up. It’s simply to understand than, since Integrity applies to write but not to read permission, speaking in STRIDE terms it can nothing against information disclosure, but it prevents tampering. Four level are provided by default (low, medium, high and system integrity) whit SID nomenclature as usual, and it's possible, even if discouraged, to create your own levels. As ever, examples in C++ are provided, and a tool on companion Website, SetMIC, allows and starts a process at an equal or lower integrity level than the user: as an elementar precaution misure, an account can't create a process at an higher integrity level than its own. Setting integrity labels on objects are performed using Security Descriptor Definition Language (SDDL) familiar to Microsoft C++ developers, and the icacls.execommand-line tool is available for rough manipulation (it recently has been added to Windows Server 2003 SP2).

Finally, a simplified model of Internet Explorer 7 Protected Mode, further explained in sixth chapter, is presented. Authors recognize debts of this model towards Biba one (which in turn was thought to superceed limitations in classic Bell-Lapadula model), but they agree it has to be highly simplified to fit highly interactive, general-purpose environment in which Windows Vista is used. Chapters end enlisting use of Application Compatibility Tools to migrate pre-Vista applications, of Authenticode to digitally sign your code, and list new privileges in Vista, object of further clarification in fifth chapter.

Third chapter focuses on defenses against buffer overruns, an argument already mentioned in first chapter. NX, /GS and SafeSEH switches are further investigated, along with useful techniques such as Address Space Layout Randomization (ASLR) and stack randomization. ASLR involves randomizing where system libraries are loaded, all of the starting points of the stack, and the starting points of the heaps; in a word, image, stack and heap of a running program are randomized. Code examples usually are provided, along with limitations of this technique: it is ineffective against local attacks; attacker can still be able and determine memory locations if application has a format string or an information disclosure vulnerability, or if the network service restarts itself on failure; to reduce virtual address space fragmentation, a library is only relocated across 256 different possible load addresses. Care has been token, on the other hand, to prevent performance losses and compatibility issues, as it was experimentally verified enabling ASLR on Office 2007 codebase. The chapter is very code-heavy and targeted to guru C++ developers.

Fourth chapter aims at networked applications developers. Network improvements in Vista have been true huge, and chapter doesn't focus solely on security, but also need and explain most of news, starting with IPv6 native support. In particular, Teredo transitional technology to allow IPv6 applications to work while IPv4 networks are examined. Most notably, Teredo offers NAT-traversal through UDP, following specifications of RFC 3489. Also, Vista offers an useful native API, Network List Manager, allowing an application to figure out whether the computer is connected to a network, and kind of network connections too. Network List Manager is an heritage of Network Location Awareness and IP Helper API; its main interface, INetworkListManager, is shortly introduced too, without any example.

New to Windows Vista is also an RSS platform API, which has any security feature embedded, such as sanitizing feed content and stripping out script prior to storing the content. It is accessed through two COM interfaces, a vtable version named IXFeedsManager and a late-bound IDispatch-derived interface, IFeedsManager, both explained in MSDN RSS documentation. Chapter shows a simple example using vtable version to enumerate feeds stored on local machine. More specific to security topic are new Winsock Secure Socket Extensions, allowing to require IPSec on a runtime socket from an application. Authors of course dedicate notably more pages than previous topics to this one, explaining details of main functions WSASetSocketSecurity and WSAIoctl and related WSASetSocketPeerTargetName (which allows the client to specify the Service Principal Names (SPN) of the server and application they want to connect to) and WSAImpersonateSocketPeer.

Last chapter topic is improvements in embedded firewall, also known as Windows Firewall with Advanced Security. Vista firewall still doesn't allow and perform same as a fully featured, enterprise-class firewall, but main limitations are impossibility and specify a ports range and to take in consideration bi-directional nature of some protocol such as TCP; on the other hand, it easily allows to apply rules only to wireless interfaces, not so easy a feature to realize from scratch. Many limitations can be overcame writing filters for the Windows Filtering Platform. Fundamentally new versions exposes two new interfaces, INetFwRule (while I’m writing this review, it is undocumented in MSDN, and you can find references just in Platform SDK and in book, of course) and INetFwPolicy2, and Authors dwell explaining all rule attributes, and showing how to work with rules and rule groups, with a special box explaining how to set group and interface properties, a little tricky activity going to be fixed in Vista Service Pack 1. P2P platform API, for merely reason of space, is just pointed out in the previous paragraph.

Who writes services should read fifth chapter. First paragraphs are a Russinovich-style introduction to service entry points interactions with Service Control Manager (SCM), use of service account (the most dangerous local system, local service and network service) and setting ACLs for specific service resource with service SIDs and ChangeServiceConfig2 function. New information level SERVICE_REQUIRED_PRIVILEGES_INFO in ChangeServiceConfig2 is also useful to specify privileges the service needs, and chapter resumes privileges in Windows platform, distinguishing dangerous high-level from benign privileges: last ones can be difficult used to compromise a system, but should equally be used sparingly. After, Windows firewalling API from fourth chapter is token up again with special attention to network access control, and chapter ends showing ways to communicate with desktop. One of greater enhancements of Vista, as already stated, has been the separated consoles for user and services; this improvements needs attention on safe ways and perform communication between service and console user. Quite a number of ways are available, none of one-size-fit-all kind; choice depends on features to accomplish and performance constraints. Shared memory is a true performing method, but it poses also unusual problems in synchronizing access, and such an approach is discouraged for non-experienced developers.

Named pipes have also very good performances and allow synchronization, but despite of new APIs available to avoid denial of service attacks, they're not the ideal mechanism for network communications. Regarding to new APIs, check GetNamedPipedClientComputerName and the whole new GetNamedPiped* family in pipe functions; we have two twin sets, for client and server, allowing and retrieving respectively name, process and session identifier. Sockets are always best choice for hostile environments, but they lack ability and easily authenticate or impersonate clients; these feature, along with simplicity of coding, can be recovered using COM wrapper, at cost of more overhead, and always taking in charge specific chapter about in Writing Secure Code. A final paragraph describes lessons learned from authors developing services on Vista, from GetModuleFileNameEx changes to necessity and install/remove services from Visual Studio running as an administrator. A MSDN page and a Word document from Microsoft resume all changes to services development in Vista; you should consider also information from Kernel enhancements for Windows Server Longhorn talk.

Web and browser applications developers will learn new security features of Internet Explorer 7 in sixth chapter, with special consideration for integrity levels introduced in second chapter. A large amount of fourth and fifth chapters, in effect, is not specific to Windows Vista, but available also on previous versions; by this chapter, pure Vista-related topics begin: major Internet Explorer defenses are explained, with security features that developers can take advantage of, and a one-page section explaining minor changes that may pose issues with legacy applications. New Internet Explorer 7 defenses comprise ActiveX opt-in, Protected Mode, and Data Execution Prevention. First of all, users now will have and explicitly opt to use an ActiveX control, the first time it is referenced. Anyway, it will always be possible to add a control in a pre-approved list not prompting user, hosted in registry key HKLM | Software | Microsoft | Windows | CurrentVersion | Ext | PreApproved. Since this key is under elevation-protected Hardware Key Local Machine branch, this will protect user from silently installation of malicious ActiveX. This kind of protection is orthogonal to kill-bitting already available for Windows XP and Server 2003.

Protected Mode is a feature available only for Windows Vista, since it takes advantage of new integrity levels model; speaking as Biba integrity model terms, since a browser is always a boundary towards a zone whose content can never be trusted, the browser process runs at low integrity, although majority of Windows Vista objects are labelled at medium or higher integrity. A whole set of new functions is required when running in Protected Mode to help extensibility components go correctly; to use them, developer must include iepmapi.h and link with iepmapi.lib. Book shows use of these functions to access and set registry keys, and recommend using Application Compatibility Toolkit 5.0 to debut Protected Mode issues in legacy applications; by the way, I suggest you to consult ACT 5.0 evalutation guide. Elevation process described in second chapter makes evident how Protected Mode is disabled if Internet Explorer is started by selecting Run as administrator; moreover, by default, sites in the Trusted Sites zone do not have Protected Mode enabled.

About Data Execution Prevention, already spoken about in third chapter, it's enabled for most of Windows Vista system processes; compatibility checks are performed through Internet Explorer Compatibility Test Tool, also included in ACT 5.0. A known incompatibility is that applications using older versions of Active Template Library (ATL) will fail and run correctly when DEP is enabled; developers will use ATL 8.0 or higher, enforcing this with assert(AtlGetVersion(NULL) >= 0X0800);. On the good news front, Adobe Flash Player 9.0 and Adobe Acrobat Reader 8.0 run correctly in Internet Explorer when DEP is enabled. You can bypass DEP marking virtual memory as readable and executable with VirtualProtect function; there's also a version, VirtualProtectEx, which takes an additional argument to change virtual address space protection of a given arbitrary process for whom you have PROCESS_VM_OPERATION process access right, instead of the calling process. Anyway, DEP is enabled by default for 64-bit Internet Explorer versions, is planned and be enabled by default in future 32-bit versions, so counting on these function is not so wise.

Against canonicalization issues, a new unified URL parser has been included exposed by IUri Interface, quite aggressive in rejecting URIs not RFC 3986-compliant. A simple example is shown, mentioning also a new COM interface, IInternetSecurityManagerEx2, accepts IUri objects and should be used instead of IInternetSecurityManagerEx and IInternetSecurityManager; a list of deprecated URL parsing functions is also provided. Chapter also recommends always to use SiteLock, regardless of version 7.0 of Internet Explorer, and Fiddler to manipulate HTTP headers; developers will have to pay attention: clipboard access using window.clipboardData is now disabled without user consent; embedding script into an URL attribute works differently in Internet Explorer 7; and, most important, Private Communication Technology (PCT) and SSL2 have been disabled, in favour of AES.

Seventh chapter is devoted to cryptographic improvements in Cryptography Next Generation (CNG) API. This new API offers unified kernel and user mode support, an easier way to configure cryptography (referred also as crypto-agility), new cipher suites (notably NSA Suite B) and improved auditing. Vista supports CAPI 1.0 and CAPI 2.0 together with .NET cryptography, but CAPI 1.0 will eventually be phased out. Note that CNG has two distinct sets of function names, NCrypt* and BCrypt* functions; the latter are low-level cryptographic primitives running in-process with your applications and, most notably, keys are not stored, they are ephemeral. Note also, you should include bcrypt.h and link your code with bcrypt.dll. On the crypto-agility front, cryptographic constants are no more numbers predefined in wincrypt.h, but strings used by CNG to load the crypto-provider that registered that name. Apart from cryptographic primitives, you can now plug in custom cipher-suites or custom certificate elements; documentation about is in CNG SDK, but fundamentally you use core function BCryptAddContextFunctionProvider, as shown in the book. Unlike CAPI, CNG doesn't require Microsoft to sign the implementation and, finally, it is possible for an application to query CNG for supported algorithms, based on certain criteria, if needed; book shows an example using BCryptResolveProviders. Note that only administrators can install a CNG provider.

Chapter also lists all alghoritms available in CNG, distinguishing elliptic curve ones new to Vista and those allowed by SDL. Than, a number of pseudo-code examples are shown using CNG to encrypt, hashing and MACing data, and to generate random numbers, explaining relationship between CNG API and FIPS standard; using Group Policy Objects (GPO) you can configure Windows Vista to use only FIPS-mandated algorithms, but this will affect just protocol suites used by SSL/TLS and .NET code. Auditing levels also have been elevated to comply with NIAP standards. Just like CAPI, CNG still lacks a password-based key derivation function compliant to RFC 2898; you'll have and turn to Rfc2898DeriveBytes .NET class. SSL/TLS improvements comprise support of Online Certificate Status Protocol (OCSP), and Longhorn Server will include OCSP server support. OCSP queries can't be cached, but on the other hand, they're smaller than those returned as CLRs; certutil command-line tool also supports both CLR and OCSP. Finally, Certificate Enrollment API has now to be used, and CAPICOM is no longer supported, in favour of .NET as high-level API.

Enterprise developers will get the most benefit from eighth chapter, which outlines the authentication and ACLs in Windows Vista. A technology staying on top of new features surely is Windows Cardspace, the .NET Framework 3.0 technology which relies on digitally signed XML documents to identify an user, and which is based on well-accepted industry open standards such as WS-Security, WS-Trust, WS-MetadataExchange and WS-SecurityPolicy. All this protocols are covered by Open Specification Promise, ensuring Microsoft will not enforce any patent or intellectual property rights for their use, in despite of effort in time, people and money expended on them. As well explained both in chapter, and in famous David Chappell's tutorial, Windows Cardspace authentication involves a third-part, named identity provider, from whom an Information Card is acquired using a Security Token Service (STS).

Information Cards will be presented to websites requiring proof of identity and, most notably, no credentials will be exchanged with them, since Windows Cardspace owner credentials are only required by Identity Provider: along with server authentication using SSL/TLS, this is a great anti-phishing measure provided by this technology, along with possibility and PIN-Protect the Information Card and displaying of previous use on websites requiring it. Technically, as mentioned, Information Cards are digitally-signed XML data structures that represent information about the user, known as assertions, such as name, surname or e-mail. Such assertion are described using Security Assertion Markup Language (SAML), allowing for interoperability with any Web technology: is at least to mention a Novell-sponsored wiki, Bandit Reference, to which you can login using Windows Cardspace, along with other technologies. Programmatically using Windows Cardspace functionalities is made easy by .NET 3.0 System.IdentityModel namespace; triggering of identity selector is performed through an OBJECT tag using Information Card IE Helper (a MIME type extension application/x-informationcard) and taking SAML claims as parameters. A snippet of code detecting Windows Cardspace support in browser is also displayed.

Finally, Windows Cardspace creates its own private desktop, separed from user's one, for use by CardSpace Identity Selector, so to avoid screen-scraping attacks. Of course, Windows Cardspace technology is a lot more than explained in book, so you shoud refer to Kim Cameron and Vittorio Bertocci’s blog, and to CardSpace resources web page. A short paragraph is dedicated to a true specialistic topic, changes in Credential Provider model involving who develops authentication modules for Windows substituting default Graphical Identification and Authorization (GINA). Finally, Owner Rights SID (SDDL_OWNER_RIGHTS) introduced in Windows Vista allows developer to stop, with any limitations, full control on an object to its creator.

Last chapter is a miscellaneous of all topics that didn't find their place in previous pages. It begins with Windows Vista Parental Controls, a feature available just in consumer-focused versions to monitor and/or limite children exposure to inappropriate content, based on URL, applications and downloads blocking and time limitations. All these features are illustrated using code from Parental Controls Programmer's Reference; finally, a reference is made to blog post logging crimson events on how logging Parental Controls activity reports. Windows Defender is a new antispyware platform embedded in Vista; operating system exposes two functions to enable and disable it and another to get its current status whose use is illustrated in sample C++ code. At time I write this review, all three functions are undocumented in MSDN, so WindowsDefender.cpp code snippet is a very useful documentation, and since these APIs are not exported through a library, you need to get them with GetProcAddress, using function pointers. Developers should read two documents, Windows Defender Antispyware Cycle and How Windows Defender Identifies Spyware, and assuring their software is included in known list through reporting system SpyNet; Microsoft won't accept direct submissions.

To prompt for user credentials, developers should now use CredUIPromptForWindowsCredentials function, whose advantage is that credential dialog is displayed on the Windows logon desktop. C++ sample is really illustrative. Moreover, they should take care and use Common Criteria EAL4+-compliant Vista security log, an easier task since AuthzReportSecurityEvent API is now furnished. A true defense against buffer overruns is pointer encoding, quoted in third chapter also. As you probably know, Windows Vista includes also hardware-based cryptography with Trusted Platform Module (TPM) 1.2 support; at time, most mature implementation is BitLocker functionality. It's true easy developing TPM and BitLocker management tools using Security WMI Providers Reference, an high-level wrapper around definitely more complex TPM Base Services (TBS). C++ example of using TBS is true long, and you should consider using a vendor-provided TPM Software Stack (TSS) to make development easier. Top off this review, I think it's useful reporting a complete list of functions added to Windows API with Vista.

The first comprehensive book about Windows Vista security, this work illustrates also many useful features not directly related with. Sample code illustrates functions undocumented in MSDN at time of this review.

Nothing noteworthy.