Jeroen van Eekeres:

Respectfully (nothing personal), that is total nonsense. All the de-/enc-/trans- coders that use ffmpeg as their internal engines, like VLC, have been able to decode .mov files with many codecs including prores for quit some time now. Encoding is of course a different story. Not in the last place thanks to Apple.

No offense taken. I think there is a slight misunderstanding. When I said "QT" that includes Open Source like fffmeg. This is why I said "platform" (not just "QT Player 7"). I know of fffmpeg and the various free/share/retail software that utilize it.

I'm not a big fan of it because of its instability in my experience. But if Avid can make it work, why not?

You can't really fault Apple. They created QT for their OS. They want to retain control of it. By creating a standard you inevitably lose control of its development.

Jeroen van Eekeres:

IMHO 'we' the professionals, broadcasters and manufacturers should have worked on improving this situation over a decade ago, and Avid should have had a leading role is this. Now Apple pulls the plug on the profesional video market for the second time I find the 'Avid, what are we going to do now?' questions logical but also proof of the pathetic situation a large part of industry is in.

There is MXF. A standard which Avid helped to develop as a replacement for OMF. But it does not have the market penetration, especially in the consumer side, of QT. MC can work just fine without QT Player. It can still capture, import, transcode, edit and export to various formats.

WillH:

In my understanding, QT must be in the Pro version to unlock any import, edit or export capabilities on a Windows machine.

This is only true if you want to export, import, or edit via Quicktime at the Windows desktop level.

WillH:

n my understanding, QT Pro must be installed for it to provide any of its services within MC. Thus, importing ProRes footage, exporting any QT movie, self-contained or reference, and so on, any of the services QT provides to the functionality of MC, as others have mentioned above, would require the QT Pro product key to be entered somewhere where QT can recognize it.

This is not accurate.  You have always gotten these features (depending on MC version) within Media Composer without needing Quicktime Pro.

Dom Q. Silverio:

You can't really fault Apple. They created QT for their OS. They want to retain control of it. By creating a standard you inevitably lose control of its development.

100% disagree. First of all Apple created QT for windows which is 'not really' their OS is it now? I believe Apple wanted the iTunes store, the iPod and later the iPhones and iPads to have the largest possible market share hence QT and itunes for windows. Never ever did I get the impression that Apple cared about the 'control' over quicktime...it wanted control over its market share of consumer products. The pro market... a niche which was never a reason for the development of QT for windows.  

The only counter argument is the development of Prores. Whoever was commercially in charge of the FCP development team also understood that a new codec for HD  and beyond was needed which became Prores. But we all know how FCP7 ended.

Anyway. From the moment Media composer started supporting a 64bit OS in version 3.0 (june 2008 - Windows Vista) it was obvious MC would become a native 64bit application at some point. It took until version 6 (November 2011 - Windows 7). Since 2008 it was also obvious quicktime had to follow the same path but Apple never ever even indicated it would create a 64bit version, not even for Mac OS.

8 years the writing was on the wall in huge letters. Then came the FCP-X introduction and now the QT EOL... I don't think Apple will EOL Prores soon but it might also go the same road if it is not profitable for Apple.

IMHO Apple can be faulted for the way they handled the professional FCP + Prores customer base. The whole market is to blame for believing and following them and as far as Avid is concerned:  They should have dealt with the issue when MC went native 64 bit in 2011.

QT Player was released on Windows 95/98/NT in 1999. iTunes for Windows was released 2003.

Anyway, QT is still an Apple platform. Their move away from QT7 is no surprise. But manufacturers continue to use MOV as their preferred container with little care that QT7 on Windows has been dead for years.

Stop using MOV and maybe Apple and Blackmagic and Atomos and etc. will get the message.

Dom Q. Silverio:

QT Player was released on Windows 95/98/NT in 1999. iTunes for Windows was released 2003.

I stand corrected in my argumentation and actually wonder why QT for windows was developed at that time.

