Sunday, July 30, 2006

A brief look over the crazy domain names business

Seems like this "virtual real-state" business is getting some publicity this month, after some news and interesting overviews appeared around on blogs and news sites. One of them is written by Dennis Forbes, with title "Interesting Facts About Domain Names". He checked thousands of domain names, with different number and word combinations, and surpisingly finding that most if not all, have been taken already. Do they have developed content? Seems like they don't. People starting a web-based business can have a tough time for finding a really good brand they can market and use for word-of-mouth advertisement, as they need to look for more complicated names, hyphen-based ones, using not so nice TLDs (ex. no .com, no .net, no .org).

Dennis did a certainly nice job for creating charts to show the statistics, one of them on the different possible length letter sequences:

Registered letter sequences domain names

Most companies go for a domain name broker or speculator to do the job for them, find a potentially brandable name and then starting the negotiations with the owner and finally doing the proper transaction via a escrow agent. The point is, How much do these brokers get out of each operation? The usual commission is around 10-5% of the final value.

How much does the owner get? Well, here we go with the interesting stuff.

Friday, July 14, 2006

The other side of VirtualProtect() and friends: DEP evasion

As some people may think that the regression tests which involve VirtualProtect() usage for evading DEP, are wrongly implemented and present a legitimate feature as a potential risk, the images below show "hot spots" in the disassemble of Microsoft Windows Media Player and Skype. The first, as most multimedia applications in either GNU/Linux or Microsoft Windows, needs to generate code on run-time and this requires access to executable memory. Skype was known to break with Data Execution Prevention (DEP) enabled, until it was fixed...

Image below shows Skype allocating memory with PAGE_EXECUTE_RADWRITE access:

PAGE_EXECUTE_READWRITE 0x40

Enables execute, read, and write access to the committed region of pages.

Allocating memory with such a nice permission is for sure an easy way to get around DEP-related compatibility issues. Basically, DEP will be useless. If the memory area allocated, receives some-how user input (or at least is partially controlled by another process), code could be written and then executed without any barrier, including DEP protection.

19.01.2006 version 2.0.0.73

  • bugfix: crashes when DEP is supported in hardware

Now let's look over Windows Media Player....

It doesn't matter if we allocate memory with RWX (Read-Write-Execute) access or we just allocate it with write access and then change it to be executable. In any case, if memory becomes executable after writing from user-input or similar unsafe sources, DEP will be unable to protect against it, as there's no enforcement in place for memory access permissions. You just have to rely on the vendor, and trust that they didn't go the easy way and didn't fix their code, but just applied a workaround.

For further information:

  1. MSDN Memory Management functions: VirtualProtect()
  2. MSDN Memory Management functions: VirtualAlloc()
  3. MSDN Memory Protection Constants
  4. Blog on Cyberterror: A DEP evasion technique
  5. ZDnet blogs: Skype 2.0 looked like a virus
  6. Skype change-log
  7. Buffer Underruns, DEP, ASLR and improving the Exploitation Prevention Mechanisms (XPMs) on the Windows platform. By David Litchfield, NGSSoftware Insight Security Research (NISR).

Tuesday, July 11, 2006

Browser fun everyday

The people from the Metasploit project came up with a certainly nice idea: a blog-style publication for releasing web browser bugs and security flaws on a daily basis for one month. A rush of issues have been published, affecting a wide range of browsers, from Microsoft Internet Explorer to Safari. Just for the shake of mayhem and destruction, some issues will get published over here as well, discovered using either their tools (DOM-Hanoi, etc) or the under-going project for developing an easy to use QA and vulnerability assessment framework, QANUM (first show-case is out...).Today's one is a simple and not-really-useful NULL pointer dereference in the Macromedia Flash ActiveX component function LoadMovie():

a = new ActiveXObject('ShockwaveFlash.ShockwaveFlash');

try { a.LoadMovie(-1, "bogus.swf") } catch(e) { }

The bug is triggered by passing a non-zero value to the first parameter (which represents the layer for the loaded movie). Nothing really interesting, right? It seems already fixed in Flash 9 (finally after remaining in 8 for quite a bit of time), and it seems there was previous knowledge of the bug, two years ago. Nice timing.