<p>You can strip most of the metadata off your files using ffmpeg:</p>

<pre><code>ffmpeg -i oldfile.mp4 -c copy newfile.mp4
</code></pre>

<p>This will copy the first audio and video streams to a new mp4.</p>

CC BY-SA 3.0
2016-03-11T22:09:18.957Z
Thx, but just tried it and the `"format_long_name": "QuickTime / MOV",` remains
GDP
CC BY-SA 3.0
2016-03-13T22:31:21.383Z
Maybe I am wrong but isn't the mp4 container Practically the same as a QuickTime file and therefore thrown into one (meta-data) box with "MOv"?
Hans Meiser
CC BY-SA 3.0
2016-03-13T22:48:41.850Z
You are almost exactly right.
Duvrai
CC BY-SA 3.0
2016-03-11T18:30:28.073Z
2016-03-11T18:30:28.073Z
Duvrai
<p>I posted this earlier on SuperUser, but realized that this is likely the more appropriate forum for my question.</p>

<p>We have several thousand very large MP4 files that have been encoded over the past decade using Sorenson Squeeze.  Over the past year, there are suddenly a growing number of customers (Universities) with Network/Proxy Server that are suddenly unable to view the videos due to vulnerability described at this link: <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1799" rel="nofollow noreferrer">Apple QuickTime Vulnerability</a>.</p>

<p>Forgive me, I know very little about media and encoding, only that the problem has suddenly started appearing while they view our videos (we use JWPlayer v7 with files hosted at AWS/S3/Cloudfront).</p>

<p>Is there an alternate way of encoding h.264/MP4 that doesn't include any reference or codecs, or whatever it is that flags them as Quicktime files, or some other way to get around this?  </p>

<p><strong>Note:</strong> Our site streams the h.264 MP4 files with JWPlayer - the end users don't open them with Apple Quicktime.</p>

<pre><code>Partial ffmpeg Output for one of the videos in question:

