VLC V2.1.3 crashes with MS EMET

[gorg]

Hi!
I just want to tell you, that VLC V2.1.3 crashes with Microsoft EMET while V2.1.2 does not.
MS EMET notification: SimExecFlow

OS: Windows 7 64bit
VLC: 2.1.3 (Standard install, standard pref, standard skin)
MS EMET: 4.0.4913.26122

I searched the forum and found only one entry with the word emet which does not cover this.
I just rolled back to 2.1.2 which is ok for me. Maybe someone can research and report a bug if applicable.

Sorry for my english, it is not my native language, and sorry that I can not investigate further, I'm just a user. :p

[Rémi Denis-Courmont]

Unfortunately, without details on where and why EMET is crashing VLC, there is pretty much nothing VLC developers can do. It might just as well be an EMET bug.

[pivotvelting]

Dear all,

actually this issue is not about "crashing" in a normal kind of sense.

"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.

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://blogs.technet.com/b/srd/archive/ ... t-4-1.aspx

http://technet.microsoft.com/en-us/security/jj653751

http://support.microsoft.com/kb/2458544/en-us

You might look at it as kind of watch-dog application if you wish.

Back to the issue:

Before version 2.1.3 vlc media player ran ALWAYS smoothly under the eyes of EMET.

For 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.

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 and 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 with the notification that "SimExecFlow mitigation rule" triggered this watch-dog action.

My solution has been to roll back to version 2.1.2 of vlc, the same as “gorg” did.

