Memory Protection

I work at a small software company. Sometimes I deal with security issues. One question comes to mind: Is there another program that protects "physical memory" besides ProcessGuard3 ?

 

The latest version of System Safety Monitor (1.9.5) also offers this feature. Like PG, it is also in beta so run it on a trial machine first.

 

You certainly speak of some special plugin, right ? I see no option to that type of protection.

 

I'm still not even sure exactly what PG restricts in terms of Physical Memory Access, it will probably be easier to determine what programs are similar once that is understood. We may have to wait for the help file for that.

 

SSM does not allow you to set protection options like Process Guard - instead it prompts on every event giving you the opportunity to allow or block it on a case-by-case basis. PG allows settings on an application basis only. For example you could in SSM allow application X to install driver Y - in PG you would have to allow application X to install any driver (which causes problems with settings for services.exe).

See the System Safety Monitor 1.9.5 closed beta (testers needed) thread for more details on the improvements added.

 

Prevx Home, Overflow Guard, BufferShield and Windows XP Service Pack 2 all have memory protection. However, software based protection is not as good as hardware based protection which Windows XP SP2 can implement (if your hardware supports this). Most of the programs I mentioned have freeware versions.

 

I think PG does more than just protect against buffer overflows.

 

Some care needs to be taken over the term "memory protection" because these programs do different things. Process Guard and SSM offer the ability to block access to \Device\PhysicalMemory (see the 'NT's "\dev\kmem"' section of Systems Internals, Tips and Trivia for more details). This does not cover buffer overflows.

Prevx, Overflow Guard (no longer free, only a 15-day trial is available) and BufferShield attempt to prevent buffer overflows while XP SP2's hardware-based Data Execution Protection should (if implemented properly - it relies on well-behaved applications here) prevent data from being executed as code (which can also limit buffer overflows).

 

Yep, have a read of Jason's replies on software Buffer Overflow protection in this thread.

Here is one of the Phrack articles that Jason mentioned in post #3 detailing methods to get around many overflow protection programs.

Regards,
Jade.

 

My question was aimed at the malicious software that hide themselves by writing directly over SDT tables. PG3's physical memory protection prevent this. What other software can do this too?
All the mentioned can't. Using the exploit of PG2 , I can break all those software (tested), including SSM.

As for buffer overrun protection (or DES handling), it was not in my idea, when I posed this thread, but nice followup, might be my next point of interest.

 

Sorry KoreanBoy, got a bit off track .

The only other software I can think of that has a way to protect physical memory is IPD (Integrity Protection Driver) from Pedestal Software - not sure if it's available anymore. But IPD doesn't allow you to specify which programs can write to it. Process Guard is the only program out there that allows users to do this in a secure way.

Anyway, wait for a reply from one of the DCS lads .


Regards,
Jade.

 

Security Focus still has it hosted:
http://www.securityfocus.com/tools/1579/scoreit

A vulnerability was apparently found in it in August, wonder if that has anything to do with why it's down:
http://www.securitytracker.com/alerts/2004/Aug/1010965.html

 

And this does refer to SSM 1.9.5, the version referenced in the link specified above? It explicitly says there "Added Device/PhysicalMemory protection" and AFAIU that is the way that the mentioned exploit takes to gain access to the SDT. Also, do you have any hint on malware already making use of that technique? Up to know I understood it's always been a theoretical vulnerability without in-the-wild threat.

Finally, have you by any chance tested that the exploit does work no longer against PGv3. I have tested it with good results, but it would be good to hear a second opinion.

Andreas

 

I've tried it also and SSM does not appear to block it - even if running in service mode. I've emailed Divine Glitch and sent logs so hopefully that should be addressed.

PG 3 does block it - my only concern is if you allow it to access physical memory, it then disables PG but PG does not subsequently report this in any way. PG doing a periodic check on the system hooks to ensure its protection was still active would seem appropriate here.

 

Indeed there was a problem introduced while debugging -- access to \Device\PhysicalMemory was not handled.
Currently the version (195b2++) located on official site should handle this

 

where can we download this beta2 ?
on the site http://maxcomputing.narod.ru/ssme.html?lang=en , all available is beta1

 

There is a separate download location for this update - but since this is described as a "very preliminary release" I think it best left to Divine Glitch to either update the main site when he's happy with it, or to provide details of the download link himself.

 

Just to update this - the current version of SSM downloadable from Max Computing (1.9.5 beta 3) does now prompt on access to physical memory and can block the SDTRestore test. Even if you allow SDTRestore to run (in both SSM and PG), it will only disable PG, not SSM (this may be due to SDTRestore only specifically targetting PG's hooks though).

 

What version of Process Guard did you try SDTRestore on? Because from any Process Guard 3 Public Beta onwards, it should be completely fixed . See this thread.

And no, SDTRestore does not specifically target Process Guard. It applies to virtually all other driver-based security software that hook native API's in kernel-space in order to protect processes from being terminated etc.


Regards,
Jade.

 

I get this when I run SDTrestore (0.2), and PG3 (beta 2) continues to function as advertised.

Nick

 

Just to expand on my previous post "Even if you allow SDTRestore to run (in both SSM and PG)" - this meant allowing SDTRestore Physical Memory access in both SSM and PG.

 

Hi Paranoid200, If you allow it to run and give it the correct allows then it will, thought the idea was to blockit?

Yes, Process Guard will allow it to run if you choose to do so.
Cheers. Pilli

 

The reason for allowing SDTRestore in this case was to compare its effect between PG and SSM. PG was disabled without giving any further indication (aside from the subsequent lack of execution prompts) while SSM seemed unaffected. How well this translates into real-life resilience against malware employing this technique I cannot say though.

While it is true that PG requires you to allow SDTRestore to run and to allow it physical memory access for this to happen, I would point out that some PG users need to allow Internet Explorer physical memory access - given that this is the security equivalent of the Grand Canyon I would suggest that an SDT-type exploit bundled within an ActiveX control may be able to take PG offline on some people's systems (yes, disabling ActiveX and not using IE are sensible steps to avoid this - but not everyone is giong to follow these).

It would, in my view, be a worthwhile feature for PG to do a periodic check on its hooks and issue a warning if it detected anything wrong.

 

Another one for the wish list

Yes, regarding your other statements, unfortunately most users are all to unaware of the risks and would probably never find a program such as Process Guard anyway.

Pilli

 

Memory protection (\\Device\PhysicalMemory NOT other types of protection) can be a little confusing for some. The main point to remember is that ProcessGuard works, this is an attack vector when you run unknown code that tries to access physical memory - ProcessGuard has the ability to block it from happening and there is NO way for a malware to get around the protection.

If you ALLOW it access there's not really much point saying OK well why doesn't it protect me anymore, you just told it you dont WANT to be protected. The attack method is to do something, we block it, game over. You allow it and... well you just allowed it!

This is along the same line as installing drivers: once you allow kernel mode code to execute there isn't much point in arguing about what protection should remain. ProcessGuard is there to protect you ! MAKE it protect you. Kernel mode code can do anything it wants, period. Likewise, access to physical memory will mean a program can do ANYTHING. The whole point is to prevent it from happening in the first place, nothing more.

On chip DEP (data execution protection) is nothing to do with access to physical memory. It is about programs setting areas of memory as executable when they shouldn't. AMD64 CPU's with Windows XP SP2 protect against this by making sure these areas of memory cant have something execute in them. This is very powerful protection against buffer overflow attacks. Hardware will eventually be the only true secure way to handle that, which is why its here on those AMD CPU's