Outpost disables Windows' kernel memory protection. Why? - Prophets and Loss - polala.com

POLALA.COM
welcome to my space

Search:

Web Design

Video Games

RVs

Religion

Management

Supplements and Vitamins

HOME

Welcome to:polala.com

NAVIGATION -

HOME

Outpost disables Windows' kernel memory protection. Why?
Published by: mike 2009-01-07

I just installed Outpost Firewall Pro 2.5.370.370 on my Windows XP Pro SP-2 system. I logged the install with some third-party utilities, and noticed something that bothers me.

Outpost, upon installation, creates and sets the following registry value:

Key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetContro lSession ManagerMemory Management
Value: EnforceWriteProtection
Data: 0

The reason this bothers me is that this one little registry change allows programs to overwrite kernel memory, as described here (http://www.securiteam.com/windowsntfocus/5VP021535K.html) and elsewhere:

[An EnableWriteProtection value of 0] would (after reboot) disable the Memory Protection scheme of Windows 2000 [or Windows XP], in turn allowing malicious code to overwrite parts of the memory that do not belong to it. This would enable an attacker (local or remote) to overwrite sensitive parts of the memory (including the kernel) causing a complete system compromise.
I looked at an old log I had for Outpost Firewall Pro 2.1, and it did the same thing then. Yes, I'm sure my registry did not have this value before installing Outpost, let alone set to 0.

Does anyone know why Agnitum does this? Or if there are any consequences (related to Outpost functioning) if the value is removed or altered?

The process memory control feature is enabled by default so i dont think people with default configs need to worry.

wl_hook, windows logon hook, is able to manipulate other programs.
Sometimes a part of trojan/malware/adware.

Still no response from my support inquiry regarding this, but hey, it has only been three weeks, right?

Just an FYI for anyone concerned: When Outpost Firewall Pro 2.5.375.374 is installed, it creates the "EnforceWriteProtection" value (if it doesn't exist), and sets it to 0. So, if you upgrade, you may want to obliterate that value again.

This link from Symantec has something

http://www-cu.symantec.com/avcenter/venc/data/backdoor.haxdoor.e.html

What key are you talking about? The "EnforceWriteProtection" item is a value, not a key, and it does not exist by default. I assume that you are referring to "EnforceWriteProtection" as a key, so...

You're fine. Just delete "EnforceWriteProtection" and memory write protection will be enabled after a reboot. That's the default (per Windows) anyway.

I do see your point. But we arent really any closer to solving this at this time. If Outpost has decided to write this new registry entry and set it to "0" then:-

1) There must be either a very good reason to impliment it; or
2) It is sloppy programming by the Agnitum developers.

I think ill submit yet another ticket about this and see if I can get any answers, and perhaps we can get this thread resolved.

Richie

I now just run the following registry script after installing a new release to remove the key. Doing so hasn't caused any problems:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetContro lSession ManagerMemory Management]
"EnforceWriteProtection"=-

I reported this issue to Agnitum. I'll let you know what they say.

I am getting confused (:
Is there a difference between having the key set to 1 and not having it at all?

I think the best thing is to check using some leak tester to see if this key is really opening any holes, but i'm sure op's Process memory control module would detect it.

That is true. However for many users who install Outpost under DEFAULT configuration they will fail many of the leaktests. So what about this situation where users have default config and the key set to 0? Are they at "more risk" then those who have tightened up the component control settings etc?

Richie

I'm not sure it's a stability issue, as I've seen more than my share of BSODs caused by buggy drivers in the past, without that setting being present at all. Just install the Blockpost plugin, then go into Device Manager and try to Stop it, as one example.

Hi

i mailed agnitum today . lets see if they come up with an answer. Ill let you know if i receive any info

regards Nolan

For all of you who have been eagerly waiting for it:

Our beloved problem still exists in v 3.5 ... :eek:

Now, that doesn't seem to be a big deal since you can easily edit that respective registry entry (if you are aware of it !!!). However, given that Agnitum have repeatedly maintained that they had fixed this issue (which shouldn't be all too difficult), that's casting a damning light on the performance of Agnitum's internal quality control.

Considering the other issues introduced with 3.5 and discussed in this forum, I'm seriously considering switching to another firewall for the first time in several years. The recent versions of ZAPro are said to be rather good ...

Hello,