Hi, Philip,

Thanks for the correction. 

I was going from my experience. I have had QT Pro installed on my PCs since before I first purchased Avid Xpress DV in 2002 or 2003.  I always thought QT Pro was a requirement for Avid, up through all the revisions.

I remember doing a clean install of MC a few versions back, and I had uninstalled QT Pro because a version upgrade of QT was required for this new version of MC.  After the full install of MC was completed, MC gave me an error message during opening saying QT was not installed. I immediately shutdown MC and installed QT in the new required version.  However, I again received the error message on opening MC.  And, it repeated until I installed the QT Pro key through the QT player registration function.  That is what lead me to believe QT Pro was required by MC.

Best regards,
Will

A few questions about some of the information above:

- Is actually "removing" the program necessary as a first step given that you can go into the "uninstall program" section of windows and hit "change" instead of "uninstall"?  You can still untick the unneeded components of QT this way, and I believe that this would leave the QT Pro license intact, so wouldn't this be an easier way to makel the changes?

- Does anyone know whether or not removing all the "other" QT components -- inlcuding the player -- removes the ability of the exploits to work?  I thought that the exploits were both based on playing QT files, so I'm wondering if the absense of those components would be enough to prevent the exploits from working.  Do the exploits utilize the QT "player," or would playing QT files in ANY player allow the exploits to work?

- Are people sure that firewalling off Quicktime does anything to help?  The exploits execute new code on the sytsem, and it seems like this would likely already be on the inside of the firewall.

We really need more info on how the pieces fit together, because it seems like we're just guessing at possible solutions at the moment.  Does anyone have any specific knowledge of how the exploit works, and if removing certain componenst defeats them?  I woudl think that this information would be out there, but I couldn't find any specifics when I looked.  Please keep in mind also that not everyone is as well-versed on this subject as others.

Thanks,

L

Since these problems in Quicktime appear to be well known,  is it possible that Windows defender and other anti virus software could be educated to protect Windows systems from these problems, at least until Quicktime can be discarded.?

Hi,

I'll try to keep it simple and not too technical. There has to be approximations.

In summary, the risks are when you go to an infected web page and/or open a file readable by QT on the WEB (MOV, MP4, etc ...)

Both vulnerabilities are corrupt remote memory areas and the potential execution of malicious software (for example, running a virus, etc ..).

I do not know if it will help but here in detail vulnerabilities in QuickTime.

Like every time we get on a web page, the browser reads the tags that make up the web pages (eg tags: put character in bold, italicize characters) but especially the video tags. If the type of TAG / video is the association with QT and QT plugin installed:
a) the plugin will allocate a memory area,
b) open the QT file, load metadata QT video. Metadata has informed the player of the length, format, etc ... and reads the QT video to the end.
c) allocate a memory buffer zone to ensure smooth playback because of the speed internet is not always linear
c) if the read tag is "automatic" starts playing.


For vulnerabilities that would be loading of metadata and loading into the buffer zone that it would be possible to start performing malicious operations.


1) A vulnerability occurs when an attacker can write data outside an allocated buffer.
http://zerodayinitiative.com/advisories/ZDI-16-241/
(0Day) Apple QuickTime moov Atom Heap Corruption Remote Code Execution Vulnerability
ZDI-16-241: April 14th, 2016

Vulnerability Details :

This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Apple QuickTime. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.

The specific flaw exists within the moov atom. By specifying an invalid value for a field within the moov atom, an attacker can write data outside of an allocated heap buffer. An attacker could leverage this to execute arbitrary code under the context of the QuickTime player.
Vendor Response


What is "moov atom". An atom means an autonomous unit of metadata about the video file. The "moov atom", for its part, shows the time, the video display characteristics and some additional track information of the video.

2) The other vulnerability occurs in the atom as providing an invalid index, an attacker can write data outside an allocated buffer.
http://zerodayinitiative.com/advisories/ZDI-16-242/
(0Day) Apple QuickTime Atom Processing Heap Corruption Remote Code Execution Vulnerability
ZDI-16-242: April 14th, 2016

