Does leaving the other two fields blank (Module & API) leave you open for vulnerability though?
We have also implemented Patch Level 4 and are experiencing the same issue. We are currently tracking all of the reported BOP alerts and have found that a majority of them are AcroRd32.exe & iexplore.exe related. I'm just hesitant to globally exclude these two processes since they are used by many exploits.
Guidance on this would be appreciated.
As far I am aware McAfee will release a fix for that, so I reckon to open a case and they will give you more info. Be aware that
Old software like office 2000 or Office 2003 is not supported for DEP and the only way to get rid of the issue is creating and exclusion. If you check in kc mcafee.com for Vse p4 bof violation you will get more info.
We discovered a similar issue. McAfee released an SNS Notice on March 7th highlighting this issue and have created a KB here https://kc.mcafee.com/corporate/index?page=content&id=KB81308
The above KB explains why this happens and some solutions and work arounds.
Thanks for the response Rich. I have seen the KB article. My concern lies in giving any process a sort of "free pass" if you have the ability to add module & API. It's a balancing act for sure. Vast number of modules, tons of API's, exclusion list could be potentially limitless vs. the risk of allowing any process named iexplore or acrord32 (hackers favorites). We've not seen the same API flagged by BOP twice (if I'm understanding the log entries correctly). Disabling BOP is not an option in our enterprise.
C:\Program Files\InternetExplorer\iexplore.exe:NTDLL.KiUserExceptionDispatcher::6d4ac228 BO:Image BO:Writable
D:\Program Files\MicrosoftOffice\OFFICE11\OUTLOOK.EXE:NTDLL.KiUserExceptionDispatcher::73 BO:Memory
From that info what do I need to put in the 3 boxes for the exclusions(process, module and API)?
I guess the process is iexplore.exe & OUTLOOK.EXE :-) would KiUserExceptionDispatcher be the module and 6d4ac228 & 73 be the API?
We're having iexplore.exe (and explorer.exe) issues, too. I was wondering the same thing about the "module" and "api" settings.
Can someone confirm that DeanBaker is correct in his assumption as to what we should be entering in these exclusion setting fields?
I've had an issue with one of our users where BOP was blocking them when trying to import scanned documents into one of our data systems. This was solved after adding the exception for svchost.exe on their machine by policy as described below.
20/06/2014 09:33:46 Blocked by Buffer Overflow Protection NT AUTHORITY\LOCAL SERVICE C:\Windows\system32\svchost.exe:NTDLL.KiUserExceptionDispatcher::74736552 BO:Stack
Using the info above from the BufferOverFlowLog I added NTDLL.KiUserExceptionDispatcher to the module field and then added the 74736552 to the api field. I noticed after saving the policy though that this information was corrected by EPO which added NTDLL as the module and KiUserExceptionDispatcher was added to the API field removing the numerical value I'd added.
It appears there is some kind of error checking when entering BOP exceptions and the logs can be interpreted as NT AUTHORITY\LOCAL SERVICE process:module.api (please correct me though if this is wrong?) I don't know how secure this is but it must be better than excluding the entire process.