Im using 3.5 as well and ive just checked and its been set to a value of 0. I dont think deleting the registry key/value would be the answer and could cause issues..... so would it be better to change the value to 1 and leave it at that if there was no issues with the functioning of Outpost? There must be a reason why Agnitum have put this registry entry in place or is it just poor programming by the developers?

Richie

so, do you guys reckon it's safe to re-enable EnforceWriteProtection with
newest version of Outpost?

Here we are again. :mad:

The problem still exists in v3.0 (557/437) ...

That's why I pointed that out a few posts up. :)

i havent tried it but are there any side effect if i set the value to zero, or does outpost only BSOD when i remove the entry?

So it is required to turn off the Write Protection (this is done by the Setup program). At the boot time, somesoftware driver checks this value and if it's not equal to "0", it doesn't try to "hook" system services (this would cause a system crash) and exits - that means the driver doesn't load correctly and though somesoftware cannot start.

As you probably know, Microsoft doesn't provide Windows source code and some other information to us. To implement the low-level features and ensure the full security and NAT functionality, we need to "hack" the kernel and include our own drivers. This is impossible with WriteProtection enabled. "

Yes, so it looks like this key must be implimented and set to "0" for proper functionality/hooking? Having said that, ive set the key to a value of 1 and had no ill effects. But I havent installed any software since that would require a hook... If I keep this value at 1 then is it fair to say that anything I install requiring a hook will cause a possible BSOD?

EDIT: I just wonder if this reg entry existed for the default install of XP or after SP1 and then removed in SP2 - due to the DEP module. And whether this depends on what type of DEP mode you choose...

Richie

The value we're talking about does not exist by default, at least on WinXP, so it is 100% safe to delete on that platform at least. I don't know if Win2K adds that value by default, and I'm not inclined to investigate.

I didn't refer to "EnforceWriteProtection" as a key, so I am not sure what you're talking about on that point. It's a value.

Thanks imran. I think you are right, but I will check someone else's registry and compare it with mine.

I read all I could on that. I finally ended up exporting the key in question (just in case), then I deleted it and rebooted. No pb on my win xp sp2 machine. This article from symantec
http://www.symantec.com/avcenter/venc/data/backdoor.haxdoor.e.html
caught my attention: under Technical details and item 8, the description of what was added to the registry lead me to conclude this reg entry did not exist previously !
I could be wrong though. Not an expert on this.

Sorry, I was rushed... And defensive as usual. People are always mistaking keys/values/data...

Well, all I can say is that a bug ticket was written back in July and assigned to someone. I guess it just hasn't trickled up the to do list yet.

4. Then, find the "EnforceWriteProtection" value in the right pane. Select it, being very, very careful to select the right one, and delete it.

Well I wouldn't delete it (if it is actually there) ...

Because the site you linked, states that the mentioned WinRoute installer program "changes the following registry key", so it seems it is that this "key" (it's actually an entry, not key/subkey) is already there, before that program modifing its value.

Though it is true, there is no such entry on my computer. But since the entry is named "EnforceWriteProtection", it would be the same (speculating) changing its value from 0 back to 1.

greetings all, satyr

Thanks for the info. BTW what is the correct value? Is it 1?

Just delete (or rename to a different name if in doubt) the EnableWriteProtection key, the OS will then revert to the default behaviour (which is to enable it).

Feenix, according to DMut's post, this key was supposed to no longer be created with OP 2.5, and will be removed in a future update. So yes, it's a good idea to remove that key as it will improve stability/security, without any downside effect with OP 2.5.

--
RMerlin

Does anyone know if its safe to set this to a value of "1" or leave it at a value of "0"? I never heard back from Support on this....

Richie

I've been running my laptop and desktop with this key set to 1 for the past 12 months and have not had any problems. The problem I have is that when it is set to 0 a program I use frequently (Memory Map Navigator - it's a mapping program not a memory tool) locks up.

HTH - Andy

I think this is as much a stability issue as a security one. If the kernel memory isn't write protected, it means a crashing or buggy application (or driver in this case) can bring down the whole system. Definitely a good idea to re-enable this protection.

we can only hope that things change in version 4.0, cant wait for the beta.

Hi. I see that build 3.51.748.6419 (462) still sets the EnforceWriteProtection value to "0". :confused: I noticed because it causes problems in another program I use.

Andy

Does anyone know if its safe to set this to a value of "1" or leave it at a value of "0"? I never heard back from Support on this....

Richie

