Zero-day buzz and unpatched, even ancient security flaws

Michael Sutton on the 0day buzz. An interesting read about how old vulnerabilities can be a serious problem to lazy administrators, or for those who get distracted by the rush of so-called advisories and other linenoise. It's nothing new but it doesn't matter how many times you tell the monkey to stop throwing the banana peel to the floor. Monkeys only care on the banana itself.

The point is, that new vulnerabilities draw attention. The ones that scare me are the old ones, the ones that have been forgotten about. Targeted attacks require specific vulnerabilities but many, if not most attacks, choose not to discriminate. The attacker simply wants control of as many machines as possible to send spam, phish for credit card numbers, etc. In this case, any old vulnerability will do, so long as a multitude of machines remain unpatched.

HD already talked on similar stuff in the Metasploit Project blog, how old and relatively new web browser flaws are being used to spread malware (well, adware would be more appropriate).

This combination of automated fingerprinting followed by a targeted attack should serve as wake-up call to anyone who believes that a patched flaw is no longer a significant threat. The Java ByteVerifier bug used in this script was fixed in April of 2003, over three years ago, yet still works well enough to be a key component of this malware installer. The fact is that an advanced malware installer is capable of attacking almost any browser or operating system and still succeed against enough people to make money for the attacker.

The mandatory links to the news and references:

1. Why all the hype about 0day? Michael Sutton's Blog


2. Internet Drive-By Shootings from The Metasploit Project


3. Internet Drive-By Shootings in the Metasploit Project blog


4. Why all the hype about 0day? at Slashdot.org


5. WebAttacker Unseats WMF as Most Popular Exploit

Microsoft Windows Vista beta-2build 5384: ASLR testing

Only heap is randomized and it's just around 7 bits (some times reported 5, 4, none and at most 8 bits), DLL base randomization only takes place in boot time and it seems to be just incremental in most cases (and affects only core system libraries like kernel32.dll), thus likely predictable:

kernel32.dll: GetTickCount()
774A910E
[reboot]
774F910E
[reboot]
77B6910E


No VirtualProtect() restrictions exist, thus all tests of that category fail. With DEP policy set to OptOut, the basic memory permissions enforcement tests have all positive results.

Looking forward to test the stack randomization and other improvements in post-beta-2. Right now, the results show the effects of a weak implementation, the heap randomization is too low for being considered truly effective and the fact that DLL base randomization is performed on boot time doesn't help. Basically, this is the same as a Windows XP Service Pack 2 system with DEP policy set to OptOut and hardware support for the NX bit.

Vista Probe reports "No Randomization" for the DLL base test due to the way it's done. It expects the executable to perform runtime randomization of the base address, but this is obviously not the case. It will work fine for both stack and heap randomization, as well as EXE base randomization (if it can be enabled on third-party applications).

A new article by Michael Howard, but still no information available with an in-depth explanation of how ASLR is implemented in Vista:

• Windows Vista Security – A Bigger Picture

Microsoft Windows Vista: Measuring the security enhancements.

A few days ago, Michael Howard, a member of the Microsoft Security Engineering group, made available a short description of what's supposed to be Address Space Layout Randomization (ASLR) in Vista.

• Stacks and Heap are randomized (stack-randomization is on post-Beta 2)

• EXEs and DLLs shipping as part of the operating system are randomized

• All other EXEs and DLLs will need to explicitly opt-in via a new PE header flag; by default they will not be randomized. 'Note that DLLs marked for randomization, such as system DLLs, will be randomized in every process (regardless of whether other binaries in that process have opted-in or not.

http://blogs.msdn.com/michael_howard/archive/2006/06/06/619163.aspx

As an experiment, the enhancements were tested by using a modified version of the paxtest tool, originally developed by Peter Buser and used for testing the capabilities of PaX and other projects, as a regression test suite capable of guessing how many bits are currently being randomized in a concrete section of memory, for example one allocated in the heap; among other tests (ie. return-to-function, etc). While the tests are pretty simple, they provide unbiased proof of the strength or weakness of the implementation being examinated. The information disclosed by Michael, days before the above quoted article, commented on the "probability" of guessing the right address on exploitation time:

In the case of Windows Vista Beta 2, a DLL or EXE could be loaded into any of 256 locations, which means an attacker has a 1/256 chance of getting the address right. In short, this makes it harder for exploits to work correctly.

It's worth noting that no snake-oil is present. He points out that, actually, ASLR makes successful exploitation of memory corruption-related issues harder. And that's completely true. Although, we are missing something here. The point is how difficult exploitation will be. And definitely, the current approach implemented for Vista is, with no offense meant to anyone (and again, no bias here), useless.

For an application that suddenly dies as of an attack or repeated attempts of exploitation, ASLR is a good option. Although, if we look over applications that actually re-spawn child processes and the like, the lower the randomization is, the higher the probability of successful exploitation in less time. What applications behave in such a suicide way? Apache is a good example :)

A GUI, user-friendly regression test suite is in development, which will also properly test the "Security Enhancements in the CRT " introduced in Visual Studio 2005. It could be, to make an analogy, the IBM Stack Smashing Protector (aka ProPolice) for Windows-based systems.

Some references for further information:

1. Security Enhancements in the CRT
2. Saying Goodbye to an Old Friend
3. Security-Enhanced Versions of CRT Functions
4. Michael Howard's Web Log
5. Address Space Layout Randomization
6. Windows Vista Address Space Layout Randomization – What is Randomized?
7. Address Space Layout Randomization in Windows Vista

Game bugs?: Jedi Academy, gravity out

Playing multi-player online games is fun. No one else doubts that, well, no average human at least. But some people, as it happens mostly everywhere, also have fun making the experience of others the worst possible. From so-called "spawn killers" (yes, those who don't let you play even a second, throwing thermal detonators right next to you when you get "spawned" in the area) to spammers (those who should keep out of playing for a while, as announcing their new kill record gets boring for most of us) and the more-than-hated h4x0rs. Those are the real problem. Either an unfair administrator or a player with some skills and knowledge, can take advantage of specific problems inside the game engine to do all shorts of tricks.

Today's episode is about a little trick that will make most Jedi Academy players out there smile the first time they see it in action. Beware of bugs, gravity doesn't seem to affect them.

Short explanation: gravity value is used to calculate the height you can gain when jumping, the velocity needed to get back to the ground, etc. The problem is that, if gravity value changes when a player is jumping or "flying", the new constants are applied immediately. The result in this case, is first putting the player characters at the highest height and then literally crunching them into the ground.

Smells like... snake-oil?

• Snake Oil Warning Signs: Encryption Software to Avoid
• Steganography snake-oil exposed
• Beware of Snake Oil
• Crypto-Gram Newsletter: Snake Oil
• PGP Desktop Wipe Free Space Flaw