Jump to content
Tuts 4 You

Recommended Posts

waliedassar
Posted

One of the new interesting features introduced in version 2.0 of OllyDbg is the ability to pause on TLS callbacks. Actually, i discussed some flaws of this feature in a previous post, but in this post i will show you a minor bug (not so minor) that i found while playing with OllyDbg, like i sometimes do.

OllyDbg v2.0 assumes that the "Size" field in the TLS data directory is mandatory, but it is actually not. To make things clearer, i will dump the ntdll.dll code responsible for parsing the TLS info.

1.png

As you can see in the image above, the "RtlImageDirectoryEntryToData" function is called to get the absolute address of the "IMAGE_TLS_DIRECTORY32" structure. Its fourth parameter is a pointer to a variable that receives the size of "IMAGE_TLS_DIRECTORY32" structure, which is typically 0x18 bytes. It is easy to notice that no checks are done to verify the size.

To be even more sure, let's check the code that extracts TLS info in the "RtlImageDirectoryEntryToData" function .

2.png

As the two images above imply, the OS loader simply discards the "Size" field and continues invoking TLS callbacks.

On the other side, OllyDbg stops processing the TLS info. if the "Size" field is zero. See the image below.

3.png

The source code for the image above should be something like this.

44.png

We can easily figure out from the source code that setting the "Size" field to Zero is enough to fool OllyDbg to ignore TLS info. We can also fool OllyDbg by setting the "Size" field to 0xC or abit longer depending on the executable's ImageBase.

77.png

Things get more interesting if the "AddressOfCallbacks" member is e.g. 0x01F12200 and the "Size" field is 0xF. In this case, OllyDbg will place the int3 breakpoint at 0xF12200 and since 0xF12200 will never be hit, the breakpoint will be left untouched.

Just play with this demo.

http://ollybugs.googlecode.com/files/fake_tls.exe

N.B. Many file inspectors are also affected by this bug e.g. Stud_PE and exeinfo.

  • Like 2
Posted

Interesting... so is the size not used at all by ntdll.dll? It seems to be put into dword ptr: [esi] - nothing useful happens with after that such as error/bounds checking?

Another nice post, thanks :)

For those not already doing so, you can follow waliedassar's blog here: http://waleedassar.blogspot.com/

Posted

If you haven't already read it, you can probably get a few attack vectors from Undocumented PECOFF. There should be something in there to break every tool out there.

waliedassar
Posted

Hi Loki,

No, the size value is not used, at least in the "_LdrpCallTlsInitializers@8" function, the function responsible for dispatching TLS callbacks.

Waliedassar

Posted

Interesting find, but why is there an almost empty 16mb last section in the test exe?

waliedassar
Posted

I just wanted the addresses 0x01F12200 and 0xF12200 to exist in the virtual address space of my demo application, such that the "Readmemory" function call (with the "bytes to read" parameter set to 0xF instead of 0x10) succeeds.

0x01F12200 points at the real TLS callbacks array. 0xF12200 points at the fake TLS callbacks array.

Hope this helps.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...