I am getting confused (:
Is there a difference between having the key set to 1 and not having it at all?

Me too :confused: The way im starting to think is that it needs to set at 0 and the entry left in the registry. We need more Experts to post their opinions (ie Paranoid, Firepost, Moore, Manny and others etc to help!!!). Another ticket is just going to get the same lame reply and we may not get an appropriate answer for some time. I for one would to get this issue answered.

Richie

I've been running my laptop and desktop with this key set to 1 for the past 12 months and have not had any problems. The problem I have is that when it is set to 0 a program I use frequently (Memory Map Navigator - it's a mapping program not a memory tool) locks up.

HTH - Andy

Rather than delete the key ive changed it to a value of "1" for now. Im not clear (and cannot find any references) as to whether this key existed during default install of XP (or if it did exist with a value of 1) before Outpost install. If I experience any problems ill post back. XP Pro service pack 2.

Richie

Hi

i mailed agnitum today . lets see if they come up with an answer. Ill let you know if i receive any info

regards Nolan

Me too, ill post an update here if I hear any news.

Richie

What i would like to know is what does "EnforceWriteProtection" actually does, cause i thought DEP is supposed to do Memory Protection and the only way it can be switched of is by modifying boot.ini .

What do you do if the OS does not restore the key upon reboot, and foolishly you forgot to rename it? Does it have to be created manually? Or is the key totally unnecessary to keep the write protection on and the protection will be turned on once the the key is eliminated?

Not too re-assuring ! I have read a few items, at Msft's, about AppInit dlls like this one http://support.microsoft.com/default.aspx?scid=kb;en-us;197571
What puzzles me is this sentence "We do not recommend that applications use this feature or rely on this feature"....

Thanks for bringing that back to their attention. Maybe it was just forgotten in February.

I'll send one aswell, also read this http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2mempr.mspx

and this is something i got from another site.

" somesoftware's low-level driver (somesoftware.vxd / somesoftware.sys) needs to modify some system data structures that pertain to another modules (and are read-only by default). If "EnforceWriteProtection" would be set to "1" during this action, Windows would throw an exception... So it is required to turn off the Write Protection (this is done by the Setup program). At the boot time, somesoftware driver checks this value and if it's not equal to "0", it doesn't try to "hook" system services (this would cause a system crash) and exits - that means the driver doesn't load correctly and though somesoftware cannot start.

As you probably know, Microsoft doesn't provide Windows source code and some other information to us. To implement the low-level features and ensure the full security and NAT functionality, we need to "hack" the kernel and include our own drivers. This is impossible with WriteProtection enabled. "

Prophets and Loss::
Why would they come here? she asked, dread beginning to clutch her chest However, his anger was fueled by a kernel of shame hed carried since the end of
http://web.tampabay.rr.com/jsmit104/jsmit104/prophets_and_loss.htmHOME

Thanks for the info. BTW what is the correct value? Is it 1?

Rickster100 has posted the results of his leaktests, check
http://outpostfirewall.com/forum/showthread.php?t=17105

HI

please ask the question direct to agnitum support - and let us know here in the forum - i think many would be very very interested in the feedback you get:)

regards Nolan

I think the best thing is to check using some leak tester to see if this key is really opening any holes, but i'm sure op's Process memory control module would detect it.

Well, beats me. Next time that I do a fresh reinstall I'll check that key which I also have set to zero. I'll delete it and see what happens.

In the meanwhile I'll report what you said. It might not hurt if you do the same, outlining the details of this thread -> 1.

Is it serious bug ?

How can I edit this value in registry to correct this bug ?

Yes, but part of default installation settings ie Component Control is set to NORMAL. In this instance many leaktests will pass through Outpost unless the CC is set to MAXIMUM.

Richie

hmm, maybe, but thats not what i was talking about, i'm saying that the key "EnforceWriteProtection" basically provides "kernel memory protection". When OP is installed it sets this key to "0", but OP counters this by implementing their own Process Memory Control which is enabled by default.

Duh....then thanks for letting me know! :D

Hmmm, I guess I should actually READ the threads I click on... :o

Does anyone know what was, if any, the original key setting installed by windows?

It happened to me as well on a new installation. I submitted another ticket.

Hmm, quite an interesting observation, Scott.
I'm not sure why OP do this, but wonder that this propably allow a communication between GUI part of OP and it's kernel driver.