"format": {
    "filename": "c:\\videos\\ABC-123.mp4",
    "nb_streams": 4,
    "nb_programs": 0,
    "format_name": "mov,mp4,m4a,3gp,3g2,mj2",
    "format_long_name": "QuickTime / MOV",
    "start_time": "0.000000",
    "duration": "1632.480000",
    "size": "86937415",
    "bit_rate": "426038",
    "probe_score": 100,
    "tags": {
        "major_brand": "mp42",
        "minor_version": "0",
        "compatible_brands": "mp42isomavc1",
        "creation_time": "2011-07-13 14:02:44",
        "compilation": "0",
        "encoder": "Sorenson Squeeze 5.0"
    }
</code></pre>

CC BY-SA 3.0
2016-03-11T18:24:58.747Z
Do you know some of the firewall brands that are posing this problem? Do you have a way of testing whether a new file will pass or not?
Duvrai
CC BY-SA 3.0
2016-03-11T19:10:34.263Z
As far as I can tell, the vulnerability relates to the operation of the Apple **Quicktime player** version 7.6.6 or older **on Windows**, not JWPlayer on the web. How have you identified the vulnerability as relevant?
Gyan
CC BY-SA 3.0
2016-03-11T22:11:21.050Z
I cannot actually reproduce it, it's all the customers giving us the same report.  Our webserver IS windows, but I don't know what all customer networks are of course.  I know this is vague, but I'm not a media OR network guru so am floundering as such.
GDP
CC BY-SA 3.0
2016-03-12T07:10:59.527Z
I just missed the aws detail. Are you transcoding the videos using [AWS Elastic Transcoder](https://aws.amazon.com/elastictranscoder/)? Do you serve them as a progressive download or streaming? It would also help to have the actual firewall error, the users browser and system version, and your jwplayer embed code.
Duvrai
CC BY-SA 3.0
2016-03-12T16:41:38.770Z
I think it would be helpful to ask your clients which vulnerability exactly is the triggering their firewalls. A quick Google search coughed up around 3-4 serious exploits in QuickTime over the last couple of years, which seem to use different flaws though. If this happened recently, I assume they are referring to this exploit and not the one you linked, which is from 2010. https://threatpost.com/patched-apple-quicktime-vulnerability-details-disclosed/113570/
Hans Meiser
CC BY-SA 3.0
2016-03-12T16:51:42.960Z
In any case I find the demand of the clients a bit strange: they have the vulnerable software installed (or maybe not but their firewall wants to protect their possible outdated QuickTime clients)..  There is nothing malicious in your files.
Hans Meiser
CC BY-SA 3.0
2016-03-12T17:05:16.250Z
Also, since you got rtmp in your questions tags, I assume you are using some kind of streaming server? Or are you just doing http pseudo streaming?
Hans Meiser
CC BY-SA 3.0
2016-03-12T17:14:24.303Z
They're using our JWPlayer page with RTMP Streaming from AWS Customers are basically saying fix it, or we won't buy it....($10K-$50K orders)
GDP
CC BY-SA 3.0
2016-03-13T22:03:05.447Z
I don't know if AWS can do this or expensive the CPU time would be, but you could always real-time transcode the files to a different format until the clients come to their senses and realize it's their players that have the problem, not your streams.
Hans Meiser
CC BY-SA 3.0
2016-03-13T22:19:40.957Z
Or check out this, they claim to be able to Transcode faster than anyone else, also from AWS... I guess your problem should be gone if you had all your files I.e. In WebM or mpeg dash... at least until an exploit triggered with WebM files is found. https://www.bitcodin.com/blog/2015/02/create-mpeg-dash-hls-content-for-amazon-s3-and-cloudfront/
Hans Meiser
CC BY-SA 3.0
2016-03-13T22:28:16.960Z
The whole idea is ridiculous though since you would just be working around their weird ideas of security since any video format could be used to trigger a vulnerability in some player and they cannot exclude all of them unless they consider watching videos over the Internet as insecure per se.
Hans Meiser
CC BY-SA 3.0
2016-03-14T13:58:41.707Z
Rencoding might be the only answer, but the last time we did this to MP4 it took almost 2 months to do the whole collection - there are 12000 full length movies involved, so we're looking for alternate solutions.  If it were only a couple of customers, no big deal, but every month we're getting more and more support tickets and canellations due to the problem.
GDP
CC BY-SA 3.0
2016-03-14T14:12:47.427Z
I think maybe a "legal" solution to this problem is easier to achieve. As the description of the exploits state, the malicious video file needs to be specifically crafted to exploit the vulnerability in the affected players. If your platform is not open to the public and you can assure that no maliciously crafted video file can sneak in to your collection, this should be sufficient as a reassurance for them or not? Then they could Whitelist your service on their firewalls. As far as I see it there is no real alternative, if you search for WebM and exploits, you will also find incidents so I gu
Hans Meiser
CC BY-SA 3.0
2016-03-14T14:13:41.567Z
@Hans, they watch the video on our web page, with JWPlayer - is the QT player even part of the equation?  The manifest of file in the JWP script is being blocked between their browser and our server, (presumably with their proxy server)
GDP
CC BY-SA 3.0
2016-03-14T14:14:22.410Z
And the same could happen with Mpeg dash, even if there is no reported vulnerability as of now. So next month they could say the will block WebM or mpeg dash as well...
Hans Meiser
CC BY-SA 3.0
2016-03-14T14:16:06.123Z
No! QuickTime player is not part if the process as far as I can see. Are you using jwplayer in flash or html5 mode?
Hans Meiser
CC BY-SA 3.0
2016-03-14T18:29:37.883Z
Default Flash/falback to HTML5 - this is only happening with RTMP
GDP
CC BY-SA 3.0
2016-03-14T19:29:15.827Z
Then i completely dont understand the clients concern. Apparently internally Safari uses quicktime as the player when using HTML5 video objects, but i guess RTMP means JWPlayer is using flash for playback. Security-wise Adobe Flash is a problem in general, but it doesnt use Quicktime, i am pretty sure about that. So, again, i think the security concerns of your clients are pretty random IMHO... What is the overall size of your collection in h264, just to have an idea how much the transcoding i.e. in bitcodin would be...
Hans Meiser
CC BY-SA 3.0
2016-03-14T23:17:40.547Z
I agree with you in general,,,transcoding would be about 30TB, so we're leaving that as a last option, and we;ve still to figure out how to reencode them anyways.  WE can't reproduce it, and the 80 or so major customers are leaving it to us to figure out.  I'm baffled, and they simply want it fixed, or will buy elsewhere (very substantial revenue).  The major fear is that the number of customers in this state keeps growing, and they'll all leave.
GDP
CC BY-SA 3.0
2016-03-15T09:53:34.827Z
I really think you should reach out to a client having these concerns and trying to understand better what it is they fear. I mean are they blocking h264 videos in general? Because potentially every h264 file (or WebM or flv for that matter) can be crafted to exploit a vulnerability. So a service offering non public video collections (like yours seem to be) is actually a secure way to allow videos while the stuff floating around on the Web is potentially dangerous. I mean you could even get different virus scanners and scan your files for exploits if that calms them down
Hans Meiser
CC BY-SA 3.0
2016-03-15T14:57:54.017Z
Of course we've done all that....they're schools - no budget to spend time/money helping us identify whatever is blocking the stream, so are just as happy to move to another provider.  It's very frustrating, but thanks :)
GDP
CC BY-SA 3.0
2016-03-16T09:12:42.757Z
The thing is: what is another provider going to do about that issue? MP4 (the container) is very closely modeled after the QuickTime file structure. So mediainfo / Ffmpeg will regard it as a mp4 / Mov container. There is nothing anyone can do about it. WebM has known exploits as has FLV (and most probably MPEG dash as well.) so transcoding your stuff will only calm them down until they learn about the other exploits as well. In the meanwhile creating considerable costs  for you. Personally I would move away from using a flash based player though for several reasons, Security only being one.
Hans Meiser
CC BY-SA 3.0
2016-12-06T05:33:29.593Z
The CISCO advisory is helpful. It says that the vulnerabiity is linked to exploiting `rnet` boxes in MP4. Those are not a mandatory spec of the MP4 file format. In fact, ffmpeg does not write those, so any MP4 files rewrapped with ffmpeg should be exploit-shielded. If the MP4s are still being flagged then your malware detector has a very broad trigger - maybe it's just looking at the extension.
Gyan
CC BY-SA 3.0
2016-12-06T17:16:25.983Z
@Mulvya Well, its not "our" detector...its Universities scattered around the western hemisphere, lol.  We've been using Sorenson Squeeze to do the encoding, but there are a decade worth of legacy files that are in use.  Do you know a way to excluding the rnet boxes when encoding, and/or better yet how to remove them with FFMPEG?
GDP
CC BY-SA 3.0
2016-12-06T17:27:28.730Z
If you run the command in Duvrai's answer, the output won't have that box because FFmpeg's code has no provision to write it. Assuming that the output isn't then altered by something else, that should be it.
Gyan
CC BY-SA 3.0
2016-12-06T17:32:48.707Z
Seems to me I tried that long ago with no luck, but will give it a go again...at least you've answered a question thats been haunting me for several years now - it's the _rnet_ box, now I know what's triggering their detectors!!!
GDP
CC BY-SA 3.0
2016-12-06T18:06:12.687Z
Can you link to one of the files triggering the error? And the text or screenshot of the specific warning that is thrown.
Gyan
CC BY-SA 3.0
2016-12-06T19:47:23.140Z
God I wish it was that easy...wouldn't be here if it was, lol.  Files are on Cloudfront, the Detectors are "God knows where", and its taken me this many years just to get the vague details of the problem from a customer.  But I really, REALLY appreciate the offer.  Maybe one day if I can get those specifics, I'll hunt you down, lol.
GDP
CC BY-SA 3.0
2016-12-06T19:48:13.577Z
If you put your suggestions/directions as an answer, I'll certainly accept it!!
GDP
<streaming><encoding><mp4><h.264><rtmp>
How can I avoid Quicktime Vulnerability with h.264 encoded MP4 files?
GDP
# How can I avoid Quicktime Vulnerability with h.264 encoded MP4 files?

(Asked by: username_0 on 2016-03-11)

I posted this earlier on SuperUser, but realized that this is likely the more appropriate forum for my question.
We have several thousand very large MP4 files that have been encoded over the past decade using Sorenson Squeeze.  Over the past year, there are suddenly a growing number of customers (Universities) with Network/Proxy Server that are suddenly unable to view the videos due to vulnerability described at this link: Apple QuickTime Vulnerability.
Forgive me, I know very little about media and encoding, only that the problem has suddenly started appearing while they view our videos (we use JWPlayer v7 with files hosted at AWS/S3/Cloudfront).
Is there an alternate way of encoding h.264/MP4 that doesn't include any reference or codecs, or whatever it is that flags them as Quicktime files, or some other way to get around this?  
Note: Our site streams the h.264 MP4 files with JWPlayer - the end users don't open them with Apple Quicktime.
Partial ffmpeg Output for one of the videos in question:

"format": {
    "filename": "c:\\videos\\ABC-123.mp4",
    "nb_streams": 4,
    "nb_programs": 0,
    "format_name": "mov,mp4,m4a,3gp,3g2,mj2",
    "format_long_name": "QuickTime / MOV",
    "start_time": "0.000000",
    "duration": "1632.480000",
    "size": "86937415",
    "bit_rate": "426038",
    "probe_score": 100,
    "tags": {
        "major_brand": "mp42",
        "minor_version": "0",
        "compatible_brands": "mp42isomavc1",
        "creation_time": "2011-07-13 14:02:44",
        "compilation": "0",
        "encoder": "Sorenson Squeeze 5.0"
    }

**Tags:** streaming, encoding, mp4, h.264, rtmp

> **Comments:**
> **username_1**: Do you know some of the firewall brands that are posing this problem? Do you have a way of testing whether a new file will pass or not?  
> **username_2**: As far as I can tell, the vulnerability relates to the operation of the Apple **Quicktime player** version 7.6.6 or older **on Windows**, not JWPlayer on the web. How have you identified the vulnerability as relevant?  
> **username_0**: I cannot actually reproduce it, it's all the customers giving us the same report.  Our webserver IS windows, but I don't know what all customer networks are of course.  I know this is vague, but I'm not a media OR network guru so am floundering as such.  
> **username_1**: I just missed the aws detail. Are you transcoding the videos using [AWS Elastic Transcoder](https://aws.amazon.com/elastictranscoder/)? Do you serve them as a progressive download or streaming? It would also help to have the actual firewall error, the users browser and system version, and your jwplayer embed code.  
> **username_3**: I think it would be helpful to ask your clients which vulnerability exactly is the triggering their firewalls. A quick Google search coughed up around 3-4 serious exploits in QuickTime over the last couple of years, which seem to use different flaws though. If this happened recently, I assume they are referring to this exploit and not the one you linked, which is from 2010. https://threatpost.com/patched-apple-quicktime-vulnerability-details-disclosed/113570/  
> **username_3**: In any case I find the demand of the clients a bit strange: they have the vulnerable software installed (or maybe not but their firewall wants to protect their possible outdated QuickTime clients)..  There is nothing malicious in your files.  
> **username_3**: Also, since you got rtmp in your questions tags, I assume you are using some kind of streaming server? Or are you just doing http pseudo streaming?  
> **username_0**: They're using our JWPlayer page with RTMP Streaming from AWS Customers are basically saying fix it, or we won't buy it....($10K-$50K orders)  
> **username_3**: I don't know if AWS can do this or expensive the CPU time would be, but you could always real-time transcode the files to a different format until the clients come to their senses and realize it's their players that have the problem, not your streams.  
> **username_3**: Or check out this, they claim to be able to Transcode faster than anyone else, also from AWS... I guess your problem should be gone if you had all your files I.e. In WebM or mpeg dash... at least until an exploit triggered with WebM files is found. https://www.bitcodin.com/blog/2015/02/create-mpeg-dash-hls-content-for-amazon-s3-and-cloudfront/  
> **username_3**: The whole idea is ridiculous though since you would just be working around their weird ideas of security since any video format could be used to trigger a vulnerability in some player and they cannot exclude all of them unless they consider watching videos over the Internet as insecure per se.  
> **username_0**: Rencoding might be the only answer, but the last time we did this to MP4 it took almost 2 months to do the whole collection - there are 12000 full length movies involved, so we're looking for alternate solutions.  If it were only a couple of customers, no big deal, but every month we're getting more and more support tickets and canellations due to the problem.  
> **username_3**: I think maybe a "legal" solution to this problem is easier to achieve. As the description of the exploits state, the malicious video file needs to be specifically crafted to exploit the vulnerability in the affected players. If your platform is not open to the public and you can assure that no maliciously crafted video file can sneak in to your collection, this should be sufficient as a reassurance for them or not? Then they could Whitelist your service on their firewalls. As far as I see it there is no real alternative, if you search for WebM and exploits, you will also find incidents so I gu  
> **username_0**: @Hans, they watch the video on our web page, with JWPlayer - is the QT player even part of the equation?  The manifest of file in the JWP script is being blocked between their browser and our server, (presumably with their proxy server)  
> **username_3**: And the same could happen with Mpeg dash, even if there is no reported vulnerability as of now. So next month they could say the will block WebM or mpeg dash as well...  
> **username_3**: No! QuickTime player is not part if the process as far as I can see. Are you using jwplayer in flash or html5 mode?  
> **username_0**: Default Flash/falback to HTML5 - this is only happening with RTMP  
> **username_3**: Then i completely dont understand the clients concern. Apparently internally Safari uses quicktime as the player when using HTML5 video objects, but i guess RTMP means JWPlayer is using flash for playback. Security-wise Adobe Flash is a problem in general, but it doesnt use Quicktime, i am pretty sure about that. So, again, i think the security concerns of your clients are pretty random IMHO... What is the overall size of your collection in h264, just to have an idea how much the transcoding i.e. in bitcodin would be...  
> **username_0**: I agree with you in general,,,transcoding would be about 30TB, so we're leaving that as a last option, and we;ve still to figure out how to reencode them anyways.  WE can't reproduce it, and the 80 or so major customers are leaving it to us to figure out.  I'm baffled, and they simply want it fixed, or will buy elsewhere (very substantial revenue).  The major fear is that the number of customers in this state keeps growing, and they'll all leave.  
> **username_3**: I really think you should reach out to a client having these concerns and trying to understand better what it is they fear. I mean are they blocking h264 videos in general? Because potentially every h264 file (or WebM or flv for that matter) can be crafted to exploit a vulnerability. So a service offering non public video collections (like yours seem to be) is actually a secure way to allow videos while the stuff floating around on the Web is potentially dangerous. I mean you could even get different virus scanners and scan your files for exploits if that calms them down  
> **username_0**: Of course we've done all that....they're schools - no budget to spend time/money helping us identify whatever is blocking the stream, so are just as happy to move to another provider.  It's very frustrating, but thanks :)  
> **username_3**: The thing is: what is another provider going to do about that issue? MP4 (the container) is very closely modeled after the QuickTime file structure. So mediainfo / Ffmpeg will regard it as a mp4 / Mov container. There is nothing anyone can do about it. WebM has known exploits as has FLV (and most probably MPEG dash as well.) so transcoding your stuff will only calm them down until they learn about the other exploits as well. In the meanwhile creating considerable costs  for you. Personally I would move away from using a flash based player though for several reasons, Security only being one.  
> **username_2**: The CISCO advisory is helpful. It says that the vulnerabiity is linked to exploiting `rnet` boxes in MP4. Those are not a mandatory spec of the MP4 file format. In fact, ffmpeg does not write those, so any MP4 files rewrapped with ffmpeg should be exploit-shielded. If the MP4s are still being flagged then your malware detector has a very broad trigger - maybe it's just looking at the extension.  
> **username_0**: @Mulvya Well, its not "our" detector...its Universities scattered around the western hemisphere, lol.  We've been using Sorenson Squeeze to do the encoding, but there are a decade worth of legacy files that are in use.  Do you know a way to excluding the rnet boxes when encoding, and/or better yet how to remove them with FFMPEG?  
> **username_2**: If you run the command in username_1's answer, the output won't have that box because FFmpeg's code has no provision to write it. Assuming that the output isn't then altered by something else, that should be it.  
> **username_0**: Seems to me I tried that long ago with no luck, but will give it a go again...at least you've answered a question thats been haunting me for several years now - it's the _rnet_ box, now I know what's triggering their detectors!!!  
> **username_2**: Can you link to one of the files triggering the error? And the text or screenshot of the specific warning that is thrown.  
> **username_0**: God I wish it was that easy...wouldn't be here if it was, lol.  Files are on Cloudfront, the Detectors are "God knows where", and its taken me this many years just to get the vague details of the problem from a customer.  But I really, REALLY appreciate the offer.  Maybe one day if I can get those specifics, I'll hunt you down, lol.  
> **username_0**: If you put your suggestions/directions as an answer, I'll certainly accept it!!  

---

## 1 answers

### Answer by username_1 on 2016-03-11. Score: 2

You can strip most of the metadata off your files using ffmpeg:
ffmpeg -i oldfile.mp4 -c copy newfile.mp4

This will copy the first audio and video streams to a new mp4.

> **Comments:**
> **username_0**: Thx, but just tried it and the `"format_long_name": "QuickTime / MOV",` remains  
> **username_3**: Maybe I am wrong but isn't the mp4 container Practically the same as a QuickTime file and therefore thrown into one (meta-data) box with "MOv"?  
> **username_1**: You are almost exactly right.  

---

