Software Restriction Policy vs Antiexecutable

I believe that lucas1985 may be correct that this is possible. It would be very interesting to find out if SRP blocks the execution of the executable code in the file c:\index.tmp in this example. If not, then this is a weakness in SRP.

 

this always confused me. how do you spoof an executable? it can't be just renaming it, for example : atfcleaner.exe. if i rename it to atfcleaner.gif , double clicking on the atfcleaner.gif opens up my picture viewer and displays jibberish. if i named it atfcleaner.txt, notepad opens with funky symbols in it. if i rename it atfcleaner.tmp, nothing happens. a window pops up telling me to select a program to open the file.

so "spoofing" can't be a simple rename, because it won't even run. does anyone have a non-destructive spoofed executable they can PM me? i'll test it in LUA with SRP enabled and see what happens.

 

Now I know the difference between AE and SRP : AE is simplicity and SRP is the opposite to say it civilized.
My advice for SRP starters : have a good rollback system, you will need it often.

 

Serious bug in SRP as I found out the hard way past few days. Using XP64, I implemented LUA+SRP+SuRun, the problem is the moment I would enable SRP my user account desktop would go totally blank with just a blank screen with no taskbar. Even after deleting the account and creating a new one wouldn't fix the issue, of course the admin account would work fine meanwhile but then that defeats the purpose of this whole issue so for now, its LUA and the excellent SuRun for me. I had to format and reinstall couple of times over the weekend but the problem persisted with consistency.

 

Remarkable words from someone who, obviously, hasn't seriously tried LUA+SRP at all...

 

Arup, I have applied SRP (with LUA and SuRun) to a couple of computers and never had this problem. Calling your problem a "serious bug in SRP" is a bold statement, IMHO, without telling us how your spcific configuration looks like and how you exactly implemented SRP.

 

Not really.

Let me provide a partial quote from a post in an earlier thread and, yes, I believe this quote and the following ones are entirely in context:

or here

or here

In other words, why let solid technical facts and/or internal consistency inhibit voicing a random opinion founded on little more than casual impression.

Blue

 

The description provided by Arup sounds like misconfigured SRP.

Blue

 

My main "issue" with SRP is it works by extensions.

tlu, do you know if there can be an executable that executes because it has an extension not in SRP? I mean, you have that list of extensions to select.
Indeed you can add manually more extensions, but my doubt is how many executable extensions can there be, they depend on what, is the default list in SRP enough, do all executables need an extension, etc.

Is there any link that explains this?

 

tlu,
Looks like SRP is a personal issue with you. My statement comes after three formats of XP64 and some research on net. Seems like blank screen with user account is a common MS XP problem as Google reveals. Bear in mind I used SRP on XP64 and not XP32 which brings in some added parameters like a x86 Program files folder as well as WoW for running x32 programs. I implemented SRP exactly as suggested by this http://www.mechbgon.com/srp/ and followed the procedures described for x64 XP. If there is anything else that I should do, please advise, I am all ears.

 

Hm, Windows tells us that the extensions listed in SRP define executable code and are added to standard types "like, e.g., EXE, DLL and VBS". I don't know if there is a comprehensive list of these standard extensions. Well, there probably is one but I'd have to search for it. Sorry!

 

Not so much like for other members here shouting "HIPS, HIPS, hurrah!" all the time ...
Seriously: It's not a personal issue, I've only said that I implemented it on various systems (XP and Vista) without any problems. And it seems that I'm not the only one.

So it might be an x64 issue, indeed. But since I've never tried that version (only x32 both for XP and Vista) I really don't know.

 

here it is :
http://technet2.microsoft.com/windowsserver/en/library/d24bc8c8-27cc-47ba-9b02-78d9d801e9371033.mspx

ps anyone find an example of a non destructive spoofed exe that i can test? hell even if it's destructive PM me a link to it, i'll try it inside sandboxie in my LUA with SRP enabled.

 

@All: Quite frankly, I've lost track of all the attempts in this thread to overcome SRP. Thus, to summarize - can anybody confirm that under the following conditions:

