A new EMET version?

Discussion in 'other anti-malware software' started by luciddream, Mar 23, 2013.

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

    luciddream Registered Member

    Joined:
    Mar 22, 2007
    Posts:
    2,545
    I remember hearing a rumor about one in another thread I posted about NEMET. Does anyone have any information about this? Like when is it going to be? I haven't added .NET FW & EMET to my "new"/used computer yet. If this new version of EMET is going to come soon I'd rather just wait for it instead of installing 3.5 now and having to remove it and install the new one shortly after.

    Thanks. I don't see anything about it from searching. Also, any info. about the new version, like what it will consist of. Just a final release of 3.5?... or is there new stuff under the hood?
     
  2. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    I wouldn't hold your breath. It'll very likely just be 3.5 but marked 'stable', maybe with new XML.

    Three's no way to predict though, it could include way more. But it's months in between releases, so just go for 3.5 IMO.
     
  3. luciddream

    luciddream Registered Member

    Joined:
    Mar 22, 2007
    Posts:
    2,545
    Well the last release (3.5 Tech Preview) was back on 7/25/12 now. The previous version (3), just 2 months prior on 5/15/12. And the one prior to that (2.1) on 5/18/11. So it's looking like a new final release about every year, with a beta coming shortly after a final release.

    So I'd actually expect a final release to come soon, within the next month or two based on that cycle. I think I'll just wait for it since I plan on removing .NET FW after installing EMET.

    I trust in Hardware DEP + SBIE to keep me safe until then...

    This Hardware DEP (Always On) is touchy btw... it was stopping my audio driver from installing properly, so I had to temporarily disable it. I know the driver was clean, but I guess it was doing something DEP didn't like.
     
  4. JimboW

    JimboW Registered Member

    Joined:
    Oct 22, 2010
    Posts:
    280
    We should see something soon.
    -https://twitter.com/jness/status/302128486804500481-
     
  5. Trespasser

    Trespasser Registered Member

    Joined:
    Mar 1, 2005
    Posts:
    1,204
    Location:
    Virginia - Appalachian Mtns
    Hope the next release, which I hope arrives soon, includes support for Win 8 without installing NF 3.0 and 3.5 beforehand.

    I, at present, have DEP turned on plus I found a registry tweak that enables SEHOP (disabled by default in Win 8 Desktops but enabled for Servers), and ASLR is on by default in WIn 8, but still it would be nice to have a "reasonable" EMET version available.

    Later...
     
  6. luciddream

    luciddream Registered Member

    Joined:
    Mar 22, 2007
    Posts:
    2,545
    Heck, I'm hoping the next final/stable build doesn't require .NET FW at all for that matter... but I won't hold my breath on that. But I did come to find you can uninstall .NET FW afterward... all of it, all the way back to 1.1, and EMET 3.5 continued to function just fine.

    Just so long as you keep the AppPatch folder behind and a few registry keys... which aren't removed when you uninstall the product(s). Even after using CCleaner's registry cleaner, the stuff I needed remained. A good sign of a good registry cleaner... it doesn't remove too much.

    I went in there manually too and removed most of the junk and just left behind the stuff I needed to maintain EMET functionality. So I have EMET 3.5 up and running on that box without any of the .NET FW attack surface, which was my goal. But I'd be happier yet to not have to install it in the first place.

    Maybe LarryPepper can get to work on his EMET-like tool he was talking about. Sounded uber promising... I'd be all over it.
     
  7. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    On an XP system I'd be really pushing to install EMET ASAP. You're missing a number of mitigation techniques, and EMET will at the very least prevent legacy exploits via SEHOP/EAF.

    I wouldn't rely on Sandboxie or any other sandbox on XP though, but there are other threads about this information.

    My advice is to get EMET on the system.
     
  8. DR_LaRRY_PEpPeR

    DR_LaRRY_PEpPeR Registered Member

    Joined:
    Oct 11, 2012
    Posts:
    141
    Location:
    St. Louis area
    Sorry I didn't reply back with the info in your other thread lucid. :doubt: EMET forum thread with info, including the tweet link Jimbo posted. The video interview doesn't have that much in it (that people here probably don't already know about EMET), and where he talks about (or, just references) new stuff in the next version is pretty close to the end... I'm hoping we'll see it within a couple/few weeks, since it's not here in "March" so far!

    BTW, DEP appears to be broken in EMET 3.5. (In case one is trying to force it on with OptIn, or make it Permanent with OptOut.)




    Why, even with keeping XP updated...? Which threads, that don't apply to fixed kernel exploits?

    But that's why it's important to at least keep up with updates, especially elevation of privilege type ones.
     
  9. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    All of those "fixed kernel exploits" were at one point unfixed kernel exploits. The exploits aren't important - it's the principal, the idea around them. There's a reason they don't bother finding a new 0day for the research, it makes just as much sense to use an old one that we've already seen.

    Staying patched is fine, but with a kernel that:

    1) Has a lot of components like graphics drivers that were later removed in Vista/7/8

    2) Doesn't have security mitigations implemented in Vista/7/8

    0days are unlikely to be hard to find, and there is no way to limit kernel exposure on XP.

    Beyond that there's very little difference between user and admin on XP as the separation wasn't enforced properly.

    Beyond that there's no ASLR or SEHOP. So getting onto the system won't be nearly as difficult.

    I could probably go on for a really long time but I fear it would fall on deaf ears and derail a topic that isn't about this.

    I suggest using EMET on XP, as the system is already in dire need of help as it is. I wouldn't wait.
     
  10. DR_LaRRY_PEpPeR

    DR_LaRRY_PEpPeR Registered Member

    Joined:
    Oct 11, 2012
    Posts:
    141
    Location:
    St. Louis area
    All right, I see what you're saying. :) [I/we] Just have to hope that new ones are fixed soon enough before getting exploited!

    And AFAIK, the vast majority (all...?) of the kernel exploits apply to later versions of Windows just as much as XP, don't they? (It seems, generally, from scanning all bulletins over time.) In that case, I don't see them as making much difference? *shrug* Yeah, yeah, maybe ASLR could make it more difficult. But, if an exploit is able to bypass ASLR, aren't those systems just as vulnerable as XP at that point?
     
  11. DR_LaRRY_PEpPeR

    DR_LaRRY_PEpPeR Registered Member

    Joined:
    Oct 11, 2012
    Posts:
    141
    Location:
    St. Louis area
    When you disabled AlwaysOn... if you went to OptOut, so DEP was still "on for everything," but you didn't have to add an explicit exception, that's Windows doing its implicit DEP opt out thing, which doesn't happen with AlwaysOn.

    What is the audio driver? I'd like to run the installer, to make sure my Permanent DEP DLL still allows it to work OK. I haven't seen any problem so far with a couple implicit opt out programs I tried.


    Yeah, I haven't attempted to do anything yet since I think I figured out how the AppPatch database file works and is written to. :) Heck, if it wasn't for the AppPatch .sdb file, you could have a non-GUI configuration thing in JavaScript, etc. to handle the registry part...

    I don't know what you think about command line stuff...? Stay away from it? :argh: Of course I'd have a command line EMET_Conf if I'm going for a transparent, drop-in replacement for EMET, I just didn't know if anyone would want to use that only first instead? Maybe creating the GUI part isn't as complicated as I think (trying to think about the initial design, similar to EMET/NEMET), but I won't know till I jump in more. I don't have any experience like I said :doubt:, although it doesn't seem too complicated. I'm not interested in using any development "stuff" to make things easier. I just like to use pure WinAPI C (plus, I really don't know anything about said "other stuff" anyway :p).
     
  12. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    A vulnerability may exist in both the XP and the Windows 8 kernel, but exploiting the one in the 8 kernel will be more difficult.

    You may also have a bug in some graphics rendering code. But as that code is now handled in userspace it wouldn't provide a full system compromise like on XP.

    To bypass ASLR requires an infoleak in Windows 8, as they've finally gotten a working version of ASLR. You also lose an entire class of exploits just by having SEHOP, which can thankfully be ported to XP.

    There's a lot to consider, but it's not really on topic.
     
  13. luciddream

    luciddream Registered Member

    Joined:
    Mar 22, 2007
    Posts:
    2,545
    But plenty of 3'rd party apps with other means to prevent buffer overflow attacks (amongst other things) that accomplish essentially the same thing as ASLR & SEHOP. And 3'rd party tools/hardening tweaks that can also account for some shortcomings you mention.

    And take into account, as Larry said, that the vast majority of these exploits target post-XP OS's anyway, and not even XP itself. And I'd say an argument could certainly be made to the contrary.

    But yeah, we've been through this plenty of times now, and it's OT. I got the info. I was looking for in another thread, that Larry posted. I expect a final release for 3.5 within a month or so. I'm going to wait till then... if I even bother installing it at all, after hearing about this EMET phoning home through svchost stuff... which brings to yet another reason I believe XP all things considered "can" be the safest MS OS to date (in the right hands). I can block svchost.exe altogether here on my OS and stop that traffic with no ill effects. Could you?... or is that one of the (many) concessions you have to make for that safer kernel, and a tool (UAC) to ask you: "are you sure?" every time you want to do something? Sometimes this "safer kernel" even prevents vendors from being able to make their security software function properly on that OS. So it's more difficult for bad guys to write stuff to hit you, sure, but also harder for the good guys to write tools to protect you. I'd trust SBIE more on XP than on an OS with these safer kernels for this reason, especially over a 64-bit OS (I wouldn't trust ANY 3'rd party security software on one). Given the choice, I'd rather have the reliable tools and trust myself to evade the bad guys. But indeed... OT ; )

    I feel fine with my Always On Hardware DEP (OS applied) & Comodo's buffer overflow protection. Neither phone home on me : ), and I don't need to install a notoriously vulnerable framework to get either to function.
     
    Last edited: Mar 25, 2013
  14. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    Security through obscurity.

    There is no comparable technology on XP. Any ASLR substitute is generally just a nop-slide, like Comodo's I believe (definitely Sophos') (useless) or randomization of very little address space.

    There is no accounting for a weak kernel, except for reducing kernel attack surface, which doesn't exist on XP.

    I don't care about outbound protection as I don't consider it a security issue.

    Well... without that tool privilege escalation is trivial, like in XP. So unless your security software is patching the running kernel, or using kernel APIs, (it's patching if anything) it'll easily escape the mechanism if the attacker actually cares at all about this.

    SBIE is just as incapable of preventing/ mitigating the damage of kernel exploit as any other sandbox, whether it's XP or Vista or 7 or 8. Hooking the kernel only prevents attackers from bypassing it as soon as they achieve administrative privilege.

    64bit OS's have permanent DEP and more powerful ASLR.

    Agreed, assuming those are all of the reasons you've got, I've addressed them, and, again, I fear they'll fall on deaf ears, but it's not important.

    The information is there for you to consider.
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.