dylib-hijacking vulnerability

gctuser

Not sure if here's the right place for such a notice. I'm also not sure if it's actually a reason for serious concerns. Given the nature of 1Password i thought it might be worth reporting. Here's the facts: DHS reports multiple 1Password components as vulnerable to dylib hijacking - affected components:

• 1Password.app
• 1PasswordNativeMessageHost
• 1Password Extension Helper

On my system there are only a handful of other apps (out of hundreds) that are reported as vulnerable - mostly apps from Microsoft's Office 365-Suite.

---

1Password Version: 7.5
Extension Version: Not Provided
OS Version: 10.14.6
Sync Type: Not Provided

Ben

Hi @gctuser

As you say the nature of 1Password makes it worth while to investigate this sort of thing, even if ultimately it isn't reason for serious concern. I'd be happy to try to help assuage any fears here. From DHS's page:

No. Vulnerable applications are simply applications that a local attacker could abuse to perform malicious actions in a stealthy manner.

I think this is a key point. In order to even attempt anything here, an attacker would need to have access to your device. Now of course thefts and losses do happen, so that isn't entirely outside the realm of possibility, but there are some steps you can take to help mitigate any risk:

1. Make sure you're using a secure unique password for your macOS user account and Apple ID [I know an app that can help with that ;)]
2. Enable FileVault for whole disk encryption: Use FileVault to encrypt the startup disk on your Mac - Apple Support
3. Set macOS to lock your computer when you're away from it: How to display a screen saver on your Mac - Apple Support (make sure the option to require a password is enabled)

It doesn't appear that there is a real viable way to address this in software with the currently available frameworks, and so a pinch of pre-planning for the worst case scenario such as the above steps may not be a bad idea.

I hope that helps. Should you have any other questions or concerns, please feel free to ask.

Ben

ref: dev/apple/issues#3559

gctuser

Hi ben, thanks for the quick reply and for calming the community by ruling out the worst case scenario of remote exploitability.

remote attacks are not the only relevant scenario though - Gatekeeper, Device Guard, SELinux... do exist for a reason.
Probably wouldn't take me long to come up with a wide variety of relevant real world attack scenarios - First thing that comes to mind is the development team's fleet of shared mac minis.

-> what's your take on the generalized conclusion of the linked paper? quote:
"this attack class opens up a multitude of attack scenarios to both local and remote attackers. From stealthy local persistence to a Gatekeeper bypass that provides avenues for remote infections, dylib hijacking is likely to become a powerful weapon in the arsenal of OS X attackers."

I'm not a developer and my assessment's probably highly under-complex - but almost all apps that are mentioned in the paper don't trigger alerts in dhs today -> fixing the issue's apparently no rocket science.

Ben

I don’t have further information to share at the moment, but I do know our security team is looking at this to see if there are additional mitigations we could put in place on our end.

Ben

jpgoldberg

Hi @gctuser,

We are aware of these, but for the specific ones we need some updates to some third party code. To quote from Patrick Wardle's FAQ about DHS checks,

Q: Are there patches available for the vulnerable applications?

A: Due to the fact dylib hijacks abuse legitimate functionality of the core OS, there are not any per-application patches available. In the future, Apple may introduce OS-level security features, such as requiring all libraries to be signed, which may mitigate this attack. [emphasis added]

It's clear that such OS-level security features are on Apple's roadmap. I am having trouble finding which WWDC session it was presented in or in recalling the details, but it appeared to me that Big Sur will be strongly discouraging SDKs from behaving in ways that trigger these warnings. My guess is that those practices will be banned in the successor to Big Sur.