Microsoft helpt bij het bugfixen van third party software

Straks worden ze nog een distro...

Lijkt mij dat het vooral Microsoft zelf is dat hulp nodig heeft.

De bewuste paragraaf.

Statically positioned DLLs and executables

ASLR is only fully effective if everything in the process address space is randomized. If somecode or data remains at constant locations in memory, it become an appealing target when building exploits. The first and perhaps most obvious technique is to look for images that are mapped at their preferred image base in the address space. As detailed earlier in this paper, in the default configuration on Vista, only executables and DLLs that have the IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE flag set in the optional header will be randomized. In order for this flag to be set, the binaries must be built with Visual Studio 2005 SP1 and have the /DynamicBase option passed to the linker. Microsoft are quite diligent about doing so in the binaries shipped with the Vista operating system and most of their other products. However, Independent Software Vendors (ISVs) have been slower to adopt this option and as a result, many third-party binaries on a typical desktop are not protected by ASLR.
This style of attack is particularly attractive when targeting browsers, due to their plugin architecture. When a user visits a potentially malicious web page, there are quite a lot of opportunities to load a wide range of DLLs by employing techniques such as:
Instantiating ActiveX controls or plugins that the user is likely to have installed.
Utilizing specific features of the browser or its extensions that result in DLL loading - such as using specific scripting languages, or using specific features of these languages.
Specifying URL schemes that require protocol handlers that load in-process within the browser to deal with those special URLs.
Supplying input data that results in library loading to do some sort of special handling of a specific Content-Type.
Requiring associated metadata handling, such as dealing with security signatures/hashes within a mobile code package.
Requiring user authentication with an authentication mechanism that has its own library.
Embedding media of various types that require loading of specific libraries to parse the data (such as an image parser or a video codec).

Practically static objects

A slight variation of statically located objects is when data objects do not have a fixed location per se, but they can effectively be relied upon to exist in a certain region of memory. This situation is often a potential issue when a growable object exists in memory that can be grown to an arbitrarily large size by the user. This technique has been very popular in the last few years when dealing with heaps that exist in the process address space. Commonly referred to as "heap spraying" or "growing the heap", this technique essentially involves exhausting the regular space available and forcing the heap to grow to be much larger. Providing that allocations are somewhat linear and the the virtual address space is limited (such as in 32-bit processes on x86), it is possible to guess where some of that data will be mapped.
For example, the heap randomization on Windows Vista shifts the base of the heap by up to 2MB. If the attacker can allocate more than 2MB of data on the heap, they will be able to guess a
valid pointer into their data, regardless of the heap randomization.

Partial overwrites

A partial overwrite is a memory corruption technique where only the least significant 1 or 2 bytes of the pointer are modified. Performing overwrites of this nature can be effective in an ASLR
environment, since the attacker is not required to know the real address of an object in memory, but rather just the relative location of the new target from what the pointer pointed to originally.
Since all image randomization in Vista is performed only on the high bytes of an image address, the low two bytes will be the same regardless of where in memory the image is loaded.
This style of attack is a well-known and often utilized technique among security researchers and hackers, and has been in wide use for quite some time. It tends to be a particularly effective technique on little-endian platforms, since contiguous memory overwrites (such as standard buffer overflows) will corrupt the least significant bytes before the more significant bytes. One of the most well-known scenarios where this has been used in the past is when a single-byte ("offby-one") buffer overflow is discovered in an application that is writing to a stack buffer. This particular scenario is quite unlikely to be exploitable in many cases now due to security enhancements in compiler technology such as the /GS protection in the Visual Studio compiler.
In practice, the ability to perform partial ovewrite attacks is very dependent on the nature of the vulnerability - what is being overwritten, whether the attacker has precise control over how many bytes can be overwritten, whether the overwrite is contiguous, and what pointers are available to corrupt.

Memory information leaks