Vulnerability Details :

This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Apple QuickTime. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.

The specific flaw exists within atom processing. By providing an invalid index, an attacker can write data outside of an allocated heap buffer. An attacker could leverage this to execute arbitrary code under the context of the QuickTime player.


So a possible solution (as already proposed in this thread) is :

1)If necessary: uninstall VLC or software that could read the quicktime on the Web. Just keep QT.
2)Find a known and reliable web page containing a video readable by QT plugin + retain the link page.
3)to completely uninstall QT and just reinstall the CORE
4)test/check if Media Composer is working properly.
5)In its firewall, create an inbound / outbound rule against the QT core only run in localhost.
6)return to the page WEB (2) and check that the browser displays "this video can not be played" or something like that.
7)Install VLC or other software that can read the QT on the Web
8)Return to the web page (2) and verify that the browser correctly displays and plays the video

(7/8 are optional)

That's what I'll do and hoping that everything will work properly.

It looks like my last post was deleted along with the repeats of the previous post, so I'll post it again.

I just wanted to get some clarification on the exploit information above.  Specifically, can the exploit still take place regardless of what program is used to play the QT file?  In other words, if I play a compramised .mov file using a program other than QT itself (like windows media player), can the exploit still happen?  Given the instructions above, it sounds like the issue applies to the player or browser plugin, but if this is the case, why would it be necessary to firewall the QT core off if the player and browser plugins are not even installed?

Also, why is it necessary to uninstall/reinstall QT when you can select "change" instead of "uninstall" in the control panel's uninstaller?  This gives you the ability to re-select/de-select the components you want to install or uninstall.

Thanks,

L

v-block:

Since these problems in Quicktime appear to be well known,  is it possible that Windows defender and other anti virus software could be educated to protect Windows systems from these problems, at least until Quicktime can be discarded.?

As I understand it, the exploit is not a virus itself, but a "doorway" that could be used by malicious software.  A scanner can look for malicious softare that it's already aware of, but it can't "close" the door because the doorway itself is not a virus.  The presense of the doorway makes it that much easier for new, unclassified malware to get onto the system.

L

lalittle:

.../...

it sounds like the issue applies to the player or browser plugin, but if this is the case, why would it be necessary to firewall the QT core off if the player and browser plugins are not even installed?

Hi,

lalittle:

.../...

it sounds like the issue applies to the player or browser plugin, but if this is the case, why would it be necessary to firewall the QT core off if the player and browser plugins are not even installed?

Hi,

lalittle:

.../...

it sounds like the issue applies to the player or browser plugin, but if this is the case, why would it be necessary to firewall the QT core off if the player and browser plugins are not even installed?

Hi,

lalittle:

v-block:

Since these problems in Quicktime appear to be well known,  is it possible that Windows defender and other anti virus software could be educated to protect Windows systems from these problems, at least until Quicktime can be discarded.?

As I understand it, the exploit is not a virus itself, but a "doorway" that could be used by malicious software.  A scanner can look for malicious softare that it's already aware of, but it can't "close" the door because the doorway itself is not a virus.  The presense of the doorway makes it that much easier for new, unclassified malware to get onto the system.

L

Your understanding is spot-on, Larry. Nicely worded explanation. The question you've aske (which is a good one) is whether the exploit (doorway) is in the core  components or in the QT player and web browser plugin. You'd think this would be an important distinction.

For me, I find I can use all QT functioality (including QT Ref files to Squeeze, etc. plus AMA linking to MOV and MP4...) by simply installing just the core components. If the exploit is in the core components then it is possible, in theory, that if I AMA link to a poisoned MOV file that the exploit could run malicious software. I'm hoping someone can answer this. In addition, if I restrict my use of QT to just sharing between my local applications (just QT Ref and SAS to Squeeze or AE, etc.) is there any risk?