2

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"
    }
  • 1
    I just missed the aws detail. Are you transcoding the videos using AWS Elastic Transcoder? 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 Mar 12 '16 at 7:10
  • 1
    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. threatpost.com/… – Hans Meiser Mar 12 '16 at 16:41
  • 1
    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. bitcodin.com/blog/2015/02/… – Hans Meiser Mar 13 '16 at 22:19
  • 1
    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 Dec 6 '16 at 5:33
  • 1
    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 Dec 6 '16 at 17:27
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.

  • Thx, but just tried it and the "format_long_name": "QuickTime / MOV", remains – GDP Mar 11 '16 at 22:09
  • 1
    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 Mar 13 '16 at 22:31
  • You are almost exactly right. – Duvrai Mar 13 '16 at 22:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.