Saturday, January 21, 2006

Wehnus Wehntrust (Address Space Layout Randomization)

The other day someone sent me a link to www.wehntrust.com, made by a company called Wehnus.
as its web site states, it is a "Host-based Instrustion Prevention System (HIPS) that
provides secure buffer overflow exploitation countermeasures." [..]
[..] "WenhTrust implements Address Space Randomization (ASLR) for Windows".
There are two versions available, one for commercial user and one for home users.
Both versions have different features:


Home version features:



  • Randomized Image Files (DLLs, EXEs with relocations)
  • Randomized Memory Allocations (Stack, Heap, etc)
  • Randomized PEB/TEB
  • Application and Image File Randomization Exemptions

Commercial Version features:

  • Same feature set as the home user version
  • Native event logging when exploitation occurs
  • Balloon tip notifications when an exploit is detected
  • SEH overwrite prevention
  • Format string vulnerability prevention
  • Stack overflow detection
  • Brute force detection and prevention
This product looks very nice so I installed it on my home computer and so far
I did not have any stability problems. I did some tests
quick tests, this is not intented to be a full review of the product, just me
playing around for 2 minutes with the product:

The Randomized Memory Allocations seem to be working fine, sample program:

void main()
{
char *p;
int i;
unsigned int espvalue;

_asm { mov [espvalue], esp }
printf("esp: %X\n", espvalue);

for ( i = 0; i < 7; i++) {
p = malloc(2000);
printf("%p\n", p);

}
}


Output:



C:\tmp>test
esp: 5708FED8
572F0758
572F0758
572F0758
572F0758
572F0758
572F0758
572F0758

C:\tmp>test
esp: 372CFED8
37510758
37510758
37510758
37510758
37510758
37510758
37510758

C:\tmp>test
esp: 4151FED8
41790758
41790758
41790758
41790758
41790758
41790758
41790758

C:\tmp>test
esp: 48CDFED8
48F70758
48F70758
48F70758
48F70758
48F70758
48F70758
48F70758

C:\tmp>


This was tested on a WinXP SP2. Running the test without wehntrust shows
the same addresses on every execution (for both esp and heap address).
I did not test PEB randomization because it is already done in XP SP2 and I
didn't care much for it anyways. You can observe that how randomization
is performed is pretty clear.


To test the "Randomized Image Files (DLLs, EXEs with relocations)" feature
I wrote this simple program:


void main()
{
printf("%x\n", LoadLibrary("kernel32.dll"));
printf("%x\n", LoadLibrary("ntdll.dll"));
printf("%x\n", LoadLibrary("advapi32.dll"));
printf("%x\n", LoadLibrary("wsock32.dll"));
printf("%x\n", GetModuleHandle(NULL));
}

Output:


C:\tmp>test3
1b0a0000
1ac30000
1b230000
1ddd0000
400000

C:\tmp>test3
1b0a0000
1ac30000
1b230000
1ddd0000
400000

C:\tmp>test3
1b0a0000
1ac30000
1b230000
1ddd0000
400000


The product documentation says it only randomizes PE files with relocations, and my
PE file (as almost any regular EXE PE file) does not have relocation info, so
getting 400000 for GetModuleHandle(NULL) is expected. For the other dlls, the
address shown is in fact not the default one for the dlls, but as you can see,
the address does not change on a per execution basis.

3 comments:

deft said...

Wehnus was coded by skape from metasploit/uninformed.org. Pretty nifty app. Only had issues when used in conjunction with Norton for some reason, although that may be fixed now.

--deft () thunkers ! net

Cachimaster said...

Sure that app can't relocate a system dll in use. Try some custom dll, and add some "freeLibrary" calls

hernan said...

yes, but the great thing would be to relocate ALL dlls. If you don't realocate all DLLs one can always look for a "jmp reg" or sthg in the DLL that has a fixed address (e.g: wsock32.dll); what defeats the idea of having random address for dlls in the first place. It is still useful to have 'some' dlls relocated, but the best thing would be for all dlls to be relocated on every execution. (relocation on a per-boot basis is also not very good (althoug it might be good enough sometimes and is better than nothing), because you can use some memory leak bug to get the info you want (address of dll), or if it is not a one-shot vulnerability you can do some brute-forcing).