locked
Why no Green Tick against some Apps? RRS feed

  • Question

  • Hi,

    Just installed EMET and, as first time user, am wondering why after I selected all my running process apps to run with EMET that most of them have a green tick next to them but some of them don't although I did select them and when I tried to reselect them i got an error popup message re: Conflict its already been selected.

    The running processes without the green tick are:

    winlogon

    smss

    csrss

    Does anyone know why no green tick?

    As background, am running XP Home SP3. Have deployed EMET as suggested by M/S to try to resolve a problem with the windows update page hanging. Automatic Updates work.

    Monday, February 4, 2013 2:59 PM

Answers

  • Hi SimberLake,

    This is the same for me on Windows XP , Windows Vista and Windows 7. From what I can tell, there is a fail-safe within EMET not to protect critical operating system processes that are necessary for Windows to boot correctly even if the person using EMET wishes to protect them. If a critical Windows process is not compatible with EMET, your system will not boot.

    For example, on Windows Vista I protected lsass.exe and lsm.exe with EMET 3.0 and rebooted for it to take effect. The system would not start afterwards. I needed to access Safe Mode and manually remove the entries from Windows Registry for these files from the following location to resolve this:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EMET

    I also had the same error when I tried to add these processes again when I saw they were not being protected “File conflicts with existing entry”.

    I have tried to protect all of the processes that you mention as well as the following processes:

    Explorer.exe

    Services.exe

    Svchost.exe

    Wininit.exe

    Userinit.exe

    For smss.exe even though this is a user mode process, it spends all of its time in kernel mode as shown by the following screenshot from my Windows 7 system taken with Sysinternals Process Explorer. This is relevant since EMET protects user mode, not kernel mode processes.

    Direct Link To Image:

    http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/SMSSKernelMode1.png

    For all of these processes I experienced the same behavior as you. EMET would not protect them and thus would not show the green tick "Running EMET".

    For explanations of what these processes do, a good source of info is the following PDF file(see pages 7 – 20)

    https://blogs.sans.org/windows-security/files/Process_Hacker_SANS_Jason_Fossen.pdf

    I never had success in protecting explorer.exe but others have had partial success as mentioned at the end of the Application Compatibility thread:

    http://social.technet.microsoft.com/Forums/en/emet/thread/1e70c72b-67b2-43c4-bd36-a0edd1857875

    EMET should only be used for protecting processes and programs that process potentially un-trusted and unknown data e.g. your web browser (Google Chrome, Firefox, Internet Explorer, Safari, Opera etc.), document readers e.g. Microsoft Word, Excel, Adobe Reader/Acrobat, Foxit Reader or any program that accesses the internet e.g. Skype, Yahoo Messenger, Windows Messenger, Oracle Java etc.

    For a thorough list of recommended processes, please see the following links:

    http://www.rationallyparanoid.com/articles/microsoft-emet-3.html

    http://krebsonsecurity.com/2012/09/internet-explorer-users-please-read-this/

    I would not recommend adding lsass.exe to the list to protect with EMET. When I added lsass.exe for Windows Vista, as I said, it would not boot. Windows XP and Windows 7 are fine protecting lsass.exe but I cannot guarantee it will be the same for you.

    I have assumed that you are using EMET 3.0 but the above advice applies to EMET 3.5 Tech Preview too.

    Also, for EMET 3.5 Tech Preview, please be aware that the ROP (Return Oriented Programming) mitigations, namely:

    Load library checks (LoadLib)

    Stack Pivot

    Simulate Execution Flow (SimExecFlow)

    Caller Checks (Caller)

    Memory Protection Checks (MemProt)

    Are disabled by default. These are experimental mitigations. They should be only enabled for a process gradually while testing their effects on that program. Simulate Execution Flow and Caller Checks are the most likely to cause the program to crash on start-up. I do not have any ROP mitigations enabled for important processes like lsass.exe, all other mitigations are enabled.

    I hope the above information is of assistance to you. If you have any further questions, please let me know and I will be happy to assist.

    Thank you.





    • Edited by JamesC_836 Thursday, February 7, 2013 11:20 AM Corrected spelling error
    • Marked as answer by SimberLake Sunday, February 10, 2013 10:13 AM
    Monday, February 4, 2013 9:08 PM