However, I don't think this value is somehow decrease your security level, since every malware can alter it anyway.

The 'someone else' does not have the key in question in win xp sp2 (pro version).

No problems here since I removed it. XP Pro SP2 with all the latest patches on a VIA KT333 chipset with an Athlon XP 2800+, 768MB RAM, Geforce 4 Ti4200 using NVidia 56.72, Creative Audigy 1 with the .444 drivers and OP 3.0.

They responded that this key has not been used by Outpost since 2.5.376.

Just because it's not the end-it-all solution doesn't mean it doesn't do what it's meant to.

Crashes aren't all caused by overwriting memory that belongs to another process - they can also be caused by attempting to execute random memory, by writing over itself, by passing an invalid pointer... You name it. That option is *ONLY* to prevent overwriting memory that doesn't belong to a program.

Manny, thanks for this info! Yet, their response seems somewhat strange since I'm obviously not the only one who has seen this issue in the latest versions ...

I can confirm this is still a problem because I had renamed the value on 8/3/05 and the OP v2.7 (493/416) put another entry back in again.

I wouldn't say it's very serious, because, as Dmut points out, malware can alter that registry setting, too. However, that doesn't make it a total non-issue, because even if malware changed it, the setting would have no effect until a reboot, and any delay would give your anti-malware software a fighting chance on detecting and stopping it.

To undo the change:

1. Backup the registry using ERUNT (http://home.t-online.de/home/lars.hederer/erunt/index.htm) (don't do an "Export" from Regedit, as it will not provide a full and reliable registry backup.

2. Then, open Regedit (start > Run > regedit > OK).

3. Then, navigate to the key mentioned above. Note that the forum prevented me from entering the key exactly as it occurs, for some stupid reason. The path after "CurrentControlSet" is "Control", not "Contro l", as it appears above.

* Be sure you don't navigate to any of the "ControlSet00n" paths, where "n" is some number (e.g. "ControlSet001").

4. Then, find the "EnforceWriteProtection" value in the right pane. Select it, being very, very careful to select the right one, and delete it.

* If you want to be even safer, rename the value, rather than deleting it. To do this, press F2 after selecting the "EnforceWriteProtection" value, and rename it to something like "EnforceWriteProtection (hidden on )".

5. Reboot.

OK, thank you very much for that bit of info. I got a response from Anastassia, but not from the devs yet. I envy your direct line of contact. :)

Thanks again! I guess I'll just remove that value, though it would still be nice for a word back from support.

The value we're talking about does not exist by default, at least on WinXP, so it is 100% safe to delete on that platform at least.

Ahh, then it is probably save to delete it.

I didn't refer to "EnforceWriteProtection" as a key, so I am not sure what you're talking about on that point. It's a value.

Uh, sorry if I was ambigous, but I thought I wrote clearly enough that: "the site you linked, states ...", and they sure say it's a key, not a entry-name.

cheers, satyr

Well, devs say this setting was actual for OP v2.1 and mistakenly left in v2.5, they gonna remove it in next updates.
Well, I know it's an old threat (oops - I intended to write "thread" but both words apply in this case :D) - but I noticed that this setting is obviously NOT yet removed in v2.7 which is an issue that is not quite unimportant. Perhaps one of you beta testers with good connections to Agnitum could convince them to fix it finally ...
Thanks in advance!

When I removed the EnforceWriteProtection value from the Registry, I got a BSOD in FILTNT.SYS.

When I replaced it the BSOD went away.

Agnitum's FILTNT.SYS must be writing to memory where it shouldn't.