Finally, there are information leaks. An information leak vulnerability is one that allows the attacker to glean some useful information about the memory layout or some useful state
information about the target process. In the context of bypassing ASLR, ideally the attacker will want to obtain a pointer value. These are immensely useful for the following reasons:
A pointer can be used to determine where an object is mapped in memory. For example, a pointer to a stack gives away at least a portion of where a thread stack is in memory.
Also, a pointer to a static variable will betray the image base of a particular DLL or executable.
Additional information can be inferred from such a pointer. For example, a frame pointer to a stack frame not only tells the attacker where a thread stack resides, but if the attacker knows what function the stack frame is for, they are able to determine a great deal more about that thread's stack. They will know what data elements surround that frame pointer, as well as those from previous stack frames. For a data section pointer, they are able to determine where that image resides in memory, not just where a single data element is. Heap pointers will be useful in pinpointing exactly where a specific data
block was allocated, which could be useful for an application-specific attack.
In the context of Vista's ASLR, information leaks have an additional advantage. If an attacker is able to learn the location of an image in memory, then it follows that they will know the location of that DLL in not just that process, but for all processes running on the target system. Recall that a DLL's position in memory is initially determined by searching the _MiImageBitMap variable for an appropriate location, and this bitmap is used for all processes. So, finding a DLL in one
process effectively allows you to locate it in all processes.

Speciaal voor Theodoor en ArjanB die het idee hebben dat de onderzoekers bevindingen niet specifiek zijn voor de browseromgeving maar voor heel Vista en voor Peter die denkt dat ik niet begrijp waar ik het over heb, wat aanvullende informatie van een van de researcher zelf.

am one of the authors of the paper referenced in the post above. First of all, I'd like to apologize for the sensationalism of the press coverage. Most of the articles about our work are completely inaccurate and full of ridiculous statements. Mark and I had nothing to do with these articles and were not contacted by their authors.

Please read our slides and paper (available from http://taossa.com/) before making any judgements about their content.

What we've done is show that the exploitation prevention mechanisms implemented in Windows Vista (including DEP and ASLR) are ineffective at preventing the exploitation of browser memory corruption vulnerabilities, due to the following factors:

1) the amount of contol an attacker has over the state of the browser process

2) the plugin architecture that allows third party plugins (Java, Flash, Acrobat) which often weaken these protections

3) the architecture of the browsers which run all code in the same process and have no isolation between different components

Our research is focused only on browsers. The protection mechanisms in Vista are still effective at preventing the exploitation of vulnerabilities in server processes, which is why I believe that Vista is still more secure than any previous version of Windows.

Posted by: Alexander Sotirov at August 11, 2008 6:59 PM

De onderzoeker zelf zegt dus zelf dat de berichtgeving vooral sensatie is veelal niet correct en zegt ook nog eens letterlijk dat hij nog steeds vind dat VIsta veiliger is dan alle voorgaan windows versies. Die uitspraak zal ik de volgende keer in de eindeloze discussies nog wel een paar keer moeten aanhalen denk ik.

@Peter
Wil dat door die verschrikkelijk dikke oogkleppen dringen!? Geloof je nou werkelijk dat die mannen alleen maar een pakkende openingszin zochten!?

Inderdaad, ik vind de vette koppen puur overdreven en de onderzoeker zelf geeft mij gewon gelijk

Je bent het stadium lachwekkend voorbij. Ik begin nu echt het stadium plaatsvervangende schaamte te naderen. Wie wil er nu geassocieerd worden met de plaatselijke dorpsmaloot.

Dat mijn woorden in bovenstaand discussie vrijwel lettelijk bevestigd worden door de betreffende onderzoeker zelf vind ik wel ok en niet lachwekkend dus ik negeer je uitval maar als zijnde een vlaag van verstandsverbijstering.
Misschien moet je perskoppen over Vista wat minder letterlijk nemen en wat meer zelf nadenken om tot een wat meer genuanceerd beeld te komen ipv van te proberen mij belachelijk te maken omdat ik het niet met die vette koppen eens ben om er dan achter te komen dat mijn beeld van de situatie echt volledig wordt bevestigd door de betreffende onderzoeker zelf.

Omdat er nog veel nieuws later is binnen gekomen op de bovenstaande discussie hier wat nagekomen links:

Webwereld: Vista's beveiliging niet onherstelbaar stuk
ZDnet: Vista security not rended useless
Ars technica: The sky isn't falling
Black Hat researcher Sotirov: News Vista security broken completly inaccurate