• SRP as defined on http://www.mechbgon.com/srp/
• a limited user account (the above SRP obviously doesn't make any sense if you work with admin rights)
• the default Windows file/folder permissions (see step 2 in this post)

... malware (or apps defined as malware for testing purposes) was able to break through? This might give us a hint if there are really any holes that have to be closed with other measures.

 

zopzop, thanks for this link! And the standard program file types are also mentioned:

• Windows operating system executable files (.exe, .com, .dll)
• Windows scripting files (when processed by Windows Script Host, such as .vbs, and .wsh files)
• Command batch files (when processed by Windows CMD, such as .bat, .cmd)
• Installation packages when processed by Windows Installer (.msi)

 

I have sent many links to remote code execution exploits involving binary executables to SpikeyB who uses SRP, so we could compare. All of the exploits were blocked.

Another test involved launching from a VBS script. SpikeyB has the script engines blocked with a rule, so that failed.

Those who are set up to test -- watch sites like sans.org and others which post live links to malware. The only way to know if a vulnerability exists is to test.

----
rich

 

I'm not trying to overcome SRP. I'm mainly trying to understand how this works.

It seems very hard to get a final answer on executable extensions, at least for me.
Even the link from zopzop, a very good one, mentions "default" (I admit i didn't read it yet, i'm going to next). So how would Windows accept more extensions? Are they referring to scripting files used by 3rd party programs? That's not what i'm looking for, i'm looking for "standalone", binary files. Is that static, and scripts are the moving target, as the user installs programs?

Until i understand this and something more, indeed i would prefer a program that hooks the very mechanism the OS uses to launch programs, and doesn't rely on extensions (if that's true for all i don't know). Seems a clean approach, as opposed to extensions control.
But i'm not trying to debate this right now, i just want to understand the extension business.

 

Thanks for the link.

Note this:

The latest Safari vulnerability (PoC) involves a .dll.

Revisiting the Safari Vulnerability on Windows
http://blog.washingtonpost.com/securityfix/2008/06/revisiting_the_safari_vulnerab_1.html

Those with Safari can test the link to the PoC given in the article.

In this case, of course, execution of the .dll is harmless. A real exploit attempting to modify something on the computer would be a better test of SRP.

Last week I downloaded/installed Safari to test the exploit to see how it works:

http://www.urs2.net/rsj/computing/tests/safari/


----
rich

 

This is true when using file associations in Windows (double-clicking). But see here for an example of the file executing from a command prompt:

http://www.dslreports.com/forum/remark,13689141

Now, for a different twist, scroll down in the same thread to the post by WayneDCS.

I have not been able to find a real executable image file exploit.


----
rich

 

Ah, trying that experiment answered my question, i think. SRP does not work by extensions, for executables. It works by extensions for interpreted programs (is this right?), or scripts.
I tried with procexp.gif in cmd, and it ran. With SRP, it doesn't run. .gif isn't mentioned anywhere.
Is my conclusion correct?

 

From zopzop's link:

This completes, for now, my doubts on how SRP works.
I can finally put it to rest.

Thank you all

 

Not with SRP. I have personally seen an admin account compromised on a system running under LUA, default permissions, fully updated software, IE, WF and a few applications. It's easier than some might think.

But no, not with LUA/SRP (in the configuration suggested here by tlu).

 

It sounds correct - can you post what turns up in your event log.

In a test earlier in this thread, I sent the spoofed .gif exploit to SpikeyB (who uses SRP) and it didn't run.

I tested AE for remote code execution using an AutoRun.inf and a .bat file on my USB drive.
I renamed astroexp.exe to astroexp.gif:

Autorun.inf file

Code:

[autorun]

shellexecute="start.bat"

start.bat file

Code:

start astroexp.gif

PAUSE

With AE disabled, the program happily executes:


________________________________________________________

With AE enabled, execution is blocked:


________________________________________________________

Unless proven otherwise, both SRP and AE take care of executables when renamed to another extension.


----
rich

 

Event ID 865

Indeed. We're left with executables that depends on an interpreter (again, is this correct? i mean ActiveX and Java..) and scripts.

 

Thanks, Pedro.

About other executables: SpikeyB has a rule to block script engines, so the malicious exploits we've tested (AE with me) have failed:

With his SRP rule the script file fails to run.

With AE the script file runs but fails to launch the executable.


----
rich