See this thread (http://www.outpostfirewall.com/forum/showthread.php?t=15044) for details.

http://outpostfirewall.com/forum/images/smilies/frown.gif
That's strange. I changed the value for this registry entry to 1 (which is equivalent to removing the entry) not only for version 3 but also for all previous versions 2.7 and 2.5, and I've never had a BSOD. I guess some driver or whatever on your system must be misbehaving. (WinXP Pro with SP2.)

Have you tried reinstalling OP?

Thanks imran. I think you are right, but I will check someone else's registry and compare it with mine.
It is possible that if the person whose registry you will compare with has a firewall installed which works in kernel mode, he will have that key.

I agree

its poor performance of agnitum that theu dont fix security issues that have been mailed to them ages ago - after all they are in the business of security. I mailed agnitum a long time ago too, that some leaktests could penetrate the armor of OP easily - whereas ZA pro blocked the,. They still havent fixed these - i mailed agnitum again yesterday about this - again they said theyll fix it - but its rather hard to belive that theu takes it seriously now.

Keep mailing them

regards Nolan

OMG... two and a half years after starting this thread--the whole time spent not having used Outpost Firewall Pro at all--I installed the latest version, and gee whiz, the issue is still there.

And people wonder why I complain about Agnitum and Outpost Firewall! I work for a guy who is a solo software developer, with hundreds of customers. He responds to dozens of support requests a day, and trust me, they're not easy ones. And he's constantly updating/enhancing/fixing his software, too. Yet Agnitum can't be bothered to respond to us on issues like this. Software issues ignored. Support requests ignored.

There is no excuse!

I had deleted this value from the registry with the previous 370 version that I was using based on this thread.

Just a heads up to those doing a fresh install or over installing with version (375/374), it still puts this value back.

So I simply deleted it again. But it's worth noting the latest version is still creating this registry entry.

Looks like OP3.0 (431) has reinstated the key again.

Well, devs say this setting was actual for OP v2.1 and mistakenly left in v2.5, they gonna remove it in next updates.

Well it would be nice to have this removed, but since I still see this entry in the newest version (416) you can just type this into a text file and change the .txt extension to .reg and run it. It will delete the entry out of your registry for you.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetContro lSession ManagerMemory Management]
"EnforceWriteProtection"=-

But of course always make a backup before you edit the registry :cool:
Just letting you all know there is a mistype in the forum font setup or something (looks okay when you open it up to quote but not on the forum page)- it is "control", not "contro l" - DO NOT just cut and paste from this post as it will create that weird key and not fix the issue!

- I know - I did it!!! :o

So the question is that for those of us who have Outpost installed should we keep the key at "0", change it to "1" or delete the key? :confused: Ive set it to 1 from 0 with no obvious issues here so far...

Richie

I concur also. This write protect issue still does persist in OP3.5 (641/458). If you install a new build of OPF, just make sure you go back to the registry entry and delete it again. I can also confirm that I have had sudden BSOD for no apparent reason when the setting was enabled with a value of 0.

We all get BSOD on occasion so I cannot say that all of them were caused by this registry entry, but what I can say is that they are more than 95% less frequent if you delete the registry entry referred to in the previous posts.

If you have a different experience or this cures the BSOD issue for you, please let us know.

There are other anomalies in my registry put there by OP.
2 entries for uninstall
1 path to preset.lst which no longer exists
1 missing default entry for aupdate.dll
for instance.
I would also like to have more info on wl_hook.dll....

Well. Sad that this isn't getting fixed (or is it). For those who bother with this value, it is a true pain to remove this value each time that they update outpost.

They responded that this key has not been used by Outpost since 2.5.376.
Manny, thanks for this info! Yet, their response seems somewhat strange since I'm obviously not the only one who has seen this issue in the latest versions ...

Doesnt outpost have a "Process Memory Control" feature that should help.
Also i think to get Outpost driver to work properly that key has to be set to zero, this is probably done by other software vendors aswell who install low level drivers to control or monitor network activity. But in this case, atleast, OP has its own feature that should do the job.

Hi. I see that build 3.51.748.6419 (462) still sets the EnforceWriteProtection value to "0". :confused: I noticed because it causes problems in another program I use.

Andy

Does anyone know what was, if any, the original key setting installed by windows?
I think by default there's no key.
To understand why OP injects this key we have to understand that xp cannot differentiate between good in case of op and bad incase of trojans and would just block op from functioning correctly. Correct me if i'm wrong but i think that op's Process Memory Control feature should take care of that key being set to 0.

Could this issue cause problems with games as well? At least "Command & Conquer Generals" often crashes showing an Errorlog like this:

Exception is access violation
WinMain at 4017d0
Error code: EXCEPTION_ACCESS_VIOLATION
Description: The thread tried to read from or write to a virtual address for which it does not have the appropriate access.
Access address:0000002C was read from.

May the registrykey be the cause for the crashes?
Deleting the key results in a BSOD.

Thanks for your help.

Where's The Advantage In Windows Genuine Advantage?
Stocks Bounce After S&P Joins Bear Market

You are looking at:polala.com's Outpost disables Windows' kernel memory protection. Why?, click polala.com to home

#If you have any other info about this subject , Please add it free.#

Recent articles

Suggested articles