Closed Bug 1606464 Opened 4 years ago Closed 4 years ago

[macOS] can load unsigned libraries into Firefox (because of disable-library-validation entitlement)

Categories

(Core :: Security: Process Sandboxing, defect)

73 Branch
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1562756

People

(Reporter: yigitcnyilmaz, Assigned: haik)

References

Details

Attachments

(1 file)

2.38 MB, application/x-zip-compressed
Details
Attached file feds.zip

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36

Steps to reproduce:

1- Download "Firefox"
2- Install it to "/Applications" path
3- Download "feds.zip"
4- Extract it
5- Run "start_firefox.sh" script with Terminal
6- Please look at the Terminal and Console

Actual results:

Mozilla Firefox for macOS, loaded a unsigned library

Also, you can see proof of concept video in feds.zip

Expected results:

Please look at the Mozilla Firefox for macOS's entitlement. Mozilla Firefox for macOS (CFBundleExecutable), have Disable Library Validation (com.apple.security.cs.disable-library-validation) as true. This means Mozilla Firefox for macOS can load unsigned libraries.

Note:
Also, This libraries/resources affected by this issue;
crashreporter.app
plugin-container.app
updater.app
firefox-bin
libfreebl3.dylib
liblgpllibs.dylib
libmozavcodec.dylib
libmozavutil.dylib
libmozglue.dylib
libnss3.dylib
libnssckbi.dylib
libnssdbm3.dylib
libplugin_child_interpose.dylib
libsoftokn3.dylib
pingsender
XUL

Haik, based on bug 1593071 I think you're the right person to look at this? Can we avoid this annotation except for plugin-container, perhaps? (I think we might try to load plugin libraries in the parent right now when looking for plugins - we could see how hard it'd be to move that to IPC'd access from the child given some of it is async already - though it may not be worth it to invest in this given the upcoming demise of NPAPI plugins...).

Group: firefox-core-security → dom-core-security
Component: Untriaged → Security: Process Sandboxing
Flags: needinfo?(haftandilian)
Product: Firefox → Core
Summary: Mozilla Firefox for macOS Code Injection → [macOS] can load unsigned libraries into Firefox (because of disable-library-validation entitlement)

(In reply to :Gijs (back Jan 2; he/him) from comment #1)

Haik, based on bug 1593071 I think you're the right person to look at this? Can we avoid this annotation except for plugin-container, perhaps? (I think we might try to load plugin libraries in the parent right now when looking for plugins - we could see how hard it'd be to move that to IPC'd access from the child given some of it is async already - though it may not be worth it to invest in this given the upcoming demise of NPAPI plugins...).

Not same problem.

Thanks for the report. It is a known issue that it is possible to inject a dylib (signed or not) to Firefox with DYLD_INSERT_LIBRARIES and it's something I'm actively working on (bug 1593071 and bug 1593072). This work will should also cover setting disable-library-validation=false for the parent process to block loading of any libraries not signed by Apple or Mozilla. For child processes we have bug 1593389 which will have a longer timeframe. We can't enable these hardening measures until we use different entitlements for the parent process and child processes. (More details below.) This is the motivation for bug 1593071 and bug 1593072. Note that exploiting these requires a compromised system already (for DYLD_INSERT_LIBRARIES) or remote code execution (to load a library dynamically). I think we could declassify this bug and close it as a dupe of 1593072.

With the fix for 1593072, we will be able to block DYLD_INSERT_LIBRARIES and block use of unsigned libraries in the parent process. Only some child process types need DYLD_INSERT_LIBRARIES and to load libraries not signed by Apple or Mozilla so we have bug 1593389 filed to use separate executables for different child process types so we can apply stronger entitlements to web content but still let decoder processes work. For example, Widevine content requires loading the Widevine library in a child process which is signed by Google.

For now, we use production.entitlements.xml from the tree when signing production builds of Firefox and those entitlements apply to the browser process and child processes. As a result, we need to set com.apple.security.cs.disable-library-validation=true and com.apple.security.cs.allow-dyld-environment-variables=true for now because we don't sign using separate entitlements for the child processes. We need to disable library validation because child processes load Flash and Widevine libraries which are not signed by Apple or Mozilla. We need to allow dyld variables because the Flash child processes depends on DYLD_INSERT_LIBRARIES to load an interposing library we use.

We have landed some entitlement files in the tree to being work on this (bug 1593071), but they are not yet used and do have some mistakes I'll be fixing in a follow-up. We need new codesigning code in automation (bug 1593072) to apply the separate entitlements. I'm working on the new codesigning python code on https://github.com/hafta/codesign-tree to be used in automation and am testing with the more strict entitlements. I've been testing with the parent set to allow-dyld-environment-variables=false and just did some tests with disable-library-validation=false (motivated on by this report).

@Yigit, if you're interested, I could provide you with a Notarized version of Firefox with the strengthened and separate entitlements for you to validate that you can no longer inject dylibs into.

Assignee: nobody → haftandilian
Flags: needinfo?(haftandilian) → needinfo?(yigitcnyilmaz)
See Also: → 1562756

Hello,
I'm waiting

Flags: needinfo?(yigitcnyilmaz) → needinfo?(haftandilian)

(In reply to Yiğit Can YILMAZ from comment #4)

Hello,
I'm waiting

Sent.

Flags: needinfo?(haftandilian)

Thank you for mail and contacting me. Your build seems as good. I think it should be. It is impossible to avoid this problem completely. Becase for Flash Player and plugins. Disable library validation entitlement added to all resources in offical build. This should change (i think). Disable library validation entitlement should be added to only resources that load Flash Player and Plug-ins.

Thank you,
Yiğit

Flags: needinfo?(haftandilian)

(In reply to Yiğit Can YILMAZ from comment #6)

Thank you for mail and contacting me. Your build seems as good. I think it should be. It is impossible to avoid this problem completely. Becase for Flash Player and plugins. Disable library validation entitlement added to all resources in offical build. This should change (i think). Disable library validation entitlement should be added to only resources that load Flash Player and Plug-ins.

Thank you,
Yiğit

Thank you for testing the build and confirming injection doesn't work. The codesigning changes tracked with bug 1562756 will address this and so I'm going to close this bug as a duplicate of 1562756.

This bug does not need to remain private. Yes it's possible to load an unsigned shared library if you have remote-code-execution or if you can launch Firefox with DYLD_INSERT_LIBRARIES on the target system, but this was typical of all apps prior to Mojave when these hardening entitlements were introduced for app use.

Flags: needinfo?(haftandilian)
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE

Unhiding per comment 7.

Group: dom-core-security
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: