Apple Releases iPadOS 14.7.1 and macOS 11.5.1 with Security Notes for Recent OS Updates

Does anyone know if this closes the “Pegasus” vulnerabilities in iMessage?

There is no mention of it in Security Notes and it would be shocking to see that Apple could react to a 0-day in such record time.

Doubtful. But I just read a Forbes article that millions of mac users are in need to check for malicious files in the LaunchAgent directory.

Check Point urges users to check the usually hidden from view LaunchAgents directory in their library, where they should check for “suspicious” filenames. Delete any that are found, the firm says, giving the example of “com.wznlVRt83Jsd.HPyT0b4Hwxh.plist” as the kind of filename you should look for.

I would need a lot more information before deleting “suspicious” files manually. The article advises to use up-to-date virus/malware checking software.
I use ClamX but am not sure if it currently covers this issue.
I wonder if the latest Catalina/Mojave updates are relevant?

" LaunchServices
Available for: macOS Mojave
Impact: A malicious application may be able to break out of its sandbox…"
It’s a 1.7gB download for Mojave.

TL;DR: It’s a good idea to review your system’s Launch Agents, but look closely at them before deleting anything because they may be perfectly innocent, even if there’s a big scary file name.

For instance, I’ve got one called com.adobe.ARM.202f4087f2bbde52e3ac2df389f53a4f123223c9cc56a8fd83a6f7ae.plist.

At first glance, that looks really suspicious, since it’s got a huge string of hex digits as a part of the name. But if you open it up and read the contents you find:

$ cat com.adobe.ARM.202f4087f2bbde52e3ac2df389f53a4f123223c9cc56a8fd83a6f7ae.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">
<plist version="1.0">
<dict>
	<key>Label</key>
	<string>com.adobe.ARM.202f4087f2bbde52e3ac2df389f53a4f123223c9cc56a8fd83a6f7ae</string>
	<key>ProgramArguments</key>
	<array>
		<string>/Applications/Adobe Reader.app/Contents/MacOS/Updater/Adobe Reader Updater Helper.app/Contents/MacOS/Adobe Reader Updater Helper</string>
	</array>
	<key>RunAtLoad</key>
	<true/>
	<key>StartInterval</key>
	<integer>12600</integer>
</dict>
</plist>

Note the contents of the ProgramArguments key. This identifies the app that will be launched. In this case, it’s the “Adobe Reader Updater Helper.app” that is contained within the Adobe Reader app.

The “RunAtLoad” key is set to true, meaning it will run this when I log in.

The “StartInterval” is set to 12600 seconds (3.5 hours), which means it will re-run itself about once every 3.5 hours. Which is reasonable for a major app to check for updates.

The important thing is that, despite the scary looking file name, this specific Launch Agent is perfectly innocent. (Assuming you actually installed Adobe Reader, of course).

Note also that the mere presence of a Launch Agent doesn’t necessarily mean anything will actually run. The system launcher will still depend on the file’s contents to determine that.

For example, iMazing has one for launching it’s iMazing Mini menu-bar app when you log in. I have disabled the feature (via its preferences), but the Launch Agent file (com.DigiDNA.iMazing2Mac.Mini.plist) still exists. But note the contents:

$ cat com.DigiDNA.iMazing2Mac.Mini.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">
<plist version="1.0">
<dict>
	<key>KeepAlive</key>
	<false/>
	<key>Label</key>
	<string>com.DigiDNA.iMazing2Mac.Mini</string>
	<key>ProcessType</key>
	<string>Interactive</string>
	<key>ProgramArguments</key>
	<array>
		<string>/Applications/iMazing.app/Contents/MacOS/iMazing Mini.app/Contents/MacOS/iMazing Mini</string>
	</array>
	<key>RunAtLoad</key>
	<false/>
	<key>ThrottleInterval</key>
	<integer>10</integer>
</dict>
</plist>

Specifically, note the “RunAtLoad” key whose value is set to false. In other words, the system won’t be launching anything in this file.

In other words, yes, go review the Launch Agents in your system and if something looks like malware, then delete it. But look closely at the contents to make sure it isn’t something innocent.

Although there are over 17,000 signatures for XLoader files in ClamXAV, I can only verify that they do not appear to look for that specific file name, but might be able to identify it by other means. I don’t have a sample yet of that specific component of the infection so can’t fully check for it, but I will return once I’ve been able to get a more definitive answer. I also checked DetectX Swift and Malwarebytes, neither of which are looking for it presently.

Security Updates never look for malware, they only patch vulnerabilities. XProtect and MRT updates cover malware.

XLoader and it’s predecessor trace it’s roots back to 2003 and is mostly been sold to adware agents. The two big deals about this new variant are that the same code can be used against both Windows and Macs (since around December of last yea) & that it is now distributed embedded in a Word document which can be sent as a message attachment. I don’t know that any purchaser has actually used it to steal information off a Mac as that isn’t usually a big moneymaker.

