VLC 2.1.3 for Windows (on Windows 7) creates EMET 4.0 SimExecFlow closure
therefore making 2.1.3 unusable
Activity
added Status::needs more info label
Dear all,
I think the "bug" which is reported here is that vlc players up to version 2.1.2 have been compatible with EMET and starting with version 2.1.3 this is unfortunately not the case any more.
I also see that some words about EMET might be needed here.
"EMET" stands for "Enhanced Mitigation Experience Toolkit". It is a "anti-hacker"-tool provided by Microsoft that shall give companies and private users an additional layer of security against potential security holes in application used on windows systems.
You might look at it as kind of watch-dog application if you wish to do so.
EMET is not installed by default but by users who want to make use of this additional layer of security.
Here are some official links to EMET resources:
http://technet.microsoft.com/en-us/security/jj653751
http://support.microsoft.com/kb/2458544/en-us
Back to the issue:
Before version 2.1.3 vlc media player ran ALWAYS smoothly under the eyes of EMET.
EMET users can define "rules" and "app specific rules".
The Microsoft EMET team provides certain predefined rule set for common applications.
As VLC media player is a well-known application there is a rule set for vlc media player, too.
Vlc media player up to version 2.1.2 complied with ALL app specific mitigation rules set as to be applied. It never triggered any of these trip wire kind of rules before.
Normally EMET shall stop an application if it tries to load a data file and those file's data try to glitch through a security hole of this application.
Troubleshooting app specific EMET rules normally consists of disabling EMET rules one by one in order to be able to get the maximum set of mitigation rules under which an application runs being watched by EMET on a user's system.
So I tried to troubleshoot vlc media player v 2.1.3 on windows 7 x64 being closed by EMET for triggering a mitigation rule. But I failed totally.
Even with ALL app specific mitigation rules DISABLED EMET 4.0 and EMET 4.1 stop vlc media player version 2.1.3 immediately with the notification that "SimExecFlow mitigation rule" triggered this watch-dog stop action.
So the problem consists of that users have no choice of applying any kind of adjustment in EMET, they can only roll back to version 2.1.2 of vlc, which is what I did.
You might argue that it is not vlc's fault to trigger EMET rules. On the other hand you might have a look at users who want to have EMET watch their systems security.
Version 2.1.3 sadly stopped to be EMET compatible.
Might it not preferable to want vlc player to be compatible with EMET again?
I hope my text helps you to see why this bug report might be helpful to get vlc media player to be EMET compatible again.
Thank you for your kind attention.
pivotvelting
removed Status::needs more info label
**EMET and VLC version 2.1.3: Issue and resolution
Hey!
I think that the introduction to EMET was necessary but I have found a workaround. There is an EMET app specific setting to make vlc 2.1.3 behave well with EMET again.
**Steps to reproduced issue
You have to have
-
vlc 2.1.3 for windows
-
EMET 4 with popular software protection profiles (xml file) imported.
After you try to start vlc.exe emet stops vlc.exe with message "EMET detected SimExecFlow mitigation and will close the application: vlc.exe"
Your app log might contain items like this one:
AppEvent log: "SimExecFlow check failed: Application C:\Program Files (x86)\VideoLAN\VLC\vlc.exe ... CodeAddress 0x00402A89 CodeStackPtr 0x28FDA4 CalledAddress 0x75B142FF API name kernel32.VirtualProtect StackPtr 0x0028FD88 FramePtr 0x28FDB0 "
There may be additional app event with a message that "C:\Windows\SysWOW64\msvcrt.dll" could not be accessed".
I guess this might be due the intercept from EMET (?).
**Resolution
Open EMET UI, app options dialog and disable "SimExecFlow" for vlc.exe.
Afterwards vlc 2.1.3 should start without problems.
**My experience
I first thought that I had the same issue as pivotvelting. With whatever setting I disabled vlc would not be startable while EMET active.
But then I tried to reset EMET settings to defaults (using its wizard) and reloaded its popular software settings profile (!). This might be necessary or not.
After I disabled the "SimExecFlow" mitigation rule for vlc 2.1.3.
Ala!
Vlc 2.1.3 can be started with "SimExecFlow" diabled.
I guess the only remaining thing which should be reviewed is if vlc / liberary devolopers could make vlc again usable with EMET even with "SimExecFlow" mitigation rule applied.
So I would conclude my experience as follows:
"There might be an issue with EMET and vlc 2.1.3 (under certain not yet well known circumstances). It may be required to disable "SimExecFlow" mitigation in order to use vlc 2.1.3 alongside with EMET.
If this does not help please reset EMET settings using its wizard to defaults, import again all protection profiles that had been appliead before and then try to resolve the issue with vlc by disaling again "SimExecFlow" mitigation for vlc.exe".
Have a nice day
hickoryoak
-
added Status::needs more info label
I am sorry for users have not been able to deliver the central point in this "bug" report (issue) yet.
"Still no symbolic stack trace or any useful infos on what is crashing and why."
I am afraid that nobody might be able to give you a stack trace of a crash for this issue ever.
For vlc 2.1.3 EMET detects a potentially unsafe behavior using the full rule set. Without potentially hazardous data file vlc has never before triggered any of EMET detections rules. Now a rule called SimExecFlow is triggered just by starting vlc.
As triggering at least one of its rules may be the result of hacker activities EMET stops the vlc process.
There is no crash, instead there is obviously a change in behavior of vlc. The kind and cause of this behavioral change remains unknown yet.
And where actually no crash happens there can be no stack trace at all.
Vlc up to 2.1.2 always complied with all EMET rules. But Vlc 2.1.3 is stopped by EMET right after program start if SimExecFlow is set. "Set" means that up to now users could safely estimate that normal app execution of vlc would never trigger the SimExecFlow detection. So triggering this rule as a result of loading a data file could indicate that the data file contained unsafe data that tried to be executed in the vlc process.
To be on the most secure side users of EMET want applications to behave in a way that they can use as many rules of EMETs' as possible for the detection of such hazardous "data glitches". This means that apps should trigger the lowest possible number of rules under normal circumstances.
Each rule that can be used in normal application usage means an additional code behavior check that can be used to detect unusual and suspicious behavior and circumstances which can be interpreted as possible hacker attack.
Because vlc up to version 2.1.2 complied with all of EMET rules Microsoft's EMET team and any user of vlc could safely define the full rule set for vlc in EMET.
In version 2.1.3 even the normal program start triggers "SimExecFlow" rule, so this rule has to disabled in EMET.
This is no problem, at least for "advanced" users. They might see that there could be totally harmless reasons why this rule has now to be disabled for vlc. They can not tell that this is indeed a safe estimation but they might feel happy with it because they can think that safe reasons exist.
It might be better to be also able to use this rule for the detection of hazardous data files but they can live with having to disable it.
'Normal' users reach out for help being unaware that changing the rule set for a new version of an application MIGHT be totally normal. How should users tell that the interception and notification by EMET is normal and only caused by harmless changes e.g. by how vlc is compiled?
Security is also about trust. If anyone could check why vlc 2.1.3 triggers "SimExecFlow" while 2.1.2 does not, this information could provide (especially for 'normal') users more confidence in disabling "SimExecFlow" for vlc.exe in the EMET UI.
I do not reopen the ticket as this is not really a bug.
If you wish to help users: Could you please point the right people of your team to this thread so they can either post an advice or even try to track down the root cause why vlc 2.1.3 triggers an EMET rule while 2.1.2 did not?
These issues' workarounds are:
-
Users can roll back to version 2.1.2.
-
Users can make a small tick in EMET (disable SimExecFlow in EMET for vlc.exe, may be after a options reset) as I wrote in my first post.
Sorry, I am afraid that I kind of bloated this thread again.
Are there chances that EMET's role in this issue becomes a little bit clearer now?
What kind of information else do you need to get a feeling on how to decide what you can do in this issue?
-
" it very much seems like this is a bug in EMET"
It is not a bug of EMET. Have a look at my explanations.
Rules for EMET are the maximum number of rules that can be used for stop free app execution under normal circumstances and harmless data files.
"...VLC developers cannot fix EMET.."
Naturally. Setting these rules is an administrative task, not that of a developer.
But may be you want your systems be guarded by EMET, too?
Nobody wants anyone to do anything impossible.
Actually there is information on what goes wrong. I posted the information that are stored in the event log alongside with the notification that vlc triggered the rule in question. Any developer with vlc, vlc developer setup and EMET and the old full rule set applied to vlc might be able to get close to the answer?
Anyway, vlc.exe is not set to be guarded by default, there is only a xml file included with EMET that can be used by users to protect "popular programms" with EMET.
As it had been normal and safe to use the whole rule set with vlc, the EMET team had defined this whole rules set in a xml file that is included with EMET.
Users of EMET tend to use these predefined profile files as starting point to protect their systems.
So anyone should post a message to a EMET forum that this issue has shown up.
May be that in the next release of EMET the EMET team shall define the vlc standard rule set with SimExecFlow disabled. That is what there can be done to "fix a bug".
No, it is not a bug, but there is a necessary adjustment in support files in order to cope with what might be caused by special behaviors of the new compiler used to compile vlc.
There is now also a thread in EMET support forum.
So there are chances that at one day new users of EMET and vlc will not meet this issue.
@JB:
Apparently setting SimExecFlowCount to a value of 6 is not supported by EMET's GUI, I guess?
MiniDump of VLC 2,1,3 being closed by EMET 13.02.2014
Added attachment:
MiniDump of VLC 2,1,3 being closed by EMET 12.02.2014
Added attachment:
Added attachment:
Update: I tried to obtain additional information by using the GDB-Debugger on the nightly debug build. That doesn't give much feedback, however:
[Inferior 1 (process ....) exited with code 030000000042] (gdb) bt No stack.The reason for that probably being the fact, that EMET has already closed the application. In case someone is interested, I could upload a dump of the crashed debug-version. Dunno, if this is useful, though, since I am not a programmer.
Things that can be done without a stack trace:
Did anything change in the compile environment for 2.1.3? Is the change from GCC 4.6 to 4.8 the only shift?
If so, then either recompile 2.1.2 against GCC 4.8 and see if it gets the same EMET errors, or recompile 2.1.3 against GCC 4.6 and see if the EMET error go away.
In the 1st scenario, you isolate the issue to GCC and if so isolated then we can shift the investigation that way to find out what changed. It may be that the GCC devs mucked something up or it is an issue they should be made aware of.
In the later scenario, if we get the same EMET stuff after compiling against 4.6, then it would be feasible to look at the libraries and see if there were any major changes there.
EMET doesn't let a stack trace get generated, but that is no reason to put up a wall and say "Oh well". There is plenty of other stuff to try that may isolate the issue.
Or it may be something with the MSYS and MinGW tools.
From the GCC changelog: Windows MinGW-w64 targets (-w64-mingw) require at least r5437 from the Mingw-w64 trunk.
mentioned in issue #10587 (closed)