All replies

  • Hi SimberLake,

    This is the same for me on Windows XP , Windows Vista and Windows 7. From what I can tell, there is a fail-safe within EMET not to protect critical operating system processes that are necessary for Windows to boot correctly even if the person using EMET wishes to protect them. If a critical Windows process is not compatible with EMET, your system will not boot.

    For example, on Windows Vista I protected lsass.exe and lsm.exe with EMET 3.0 and rebooted for it to take effect. The system would not start afterwards. I needed to access Safe Mode and manually remove the entries from Windows Registry for these files from the following location to resolve this:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EMET

    I also had the same error when I tried to add these processes again when I saw they were not being protected “File conflicts with existing entry”.

    I have tried to protect all of the processes that you mention as well as the following processes:

    Explorer.exe

    Services.exe

    Svchost.exe

    Wininit.exe

    Userinit.exe

    For smss.exe even though this is a user mode process, it spends all of its time in kernel mode as shown by the following screenshot from my Windows 7 system taken with Sysinternals Process Explorer. This is relevant since EMET protects user mode, not kernel mode processes.

    Direct Link To Image:

    http://i742.photobucket.com/albums/xx69/Jimboc/Microsoft/SMSSKernelMode1.png

    For all of these processes I experienced the same behavior as you. EMET would not protect them and thus would not show the green tick "Running EMET".

    For explanations of what these processes do, a good source of info is the following PDF file(see pages 7 – 20)

    https://blogs.sans.org/windows-security/files/Process_Hacker_SANS_Jason_Fossen.pdf

    I never had success in protecting explorer.exe but others have had partial success as mentioned at the end of the Application Compatibility thread:

    http://social.technet.microsoft.com/Forums/en/emet/thread/1e70c72b-67b2-43c4-bd36-a0edd1857875

    EMET should only be used for protecting processes and programs that process potentially un-trusted and unknown data e.g. your web browser (Google Chrome, Firefox, Internet Explorer, Safari, Opera etc.), document readers e.g. Microsoft Word, Excel, Adobe Reader/Acrobat, Foxit Reader or any program that accesses the internet e.g. Skype, Yahoo Messenger, Windows Messenger, Oracle Java etc.

    For a thorough list of recommended processes, please see the following links:

    http://www.rationallyparanoid.com/articles/microsoft-emet-3.html

    http://krebsonsecurity.com/2012/09/internet-explorer-users-please-read-this/

    I would not recommend adding lsass.exe to the list to protect with EMET. When I added lsass.exe for Windows Vista, as I said, it would not boot. Windows XP and Windows 7 are fine protecting lsass.exe but I cannot guarantee it will be the same for you.

    I have assumed that you are using EMET 3.0 but the above advice applies to EMET 3.5 Tech Preview too.

    Also, for EMET 3.5 Tech Preview, please be aware that the ROP (Return Oriented Programming) mitigations, namely:

    Load library checks (LoadLib)

    Stack Pivot

    Simulate Execution Flow (SimExecFlow)

    Caller Checks (Caller)

    Memory Protection Checks (MemProt)

    Are disabled by default. These are experimental mitigations. They should be only enabled for a process gradually while testing their effects on that program. Simulate Execution Flow and Caller Checks are the most likely to cause the program to crash on start-up. I do not have any ROP mitigations enabled for important processes like lsass.exe, all other mitigations are enabled.

    I hope the above information is of assistance to you. If you have any further questions, please let me know and I will be happy to assist.

    Thank you.





    • Edited by JamesC_836 Thursday, February 7, 2013 11:20 AM Corrected spelling error
    • Marked as answer by SimberLake Sunday, February 10, 2013 10:13 AM
    Monday, February 4, 2013 9:08 PM
  • Many thanks James.

    Very clear reply - please accept apology for my delayed reply.

    Sunday, February 10, 2013 10:16 AM
  • Hi SimberLake,

    I am really glad that I was able to assist you. No worries about the delay.

    As always, if I can be of any further assistance, please let me know. Thank you for marking my post as an answer.

    Sunday, February 10, 2013 3:50 PM