VLC vs browser for unvetted audio/video files

[joelewing]

I should start by saying that I am by no means a security expert, just a curious bystander.

I was wondering if opening a mp4 or mp3 in Google Chrome is safer than opening it in VLC, given the rigorous sandbox that Chrome has.

Any thoughts?

[beerisgood]

What’s wrong with using macOS internal program for that? VLC isn’t even available in AppStore so this is a security risk itself.

[joelewing]

I agree with you, it seems preferable to pick a program that uses the App Sandbox. Apple Music and VLC do not. QuickTime does (though it looks like QuickTime is not "hardened"). But I was wondering if the sandboxing provided by Chrome was even more robust than what Apple offers.

[beerisgood]

Was this test under a Mac with Intel CPU? Wonder how the result is with Apple M1.

i also don’t know how this tool you used check for that stuff listed but maybe „hardening“ isn’t needed for sandboxed programs?

[joelewing]

This is from an Intel Mac, yes. The app is called Apparency. Hardening refers to turning off capabilities that the program does not require. https://www.mothersruin.com/software/Apparency/use.html#code-info-signature

It seems that the App Sandbox is more restrictive than hardening but doesn't cover all of the same capabilities. It's worth noting as well that apps from places outside of the App Store can still enable the App Sandbox. This was the case for the Apparency app itself.

[drduh]

I can say from experience this is true for PDF files: it is safer to open them in Chrome where sandboxing is stronger than in native or third party apps. It is probably quite good at sandboxing other file types as well, but we should hear from an expert and make a recommendation accordingly. Thanks for bringing this up.

[reactive-firewall]

🤷🏻 Caveat: I should start by disclaiming any expertise on the security details, including for mp4 files. Let's say I'm also a curious bystander...

🤔 I see a few parts to this question that can lead to different answers: Apple likes to use their Core-Audio throughout macOS and opportunistically (can I say aggressively) seem to convert media to ac3 (in an mpeg v4 container) core audio for their hardware (namely Safari and the ShareKit features alter audio to mp4) so the browser may not be the only issue rather both the browser handling and subsequent handoff to the audio engine should not be one and the same.

💭 For the browser handling side, if you are concerned about unvetted mp4 files I'd recommend the usual secure environment (hardened VM or the like) file download (for example curl straight to a file - guru's to weigh in on the details) from there ffmpeg has a probe tool for getting to the bottom of how the mp4 file is actually crafted called 'ffprobe' (EDIT: I think VLC even uses ffmpeg as one of it's internal libraries)

❔ for the transfer to the core-audio library I'd actually welcome any thoughts and knowhow on the security considerations of MacOS's core-audio components. Especially in regards to any secure configuration of them.

[drduh]

We could benefit from additional expertise on this topic, or add general information on additional sandboxing/virtualization techniques for opening some file types.

[kimg45]

So looked into it a bit and there's some considerations here:

1. VLC requires you to install Rosetta which adds extra attack surface and performance overhead, they seem keen on backwards compatibility with older versions of macOS so I don't see this changing anytime soon.
2. I don't really want to trust third party tools for information like this so I found out that you can see which apps are sandboxed in Activity Monitor by right clicking the columns and checking "Sandbox". You can see that Chrome doesn't use the App Sandbox, although they have their own strong sandbox so I'm sure it's not an issue. Much more concerning is the fact that VLC doesn't use the sandbox, which puts you at significant risk if your threat model includes malicious media files. As @beerisgood pointed out, this disqualifies it from being listed in the App Store, which also means you don't get the nice autoupdates that are handled by your system, you have to rely on their updater which will only install updates with user interaction afaict. RIP if you haven't opened VLC in a while and suddenly try to open a malicious file; you'll be opening it in a severely outdated version of VLC.
3. There is also a "Restricted" column in Activity Monitor. As far as I can tell, this lets you see which processes are "restricted" which is a flag that can be set on binaries that prevents code injection via macOS's dynamic linker. VLC seemingly lacks this protection according to Activity monitor, although I don't really understand this stuff that well so someone can correct me here. All of the other programs have this feature enabled.
4. If you run the command: codesign --display --verbose /System/Applications/Music.app You can see what the developers set under "flags". So if you see (runtime) then they enabled the hardened runtime (this is a requirement for notarization) which VLC does which is good. Although you can see that the runtime version for VLC is much lower than any of the other apps in question which I'm sure comes with security implications. If you check QuickTime Player, it shows that it in fact does have Hardened Runtime enabled so it seems the third party tool you were using gave you bad info. As far as notarization goes, of course the official Apple apps don't need it since they're already reviewed by Apple in house.
5. Default apps on macOS benefit from the Signed System Volume so it's read-only and verified on boot by the hardware root of trust, so I have a tendency to prefer default apps for most things.
6. Also consider how often it's updated and whether the app is still being updated. Looking at VLC's Github, it seems like they haven't had a commit in over a year???? Very concerning to say the least and absolutely not what you want if security is a concern.

So, in conclusion, 1. don't trust third party apps to tell you accurate info on your system and 2. can't say which of these options is objectively the best but VLC is pretty much objectively the worst.

I'd probably change the guide to recommend opening files in QuickTime Player rather than VLC.

[beerisgood]

Point 3 & 4: a much easier solution for the user is using the Activity monitor and checking (after adding the column) the Sandbox/ Restricted status.

https://developer.apple.com/documentation/security/app_sandbox/protecting_user_data_with_app_sandbox#4098972

[kimg45]

Point 3 & 4: a much easier solution for the user is using the Activity monitor and checking (after adding the column) the Sandbox/ Restricted status.

https://developer.apple.com/documentation/security/app_sandbox/protecting_user_data_with_app_sandbox#4098972

Yes, unfortunately it doesn't show whether the Hardened Runtime is enabled. You could just try to run it and see if Gatekeeper blocks you I suppose since all notarized apps are required to enable it, that's probably the easiest way.

[beerisgood]

Point 3 & 4: a much easier solution for the user is using the Activity monitor and checking (after adding the column) the Sandbox/ Restricted status. https://developer.apple.com/documentation/security/app_sandbox/protecting_user_data_with_app_sandbox#4098972

Yes, unfortunately it doesn't show whether the Hardened Runtime is enabled. You could just try to run it and see if Gatekeeper blocks you I suppose since all notarized apps are required to enable it, that's probably the easiest way.

Are you sure? For me that sounds like „Sandbox“ in activity monitor is Hardened Runtime.

[kimg45]

From the documentation:

The Hardened Runtime, along with System Integrity Protection (SIP), protects the runtime integrity of your software by preventing certain classes of exploits, like code injection, dynamically linked library (DLL) hijacking, and process memory space tampering. To enable the Hardened Runtime for your app, navigate in Xcode to your target’s Signing & Capabilities information and click the + button. In the window that appears, choose Hardened Runtime.

And the App Sandbox:

The operating system creates a container directory when launching your sandboxed app, to which the app has unrestricted read and write access. The sandboxed app doesn’t have unrestricted access to the user’s home folder.

So basically the Hardened runtime disables stuff like Just-In-Time compilation that has to do with the app itself, and the App Sandbox restricts its access to other files and things on your system. They're listed as separate things in the documentation and it only mentions the App Sandbox being shown in Activity Monitor, not Hardened Runtime.

So yes currently the easiest way to tell is to just try and run it and see if Gatekeeper blocks you.

[beerisgood]

Alright. Thanks for the Correction.