WehnTrust - opinions/experiences?

WehnTrust... adds ASLR & SEHOP to Windows XP SP2-3. I was looking for any insight into this app. Experiences especially, regarding v1.2, since it's become open source. Namely footprint & stability, but any info. is appreciated.

Also how it is deployed. Like is there a GUI with configuration options, ala EMET... perhaps even an icon in the system tray? Some service/process running in real-time? Or is it an install & forget thing that just works quietly in the background, just like DEP is doing for me now? If the latter were true, and it's light & stable... then this is something I believe could benefit many an XP user.

I saw some less than encouraging reviews of instability, but they were quite dated, and related to an older version and before it became open source. I haven't really seen anything about it lately, in it's present state. And was hoping someone in here was using it as it is now, in the present. Apparently back then there was a free & paid version, and the former was buggy.

I'm thinking about giving it a test drive, but wanted to get as much info. as possible first.

Thanks...

 

Well it seems nobody has any experience with this tool. So next phase:

... does anyone in here using XP, with either a 2'nd/test machine and/or a VM feel like taking the plunge to test it out and report their findings? I would if any of those scenarios applied to me. Sure I could restore an image if something went wrong, but I'd feel much safer doing it on a test machine or VM. As there is always a chance a box can be crippled to the point you can't even restore an image. And this is the only one I have.

So I'd like to get more info. on this thing before I jump in.

 

WehnTrust threads & posts https://www.wilderssecurity.com/search.php?searchid=5015633

Take your pick

I did install it some years ago, but i can't exactly remember what my experiences were of it now I have a feeling that if they were positive, it would still be installed, but it isn't.

If you or anyone else does, i'd be interested to hear what you think about it etc

 

First off... that link leads nowhere. Also, I probably read that post, it's several years old and references an older version, if I recall. It has changed since then and that's why I specially asked for "current" info. Back then there were a free & paid version, and the free was known to be buggy. Since then it's gone open source and the (previously) paid version is the only one... and it's been updated a few times as well.

Looking around the net all the info. I see about it is at least 4 years old, if not more. I see nothing current. That's why I was hoping someone in here has recent/current experience with it. And if not could maybe test it in a VM/test machine to give a nice (current) review... as if it's stable it could be a very nice option for XP users. To be able to utilize the mitigation techniques without having to add the surface of .NET FW = a very nice thing, if it's stable & light.

I would totally do it in a second if I had a 2'nd/test machine. But I'm too poa. I can't even afford a new 1'st machine.

 

I wanted try it, but this thread let me some troubles... https://www.wilderssecurity.com/showthread.php?t=236236

 

Wishing somebody with lots of free time will do the testing for you. If there's nobody willing to take the burden, perhaps, you can do the testing yourself. As they say, no pain no gain. In lieu of a separate test machine, you can create a new partition if you have ample drive space and test it from there. Or if there is no space left for you, you have no choice but to test it on your sole workmachine after first having a nice working image back-up you can restore later on offline. Just re-image back to your previous after you have finished testing.

 

Meriadoc and others think the author skape is no blackhat but an oldhat...
http://forum.sysinternals.com/topic18323_page1.html

It's just the nature of the program.

 

It's really not like Appguard or NVT. The better comparison would be that since everyone is using EMET no one bothers with something like WehnTrust. That and I doubt many people are even aware of it's existence.

Nevermind anyway. I was just reminded by a member here that ASLR is not possible on XP. Whatever WehnTrust does, it must be a pseudo-ASLR measure, and not the true mitigation. And could therefore be bypassed trivially I'm sure.

So nevermind... I have no desire to pursue this venture after all. Mods can close this thread now if they wish.

I think I'm going to install EMET when XP reaches it's EOL. Once it's no longer being patched such a tool would then be very useful towards safely extending it's life. Because I really have no desire to use any versions of Windows since XP.

 

Well I have it up and running, and no problems. I can't "feel" any footprint, but after actually looking at it on paper, err... on my monitor anyway, I see there is indeed a good bit of resources being used:

I am now caching about 110 MB more physical RAM at boot. Considering my previous "total" was about 208 MB, that's a lot to me. But only because my setup was so trim prior. But with 2 GB available I'm still not even close to a point I'd notice it.

It adds 1 service & 1 process. 2 processes if you keep the tray icon, but I don't.

And 2 startup entries.

Normally, I'd consider a program that does these things bloatware... but I feel this is hardening XP in a manner sufficient enough to offset it. And because I'm so trim otherwise I can take it in stride.

It adds absolutely no CPU usage, I/O.

 

And the interface couldn't be more simple. If you right click on the tray icon there are 2 things: Options, & Exit. Choosing Options opens the interface:

A little box with 3 tabs:

1- Shows the protections offered. And has 2 check boxes along the bottom... one to enable/disable the protection, and the other to enable/disable the tray icon.