One other thing I should have mentioned. Java is need in order to install this version of XLoader and most users will not have it since it hasn’t been included in macOS since Snow Leopard and very few 3rd party apps still require it. If you don’t have a Java prefs pane in System Preferences and are not still running SL then look no further for this one. Another check would be this Terminal Command:

java -version.

14.7.1 security updates have just been released:

We’ve updated this article with details on iOS 14.7.1, iPadOS 14.7.1, and macOS 11.5.1.

says 14.7.1 fixed unlocking the watch for phones with touch id. someone failed to test that: my phone with face id no longer unlocks my watch. apple quality once again …

I’d try restarting the watch and phone and see if that fixes it; it’s working fine for me on iPhone X (14.7.1) and Series 5 (7.6).

That was one of the primary stated improvements! How could that have been missed in testing?

With respect to Apple quality.
I have to wonder if it is the quality of the input or the quality of the trainers or training materials.

I spent a lot of time on nuclear submarines - training was essential - so was personnel input. As CO I was responsible for the overall product and it required attention - but we got good sailors and training materials - and we were well-trained ourselves. The downside of an error could be pretty steep.

I’ve noticed in interactions with Apple (user since ’84) that in the last few years the first-line support is not even close to what it had been. Escalating is sometimes helpful.

So, I wonder if Apple management has taken their eye off the ball - or its just becoming very hard to get their trainees up to speed.

David

Let’s not turn the discussion of these latest updates into yet another general anecdotal conversation on Apple quality.

Obviously, iOS 14.7.1 doesn’t break iPhone unlocking from the Apple Watch for all Face ID-equipped iPhones because it works fine for @ddmiller. I’m curious if his suggestion of restarting the iPhone and Apple Watch resolves it or not for @henry.crun.

I can tell you that iOS 14.7.1 makes no difference with my Apple Watch 4 and iPhone 12 Pro with Face ID. My iPhone still takes 3-4 (or more) tries to unlock my watch even after restarting them both. They worked perfectly before iOS 14.7

Interesting! I’ve confirmed that both unlocking the Apple Watch from the iPhone and unlocking the iPhone from the Apple Watch work on my iPhone 11 Pro with iOS 14.71 and Apple Watch Series 5 with watchOS 7.6.

I don’t know if it was just me being impatient, but I did seemingly have to restart the watch and the iPhone before the iPhone would unlock the watch. In two tries before I restarted, I’d get the little Unlocking Apple Watch alert at the top of the iPhone screen, but it would go away before saying Unlocked (and the watch would stay locked).

tried the reboot of both devices. the phone still does not unlock the watch. tried multiple times in case it’s just pilot error. nope: error appears to be in apple engineering.
phone is a 12m. watch is an s5.

@applesupport suggested toggling “unlock with phone” in the watch app. did that. no resolution. phone still fails to unlock the watch.
note that the watch will unlock the phone if my mug is masked. bluetooth and the connection between the devices is sorta working.

Unlocking my iPhone XR with my Apple Watch 6, running iOS 14.7.1 and WatchOS 7.6 does not work. It used to work every time, until I installed iOS 14.7, and it still refuses to work with 14.7.1.

I’ve read a few people who were having issues with unlocking the watch (both intermittently and always) with a FaceID iPhone on 14.7.1 had it resolved by un-pairing and re-pairing the watch to the phone.

Apparently there is a similar fix needed for watchOS which was very briefly posted today as watchOS 7.6.1 (18U70), but then quickly removed without explanation.

I can confirm that iOS 14.7.1 fixes the bad CarPlay connection, so once again my iPhone connects right away with my Mazda CX-5.

CarPlay hasn’t worked at all for at least a month, since I think the 14.6 update.

@applesupport suggested wiping and reinstalling the watch. nix that. i can enter its passcode when i put the thing on. they’ll break something else when the next ios14/watchos7 dot release drops but will maybe fix whatever 14.7.1 broke.

must keep the faith, brethren.

btw: at some point a couple of days ago, the phone unlocked the watch. no idea how that worked. it’s declined to repeat the trick.

installed watchos 7.6.1 last night. the phone unlocked the watch this morning.

Many iOS 14.7.1 users are complaining about a No Service message with the update. Are any of you seeing this?

I wouldn’t blame it on the 14.7.1 update specifically, but I have had a similar issue at last three times now (perhaps since 14.5?).

In each instance, it happened after I had lost connection to the cellular network (coverage is bad back at the end of the canyon). Once back in an area where I always had reception, my iPhone 12 mini simply refused to reconnect to the T-Mobile network. Surprisingly, going into Airplane Mode for a minute or so and back did not change anything about the phone’s inability to rejoin the cellular network. What it ultimately took was rebooting the phone.

And now that I think about it, I also remember it happened once at SFO airport when coming back from Boston. My wife’s 12 mini had already reconnected to the cell network 10 min ago, but I was still waiting, toggling, but nothing. Eventually I rebooted my iPhone and then it immediately reconnected to T-Mobile’s network. Odd bug.

I don’t recall lately getting prompted to update the carrier profile. Maybe it’s unrelated. Wonder if it’s affecting people across many carriers.