Tenable has discovered a possible vulnerability in the LaunchServices framework – the 'lsd' service in particular. The vulnerability is a local denial-of-service. We have verified this vulnerability is present on the latest versions of macOS at the time of this submission. This service is used to determine various behaviors during the launch of a given file or application. For example, file extension association.
In short, it does not appear that there is any size limitation applied to entries for the LSDatabase structure. As this structure is stored on disk, loaded into memory, and updated automatically as applicable files/structures hit the disk (such as being download from the internet, copied, etc.), this could lead to resource exhaustion on the host as well as a crash of the lsd service.
As an example scenario to reproduce this behavior:
- Create and build sample Cocoa application via XCode
- The application does not need any implemented functionality. The purpose of this is to create an appropriate app structure
- Build and locate the sample app
- In Info.plist (<app name>.app/Contents/Info.plist), ensure that there is data that lsd makes use of. For this example, we'll use CFBundleURLSchemes. See the following for an example Info.plist:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<string>Copyright © 2019 James Sebree. All rights reserved.</string>
- Modify this file (the value of "this_is_a_test_URL_scheme" specifically in this scenario, though other fields also cause this issue) to be excessively large (in excess of a gig)
- Copy and paste the entire app folder to trigger the issue. This can be triggered in many different ways, but for proof-of-concept purposes, a copy and paste will suffice.
As soon as the paste finishes, lsd will begin processing the app. It will copy the Info.plist into memory, store this excessively large value in memory, and subsequently store the values in the LSDatabase. Accessing this value, storing new values in memory, or just periodic checks within this service are enough to cause a segfault and crash the service, which causes launchd to spawn a new instance of lsd. This again loads the database into memory. Over time, this can exhaust system resources by using all available memory, and causing swap space to grow large enough to cause the system to run out of allotted storage. This behavior persists through reboots as the database is stored on disk and lsd is launched at startup.
Beyond this denial-of-service impact of the host, Tenable is unaware of any further impact this attack vector may allow. Since it appears that the database lsd uses is available from userspace and given the lack of size limitations, it may be possible for a dedicated attacker to abuse this functionality as a persistence mechanism for malware or other attacks, but would have to have some other attack vector in order to use this functionality.
Apple has disputed this as a security vulnerability as they believe it is a simple case of resource exhaustion. While Tenable researchers agree that this is a low-severity and non-serious issue, we believe that this issue poses security risk - even if minimal - and could be fixed simply by adding some sort of upper bounds to LSDatabase entries or other similar mitigation to prevent resource exhaustion.