2- An exclusion list

3- An "About" section... with your typical info. about the product.

Doesn't get simpler than that. My only regret is not discovering this app sooner.

 

You can try SLIPFEST> http://slipfest.cr0.org/ to evaluate WehnTrust or EMET for that matter if it can block Slipfest's shellcodes from running in remote process and/or running on stack. To use: after running Slipfest, click "shellcode", then dropdown to "access control", select "spawn process", then either select "WinExec" or "CreateProcess". If WehnTrust fails to block the shellcode, the payload calc.exe will execute.

 

Now I tried WehnTrust on another computer and the memory randomization component wasn't working... seemed a necessary driver for it wouldn't install properly or something. So I reimaged.

I wonder... the machine I tested it out on first, that it ran fine on, didn't have it's OS partition encrypted with TrueCrypt. The other one did have that encryption. I wonder if that makes a difference? Like will OS encryption prevent WehnTrust's randomization from working properly? Or maybe even Comodo's Execution prevention... perhaps I should have turned it off first, or at least taken the level down to Limited or even partially limited? Then change it back afterward. I did that on my primary machine... but not the other one. Could that also make a diff?

 

Blogued about it 6 or 7 years ago...and as previously said, quite useless todays. BO is a kind of Ebola of Insecurity, as there is no perfect code, there is no solution against this threat, only ways to mitigate risk and impact (NVT or AppGuard will not block the exploit, but might prevent the exploitation of the vulnerability by blocking a zero day pdf malware, or a privilege escalation from admin to system rights for instance).
The dev. of Geswall Andrey Kolishak has provided similar hardening dll tool called BoWall http://securityvulns.ru/bo/eng/BOWall/index.htm

Most anti-BO has disappeard, as this niche market seems too specific to be a viable business model: StackDefender, OverFlowGuard, Ossurance Desktop, DefensePlus...all has joined the cimeteray of discontinued security softwares.

The only survival, perhaps the most serious desktop solution against buffer overflow is still BufferShield, that has been discussed on this board a few years ago http://www.sys-manage.com/BufferShield/tabid/61/Default.aspx

Real life testing can be done with Metasploit framework, in a more easy way if the System is unpatched for some known vulnerabilities.

rgds

 

Well I "kinda" figured out the problem. A conflict between WehnTrust & Comodo FW/D+'s Buffer Overflow Protection (Execution Control tab). As has been stated, it's a sort of pseudo ASLR technique that works very much like that component in D+ does, or the old Comodo Memory Firewall. True ASLR would not conflict with it in that way, which is why EMET users on post-XP systems using Comodo with that setting checked would never run into this problem.

Only problem with this theory being... I have that setting checked on my main box too, yet WehnTrust is functioning just fine! Yet on another box that is virtually identical, the two conflict. And I must disable Execution Control to get WehnTrust to install properly.

So it seems more than anything that this WehnTrust program just has a mind of it's own. It's unpredictable and fickle. Although I have it running fine on my main box right now I cannot in good conscience recommend this to anyone else. Given the choice, for XP users, I'd choose the B.O. protection Comodo's D+ offers... a well, currently developed product. It does pretty much the same thing as WehnTrust. Combined with Hardware DEP, and maybe the app specific mitigations EMET offers (even in XP), you're pretty well protected. Especially if your internet facing apps are also sandboxed.

And for post-XP OS's the answer is very simple... use EMET for ASLR & SEHOP, whether you use Comodo or not. If you do though I'd think the B.O. protection would be kinda redundant, and just disable it to avoid potential conflict and overlap. Because Hardware DEP + ASLR will protect against shellcode injections better than that component in D+ ever could, IMO.

But just the same, since it's working for me I'm keeping it. And have added the directories for each to each others' exclusion lists to avoid potential future problems. And suggest doing the same if you feel the need to get both working together, which again I don't recommend.

 

I just got rid of the thing. I got the feeling maybe this was one of those situations where everything "seemed" to work fine, but there was some conflict behind the scenes. And that instead of having 2 things protect me, really neither were. And it wasn't a hard decision on which was going to go.

I saw on the website that WehnTrust was labeled a HIPS, even though it didn't act like the (modern) ones we're accustomed to. So no wonder there'd be a conflict. Comodo's blocking of shellcode injection probably works in a very similar manner, and I trust it more. I believe it could prevent against exploits every bit as well as ASLR and/or SEHOP could when combined with Hardware DEP... it's just variations on a theme really.

But for XP users that aren't using any HIPS... it (WehnTrust) is something you "may" want to look into. But my affair with it has come to an end. I feel pretty well covered with hardware DEP, Comodo's Execution Control, and NEMET's app specific mitigations. And quite frankly... felt perfectly safe before all this with just software DEP & Comodo's D+. But I get kinda OCD about things sometimes.