Sign in to follow this  
cutting_edgetech

OA's Physical Memory Access HIPS component question?

Recommended Posts

I'm using Windows 7X64 Ultimate, and I configured OA's physical Memory access HIPS component to prompt me when ever a web application attempts physical memory access. I did this for Firefox, Opera, IE, java, Adobe reader, Adobe Flash, Windows Media Player, VLC Player, Jitsi Messenger, etc.. It has been 2 days now, and OA has never prompted me for any action to do with physical memory access. Does OA physical memory access component work for 64bit machines? Also, are there any other OA HIPS components that do not work on 64bit machines?

 

I read the link you posted. So reading the physical memory is not the same as applications reading, and writing to the memory of other applications? I still need some examples of when OA memory guard would alert me to possible malicious behavior to clear on exactly what OA memory guard can do.  I read the page you linked, and it leads me to believe that OA does not prevent applications from reading/writing to the memory of other applications. I just want to make sure that is what you are telling me.

Share this post


Link to post
Share on other sites

Well, developers don't always code with security in mind. I know you know that as good as anyone. Firefox does read the memory of explorer.exe, and I thought maybe OA would alert me when applications attempt to read/write to the memory of other applications. So are you saying that the memory guard works for 64bit machines? Can the HIPS memory component keep applications from reading, and writing to the memory of other applications? So far it appears that OA memory guard does not do this. When would the memory guard component alert me to possible malicious behavior? It would probably be easiest if you gave me a few examples when memory guard would alert me to a violation of the memory guard policy. I read the link you gave me. So basically you want me to understand that reading, and writing to the memory of other applications is a completely different concept than reading the physical memory?

Share this post


Link to post
Share on other sites

In general Online Armor does prevent applications from writing into other processes. Preventing reads however is not always possible and will break a ton of applications, which is why Online Armor does not attempt it for most processes. This is largely due to the fact that a lot of APIs actually do read the memory of foreign processes without the developer expecting it. For example the APIs to display a tray icon in your system tray read memory of the Explorer process.

Memory protection is functional on x64 as well as x86.

Share this post


Link to post
Share on other sites

Why would you expect any of those processes to cause a message from the HIPS? There is no reason why any of them would access the PhysicalMemory object.

I was trying to compare OA's memory protection to that of AppGuards at the time I opened this thread. There are a few members at Wilders that are saying all HIPS offer the same memory protection that AppGuard does. I now know that OA's memory protection is different than that of AG's. You did make a very good point though in answering my question. Those applications should not be accessing the physical memory at all. Web facing apps are the most likely to be used by exploits to gain access to the physical memory. Web facing apps should not be allowed physical memory access, but OA was allowing most of them physical memory access with it's default settings.  I changed the settings for all of them to notify me if they attempt physical memory access. Thank you for your help!

Share this post


Link to post
Share on other sites

Ok, thank you! I will.  Is controling remote code, and remote data modification an effective means for mitigating many exploits? Will this technique do anything to stop exploits that only attack the memory, and do not use a payload? Also, will Adobe reader, and Adobe Flash need remote code, and remote data modification in order to update? I was thinking maybe I will have to give them this permission on-demand when they are updating. Thank you so much for your help!

Share this post


Link to post
Share on other sites

Those permissions will do nothing when it comes to preventing exploits. The only effective way to prevent exploits is to not use vulnerable software versions. Adobe Reader and Flash may need those rights for their sandbox. So you may want to set up rules that allow them to inject code into their own processes, but not others.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.