Other users have been trying to post bug reports about this issue. These have been canceled (https://trac.videolan.org/vlc/ticket/10583), yet, obviously because users and vlc code enthusiasts are still unaware of what EMET is and how to communicate this issue in kind of proper way.

I hope my text helps to enable you to reestablish your well known media player as one which is running as smoothly with EMET as ever before .

pivotvelting

[Jean-Baptiste Kempf]

Sorry, but no idea what SimExecFlow is supposed to be. 2.1.3 uses an updated compiler, so that could come out of that.

[Orlin]

Having same problem (Vista HP x64, EMET 4.0).

After reading description of SimExecFlow here I found temporary workaround - by decreasing number of emulated instructions for VLC process. Here's how to do it:
1. Run regedit
2. Go to HKLM\SOFTWARE\Microsoft\EMET\vlc.exe\
3. Check value for *\VideoLAN\VLC\vlc.exe (sth like: {b8e8ea28-d844-4de8-82e7-3f4f7ffc47d7})
4. Now go to HKLM\SOFTWARE\Microsoft\EMET\_settings_\{b8e8ea28-d844-4de8-82e7-3f4f7ffc47d7} (use value from step 3)
5. Create new DWORD value with name SimExecFlowCount and value 6 (highest value, that doesn't stop VLC, found by trial and error).
6. Run VLC

[nathan.gautrey]

Nice find Orlin!

Same issue with Windows 7 SP1 64bit, any update on this?

EMET is used heavily in the business world so it would be good to get a fix on this as a lot of admins won't spend the time fixing it and will either not upgrade VLC or will tell people to use media player instead! :O

Not to mention Microsoft (shocking as it might be) is giving VLC extra free security by including it in the popular software list, which is never a bad thing!

Alternative way (not quite as good but if you are in a rush) open EMET and in the applications list and under the ROP tab you'll find SimExecFlow, you can untick this for the vlc.exe process.

When you restart VLC you should find it working.

[bA28K549k]

When EMET profile "Maximum security settings" is chosen, 2.13 breaks:
"EMET 4.1 detected SimExecFlow mitigation and will close the application: vlc.exe"

Same error message with EMET 4.04.
Providing an app profile to EMET does not solve this. Even with all the uncheckable options, unchecked, 2.13 still crashes.

Also selected in EMET: "Stop on exploit", "Anti Detours", and "Banned Functions."

2.12 does not break.

Download EMET here: http://www.microsoft.com/en-us/download ... x?id=41138

Particularly as VLC is exposed to the Web, it would be advisable to make VLC compliant with EMET maximum security settings.

[Jean-Baptiste Kempf]

As SimExecFlowCount is not really explained anywhere, we can't do anything... And as EMET is not open source, we cannot fix it.

But I'd tend to say that our compiler is buggy.

[pivotvelting]

SimExecFlowCount is not really explained anywhere

For SimExecFlowCount you might find this link interesting:

http://blogs.technet.com/b/srd/archive/2012/07/24/emet-3-5-tech-preview-leverages-security-mitigations-from-the-bluehat-prize.aspx

...But I'd tend to say that it is buggy.

Actually I tend to think it seems to me as a little bit more involved than that.

EMET is a administrative tool to reduce chances that hackers can exploit unresolved potential buffer overflows in Windows applications.

EMET's tests for buffer overflows are called 'mitigations'. By default EMET does not interfere with any application unless being told to do so.

EMET contains files with predefined settings, one is called "popular software.xml". In this there are proposed sets of settings for some popular software packages, including vlc.

This profile is not used automatically. It has to be applied manually.

EMET does not "crash" vlc, with the "popular software.xml" being applied it simply stops vlc 2.1.3. It seems to be obvious that 2.1.3 is not compatible anymore (for yet unknown reasons) with one of EMET's 'mitigations'.

So far all EMET checks have been compatible with vlc. Vlc has changed now. All mitigations being used can be configured. It might be necessary to change the set of external safe guards being used for an application that has changed.

So I would like to describe it as "The proposed set of safe guard settings for vlc in "popular software.xml" of EMET has only been compatible with vlc up to version 2.1.2."

Users simply have to switch off a 'mitigation', a certain external test for buffer overflows, a certain trip wire. That's all.

I tend not to see "EMET might be buggy" as a right estimation.

Everyone who uses the "popular software.xml" in EMET and wants to use vlc 2.1.3 might want to disable the SimExecFlow mitigation for vlc.exe in the EMET Gui.

As for vlc there has been predefined set of seetings I would expect that in a new version of EMET there might be a change in the included file "popular software.xml" for vlc (SimExecFlow mitigation disabled for vlc.exe).

I also guess getting to know which change in vlc or which change of how vlc is compiled made the change in EMET's safe guard settings for vlc necessary would be nice but at the end this not really important.

It might be safer to use the proposed SimExecFlowCount setting as hacked files may still have chances to trigger SimExecFlow, but as editing the registry is not safe for everyone, I would prefer to use the EMET app settings gui to disable SimExecFlow instead.

Up to now there are these other postings concerning this thread's cause:

VLC trac:

https://trac.videolan.org/vlc/ticket/10583

EMET forums:

http://social.technet.microsoft.com/Forums/security/en-US/b603ecaa-441c-4256-8f3f-ce5c33e3723a/

[Rémi Denis-Courmont]

There is no concrete proof that it is an EMET bug, but there is also no concrete proof that this a VLC bug.

But with so little informations, there is simply nothing VLC developers can do. Two weeks have passed and still nobody has been able to supply a symbolic strace trace, which would be the bare minimum...

[mr chips]

edit: see this post https://forum.videolan.org/viewtopic.ph ... 16#p399716

[Ludrax]

It turns out that vlc.exe from the vlc-2.1.3-20140203-0206 debug package does run successfully on a system where the standard win32 VLC 2.1.3 downloaded from the main website will not. In other words, vlc-2.1.3-20140203-0206 will run with SimExecFlowCount enabled in EMET 4.1.

I think it's not good news

EMET's tests for buffer overflows are called 'mitigations'. By default EMET does not interfere with any application unless being told to do so.

[Ludrax]

I think it's not good news

Why do you think it's not good news? We've got a certain build of 2.1.3 that does work with EMET 4.1, so comparing between that build and one that doesn't work seems like a good place to start. If anything, that's a step in the right direction, not bad news.

Also, if the devs need that stack trace, I can provide it too. My org has VLC and EMET deployed on thousands of machines so I'll do whatever I can to help fix this. It doesn't help that EMET's operation is so sparsely documented.

are you sure it's re added as "new" app?

After you install EMET, you must configure EMET to provide protection for a piece of software. This requires you to provide the name and location of the executable file that you want to protect. To do this, use one of the following methods:

• Work with the Application Configuration feature of the graphical application.
• Use the command prompt utility.

[mr chips]

are you sure it's re added as "new" app?

Blast, I got carried away and overlooked that. Doing that triggers the same problem with EMET, so I jumped the gun a bit earlier.

Now it seems like EMET doesn't cause VLC to exit in a manner that generates a stack trace:

Code: Select all

C:\Users\username\Downloads\vlc-2.1.3-20140203-0206>gdb GNU gdb (GDB) 7.6.1 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-mingw32". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. This binary was built by Equation Solution <http://www.Equation.com>. (gdb) target exec vlc.exe (gdb) run Starting program: C:\Users\username\Downloads\vlc-2.1.3-20140203-0206/vlc.exe [New Thread 3172.0xf38] [New Thread 3172.0xf68] [New Thread 3172.0xf64] [New Thread 3172.0x1e0] [Inferior 1 (process 3172) exited with code 030000000042] (gdb) bt No stack.

What else can I do to get a stack trace?

EMET does generate a ~200KByte binary DMP file and a 70Kbyte XML file.
Here are the contents of the XML file, sans 70Kbytes of memory address contents in lines 18-20:

Code: Select all

<Exploit Code="7"> <Message>SimExecFlow check failed: Application : C:\Users\username\Downloads\vlc-2.1.3-20140203-0206\vlc.exe User Name : 830\Ben Session ID : 1 PID : 0x980 (2432) TID : 0xD20 (3360) CodeAddress : 0x00402A29 CodeStackPtr : 0x28FD54 CalledAddress : 0x75F042FF API name : kernel32.VirtualProtect StackPtr : 0x0028FD38 FramePtr : 0x28FD60 </Message> <App>C:\Users\username\Downloads\vlc-2.1.3-20140203-0206\vlc.exe</App> <Module>C:\Users\username\Downloads\vlc-2.1.3-20140203-0206\vlc.exe</Module> <Registers EAX="401000" EBX="75f042ff" ECX="1" EDX="0" ESI="4012a8" EDI="28fd60" EBP="28fd98" ESP="28fd38" EFlags="212" /> <Mem Addr="400000"></Mem> <Mem Addr="75f03000"></Mem> <Mem Addr="28e000"></Mem> <GUID>c63d732f-ce0c-496a-b63b-050012ee62f9</GUID> </Exploit>

Can any of the devs say if these dump files from EMET will help them? If so I will find somewhere to upload them.

[Rémi Denis-Courmont]

Maybe or maybe not. At least, it will not help me.

[mr chips]

Maybe or maybe not. At least, it will not help me.

OK.

Can anyone suggest other ways to get a stack trace?

the 64 bit version of VLC 2.1.3 for Windows doesn't have this problem.

[bA28K549k]

Maybe or maybe not. At least, it will not help me.

OK.

Can anyone suggest other ways to get a stack trace?

the 64 bit version of VLC 2.1.3 for Windows doesn't have this problem.

Several of the EMET protections are not applied to 64 bit executables. This could be a workaround. Is there a packaged build?

[Ludrax]

EMET is a administrative tool to reduce chances that hackers can exploit unresolved potential buffer overflows in Windows applications.

now we can see that will only stop installed VLC, but it won't do anything when user starts fake VLC from flash drive

What else can I do to get a stack trace?

EMET does generate a ~200KByte binary DMP file and a 70Kbyte XML file.

http://msdn.microsoft.com/en-us/library/d5zhxt22.aspx ?

[mr chips]

OK, I've got VS 2013 now and can analyse the dump files and, maybe step through the error.

The summary info VS 2013 gets from the dump file is:

Code: Select all

Dump Summary ------------ Dump File: emet_20140226_215326_2432_5068.dmp : C:\Users\username\Documents\EMET dmp files\emet_20140226_215326_2432_5068.dmp Last Write Time: 26/02/2014 9:53:26 PM Process Name: vlc.exe : C:\Users\username\Downloads\vlc-2.1.3-20140203-0206\vlc.exe Process Architecture: x86 Exception Code: 0xC0000090 Exception Information: The exponent of a floating-point operation is greater than the magnitude allowed by the corresponding type. Heap Information: Not Present

Will update in the next couple of days with more details, if I can get them.

[Kelimion]

Just wanted to let you guys know that VLC 2.1.3. does work with the EMET 5.0.5168.17251 preview and its proposed rules for VLC from the Popular Software profile.

Edit: Or so it did a few hours ago. But disabling SimExecFlow for vlc.exe in this version of EMET does actually work.