DEP + Sandboxie

Discussion in 'sandboxing & virtualization' started by luciddream, Feb 22, 2013.

Thread Status:
Not open for further replies.
  1. luciddream

    luciddream Registered Member

    Joined:
    Mar 22, 2007
    Posts:
    2,497
    Last week I think I may have had an intrusion attempt, or targeted malware attack through Pidgin Messenger. It may have just been some conflict, as they were in the process of trying to set up their Pidgin and maybe changing random settings while we were connected that did something weird. But I don't know them well either, and what I do know, they're kinda a jerk. So I don't trust them. And I've never seen Pidgin do anything like this before.

    If so, it was the first time in like 7 years I've had something like this happen. Fortunately I was running Pidgin in a restricted sandbox, and well hardened via outbound FW rules & D+ too. All that happened is my box froze for a few seconds. Then DEP kicked in and terminated Pidgin. Then I got my CCleaner prompt to delete the sandbox, and did so. And that was that.

    And if so, great timing too. I just updated the "Off-the-record messaging" plugin to version 4.0.0.1 And noticed it was hardened by adding DEP & ASLR to it. And it said in the notes for it something like: "We hope that no such vulnerability exists, but if so now it would just terminate the program instead of your entire system", or something. LOL... perhaps this person found such a vulnerability indeed? And adding DEP & ASLR to that plugin was a most welcome measure? Heck, maybe my name even got picked out of a hat for them to test it out on?

    But I was wondering, my situation aside... is it normal for DEP & SBIE to interact in this fashion to ward off attempted attacks? It seems logical that it would be. As DEP is designed to just crash/terminate a program when it becomes unresponsive instead of your entire system. And sandboxie will keep the attack isolated inside that app, which could cause it to become unresponsive. So I would think the two would work together like this quite often. But I don't have any test machine that I play around with stuff on, so I wouldn't know. This was my 1'st/only honest to goodness attempt against me since I've been on XP... "if" it indeed was one at all. And it happened to unfold that way. But logic leads me to believe this tandem kicking into action could be quite common.
     
    Last edited: Feb 22, 2013
  2. CrusherW9

    CrusherW9 Registered Member

    Joined:
    Dec 27, 2012
    Posts:
    516
    Location:
    United States
    I have ran the exploits from this site (IT IS A "HACK TOOL") in a sandboxed Firefox and the behavior was somewhat similar. Provided I played dumb and hit yes at the prompts that showed up, it crashes Firefox and a simple empty of the sandbox fixes it. I don't have EMET installed but like I said, the behavior seemed similar. I don't know too much about attacks like these but it may be something you could use to verify that this is the same thing you have experienced and if it is normal. The odd thing is, now I can't get it to crash FF.
     
  3. luciddream

    luciddream Registered Member

    Joined:
    Mar 22, 2007
    Posts:
    2,497
    Yeah, I think DEP is by far the most useful mitigation technique in the real world. And having it "always on", plus a restricted sandbox seems darn near impossible to circumvent. The other mitigations, I think you'd really have to be lax in other areas or testing exploits intentionally to have them spring into action. Not to mention the others are heavier, and much more likely to break things, whereas DEP seems benign for the most part & light. I notice no increase in footprint and no conflicts having it always on... when deploying it through "System" in the Control Panel. But with EMET I've run into so many conflicts, I just don't even put it on other people's boxes anymore because I know they'll be calling me back.

    And if I had had DEP only in it's default, opt in state, it wouldn't have protected Pidgin. I'm glad I found a tweak to turn it always on in XP. And would recommend to everyone to have it in that state at least, if they're not going to use EMET. Or opt out, and list specific apps you've found it doesn't play well with.

    And now that I've seen how beneficial DEP can be along with SBIE I'd like to have the hardware version. Maybe I can find a box on Craigslist for next to nothing with a CPU that supports hardware DEP. With 4 GB of RAM too, to take EMET into stride better than it would on my box. Cuz once the patches for XP stop I can see the other mit. techs making me sleep better at night, because I have no desire to move away from XP anytime soon. Now that everyone has 64-bit Win7/8 boxes with Core i5-7 CPU's and 8+ gigs of RAM, I could probably find such a box for a stick of gum. And could get several more good years out of it. Hopefully by then Windows will design an OS that goes back to the basics, is less convoluted, so I don't have to migrate to MAC.
     
    Last edited: Feb 22, 2013
  4. CrusherW9

    CrusherW9 Registered Member

    Joined:
    Dec 27, 2012
    Posts:
    516
    Location:
    United States
    Did you have start/run restrictions enabled in your sandbox?
     
  5. luciddream

    luciddream Registered Member

    Joined:
    Mar 22, 2007
    Posts:
    2,497
    Yeah... Pidgin is the only thing allowed start/run & internet access in them. Also, I'm gonna attach my D+ settings for Pidgin (1'st), and then FF, to give everyone an idea of how anal retentive I am about hardening my apps. I'd imagine these settings would make it very difficult for an exploit to succeed also. I feel a Paranoid, strongly deployed HIPS can greatly lessen the need for these mitigation techniques. Especially the "Interprocess Memory Access" setting. I have the same "Protection Settings" for both FF & Pidgin so I'm only posting 1 screenshot of that. Oh, and you cant see it but I have 3 things whitelisted in Firefox to run as executable (FF, p-c, VTHC). And 1 for Pidgin (SBIE RPC).
     

    Attached Files:

    Last edited: Feb 23, 2013
  6. luciddream

    luciddream Registered Member

    Joined:
    Mar 22, 2007
    Posts:
    2,497
    Those settings pretty much echo how I handle everything on my box. If it's not necessary, and/or useful, I just don't allow it. It not only makes my box more secure, but more responsive & stable too. Same with my SBIE restrictions. Though I have 3 different ones for Firefox. A "loose" one where I allow bookmarks, VT Hash Check, Flash/plugin-container, and recovery (to a sandboxed, dedicated partition called "Downloads" only). A medium one where I allow only access to bookmarks & Flash/p-c, which I use the vast majority of the time. And a "secure" one where I allow nothing but Firefox start/run & internet access, which I use if I'm purchasing something or doing something I'd otherwise consider sensitive (I don't do online banking).

    Along with a default deny SRP... having no Java, PDF, or .NET FW on my box. 8 (non vulnerable) services running. And GP edits that basically make my secondary Admin acct. a pseudo-LUA... an exploit would have to get up pretty early in the morning. And since both .NET FW & EMET eat up a good amount of footprint on my box I just don't consider it worth the hit vs. the likelihood of me needing it. It's just like the decision I made regarding keeping a real-time AV around. I try to maintain a balance of keeping my box as secure as I can while still keeping it functional, convenient & light. In the past I sacrificed too much footprint for security that was overkill. I also stopped running LUA also because I felt it sacrificed too much convenience. I feel that through GP edits among other things I have an Admin acct. now that strikes a perfect balance of security & usability. It was to the point where I felt like I was blocking myself from using my computer, lol. That's going too far.

    And here's another screenshot that I personally think portrays well, at a glance, what I aim to achieve in terms of attack surface. And IMO it should be the aim of everyone (when at idle):

    And also:
     

    Attached Files:

    • cmd.jpg
      cmd.jpg
      File size:
      44.8 KB
      Views:
      301
    • tm.jpg
      tm.jpg
      File size:
      83.5 KB
      Views:
      297
    Last edited: Feb 23, 2013
  7. DR_LaRRY_PEpPeR

    DR_LaRRY_PEpPeR Registered Member

    Joined:
    Oct 11, 2012
    Posts:
    141
    Location:
    St. Louis area
    I don't think DEP really does that much these days... As exploits have gotten more advanced, etc., I don't think DEP does much to hinder them. And DEP is a lot more effective with ASLR, which we don't have in XP. :'( ASLR+DEP together are stronger than the sum of each on their own.

    There is no overhead or footprint when implemented on the CPU/hardware (the only way). Only if memory without the execute flag tries to be executed does that trigger an exception which Windows (or program?) handles. e.g. terminates.



    Yeah, even though I don't think DEP has hardly any benefit, yet I can't have it AlwaysOn because I need exceptions OptOut (which also does other things besides explicitly opted out applications). So mostly just because I was messing around with stuff (don't have much experience with Windows coding), I made a simple DLL that makes DEP basically act as if it's AlwaysOn in Windows XP (Vista SP1+/7+ don't really need it), and permanently enabled on processes that haven't been opted out (explicitly; or by Windows, implicitly). I'll post about it here soon. :) Otherwise with standard OptOut setting, DEP can be turned off for a process if some exploit code manages to start.


    Sorry, but if you don't have hardware/CPU DEP support, you don't have any real DEP at all. That "basic Windows software 'DEP' techniques" you may have seen mentioned, isn't DEP, but rather just "SafeSEH." I think that means Windows creates a list of which Structured Exception Handler functions are valid in the program when it starts, and doesn't let an exploit replace and Exception Handler at the "end of the chain," or... something. :eek: But other links in the SEH chain can still be broken by exploits, blah, blah, which is what EMET's SEHOP protects against (not sure if that's different than Win 7's system SEHOP).

    But as far as true DEP that honors the EXECUTE memory flags with dynamic allocations, etc.? Only works with hardware support. Windows is not enforcing that via "software," which would slow things down.

    I think a demo program I found that you can see proves this... I might check later if I want to restart this system (I guess I can), disable hardware DEP support in BIOS, and set AlwaysOn DEP in boot.ini.
     
  8. luciddream

    luciddream Registered Member

    Joined:
    Mar 22, 2007
    Posts:
    2,497
    Whatever it was... it stopped that exploit dead in it's tracks. So it must've done something right. Or maybe SBIE did, or my D+, or SRP, or any number of the 1001 hardening tweaks I've done to this thing... then DEP merely terminated the program because it became unresponsive as a result. But in any event I'd say I'm covered.

    But I've decided I'm adding all those fancy mitigations to XP just the same. ASLR can be made available on XP via WehnTrust, and the rest through NEMET. And I can get it without having to add the bloated, vulnerability ridden, attack surface that is .NET Framework. Having all of those mitigations on an OS with an attack surface the size of a flea = the best of both worlds.
     
    Last edited: Feb 23, 2013
  9. DR_LaRRY_PEpPeR

    DR_LaRRY_PEpPeR Registered Member

    Joined:
    Oct 11, 2012
    Posts:
    141
    Location:
    St. Louis area
    OK, the program I found when researching DEP bypasses after creating my "AlwaysOn"/permanent DLL for OptOut is BufferShield's DEP Test. I guess it's safe/legit, but I ran it in Sandboxie...

    I didn't realize it says right there on the main screen when you run the program, it will fail with software "DEP." It checks 5 things, and all simulated exploits succeed instantly (so the tests fail) with OptOut and, as it says, when I set AlwaysOn after disabling hardware DEP. Hardware DEP with OptOut+my simple DLL, all exploits fail with DEP (takes a few seconds while trying I guess) and tests all say "Protected" (just like AlwaysOn would with hardware DEP).
     
Loading...
Thread Status:
Not open for further replies.