Detecting and affecting Lockdown Mode in macOS Ventura

Lockdown mode is new feature for macOS Ventura and for many MacAdmins we’ve been wondering how to detect this state. Why? Lockdown mode affects how macOS and Mac apps behave. This is something a helpdesk might like to know when trying to troubleshoot an issue. Also, due to some ambiguous wording by Apple, they made it seem like MDM Config Profiles could not be installed at all when in Lockdown mode, however this is not always the case. The hunt was on!

Detecting Lockdown Mode

I was looking everywhere last week: ps process lists, nvram, system_profiler, kextstat, launchctl, sysdiagnose, a defaults read dump, etc. I was looking high and low for “lock” “down” and “mode” and I got a hit in the com.apple.Safari domain in the sandboxed ~/Library/Containers/Safari path. While it turns out that Safari will in some cases write the button label LockdownModeToolbarIdentifier to that pref domain, it requires Safari to be launched and for the toolbar to be in non-default layout, otherwise the label name is never written! So that was a dead end.

Then a little birdie on MacAdmins pointed me in the right direction and blogged about it and wrote a Jamf extension attribute! 😅 Turns out I had missed the value sitting at the top of the defaults read dump! (d’oh) It was there the whole time in .GlobalPreferences, I just hadn’t done a diff like I should have! That would have revealed the key uses the LDM acronym/mnemonic: LDMGlobalEnabled Funnily enough, when I searched for this key on Google I got 5 hits and all of them for iOS, like this one at the Apple dev forums. However they were all about Swift and iOS, here’s how to do it in shell for the current user:

defaults read .GlobalPreferences.plist LDMGlobalEnabled 2>/dev/null

It’s a boolean value, that will not exist if Lockdown mode has never been enabled, when enabled it will report 1 from defaults and when disabled the key will remain and report 0. What stands out is that this is a per-user preference. Since it makes you reboot I had supposed it was a system-wide setting but sure enough if you log out and into another user, Lockdown mode is disabled. Perhaps that makes sense but I’m not quite sure about that?

Affecting Lockdown Mode

This totally blew me away: You can enable and disable macOS Lockdown mode by writing to your .GlobalPreferences preference domain!

#turn lockdown mode off
defaults write .GlobalPreferences.plist LDMGlobalEnabled -bool false
#turn lockdown mode on
defaults write .GlobalPreferences.plist LDMGlobalEnabled -bool true

That’s right, it’s not written to a rootless/SIP protected file like TCC.db! Just run the command as the user and it’ll turn toggle the behavior for most things. Here’s some details of my findings:

  • Configuration profiles – a restart of System Settings is not required, it will prohibit the manual installation of a .mobileconfig profile file. When Apple says “Configuration profiles can’t be installed” this is what they mean: User installed “double-click” installations of .mobileconfig files cannot be done. When they say “the device can’t be enrolled in Mobile Device Management or device supervision while in Lockdown Mode”, this only applies to these user-initiated MDM enrollments using a web browser that downloads .mobileconfig files. Lockdown mode does not prohibit enrollment into MDM that’s assigned via Apple Business Manager (ABM/DEP). You can initiate enrollment with the Terminal command: sudo profiles renew -type enrollment A Mac in Lockdown mode will be able to successfully enroll into an MDM assigned by ABM. Once enrolled, new Config Profiles can also be installed via that same MDM, even in Lockdown Mode.
  • Messages – a restart of Messages is not required, all messages will be blocked immediately, attachments or not. I’m not sure if that’s a bug or not since Apple only mentions attachments, not plain messages. It does not matter if the sender is in your Contacts or whether you have initiated contact with them before (like in Facetime). Messages will be delivered to any other devices not in Lockdown mode. If Lockdown mode is turned off, those blocked messages may be delivered if sent recently enough but will appear out of sequence. For example, a device that never had Lockdown Mode turned on would see messages: 1,2,3,4,5 while a device that turns it on and then off would see: 1,2,5,3,4
  • Facetime – restart not required, it will immediately begin blocking calls from anyone you have not called previously from that device. Unlike Messages though, it will show a Notification of the blockage.
  • Safari – app restart required. This differs from everything else, however Safari also gives the best visual indications that Lockdown mode is enabled! On the Start Page you’ll see “Lockdown Ready”, once at at website you’ll likely see “Lockdown Enabled” unless you’ve uncheck Enable Lockdown Mode in the top menubar SafariSettings for <site>… in which case you’ll see “Lockdown Off” in red.
Safari’s Lockdown Mode Toolbar states
  • Safari – Another subtle visual cue of Lockdown mode, that aligns with Apple’s “web fonts might not be displayed” guidance, can be seen on a Jamf user-initiated MDM enrollment screen, instead of a check mark you’ll see a square, take heed and turn back now! Since once you get the .mobileconfig files and fumble your way to System SettingsPrivacy & Security, scroll to the bottom of the list to Profiles (UX gripe: it used to just open the dang panel when you double clicked on them!) you’ll be blocked from installing it as seen above.
  • System Settings – an app restart is required for Privacy & Security to reflect the current state of LDMGlobalEnabled, if it was on and you disable via defaults once you launch System Settings again, it’ll let you turn it back on with a reboot and everything!

Wrapping Up

I didn’t try out the other lockdown mode behaviors for things like new Home management invitations or Shared Albums in Photos. Still it’s quite surprising that despite the System Settings GUI making you reboot to turn it on, Lockdown mode is a per-user setting that can seemingly be enabled and disabled dynamically with a simple defaults command run by the user. With the exception of Safari and System Settings it does not require Messages and Facetime to restart! There might be other caveats, it’s hard to tell. Perhaps this is all in the realm of “works as designed” for Apple but when you, the customer, don’t know what that exact design is, it can be quite a surprise!

Update: Looks like they started explaining a bit more about what happens when you enabled Lockdown Mode in macOS Sonoma

One more (unrelated) thing…

Update: As of Dec 13, 2022 Bug 174931 – Implement RegExp lookbehind assertions has been marked “Resolved” and the extensive pull request has all the gory details of the extensive refactoring that was done to implement this. 🎉 Thanks Michael Saboff! 🙏 Now when this will make it into Safari…. we’ll see.

Update 2: Safari 16.4, released March 27, 2023, now supports RegExp lookbehind assertions!

Since this post might get a few eyeballs, I’d also like to shine a light on the perplexing fact that Safari is the only browser that still doesn’t support the four year old ES2018 feature of RegExp lookbehind assertions?! I mean, sure it was a Google engineer who kindly filed this heads up to the WebKit team back in July of 2017 when it was a draft and a full year before it was ratified (Bug 174931 – Implement RegExp lookbehind assertions) but even a silly corporate rivalry couldn’t explain the seeming obstinance in letting this feature languish. I don’t get it, it just doesn’t make sense! There’s a nicely visualized page of where things stand and Safari is keeping company with IE 11 on this one.

Make these red islands green, Apple!

So take a look at the comments on the WebKit bug, some are quite funny, others just spot on, and there’s even one from yours truly. Perhaps add your own? Maybe when a bug gets 100 comments something special happens and we all get cake? 🎂

Jamf & FileVault 2: Tips & Tricks (and more)

Raiders of the Lost Feature Requests

So there’s this old feature request at Jamf Nation (stop me if you’ve heard this one…) it’s almost 6 years old: Add ability to report on FV2 Recovery Keys (and/or access them via API) In fact, maybe you came here from there, watch out don’t loop! Continue!

The pain point is this: Keys are sent back to Jamf Pro (JSS) but then can only be gotten at manually/interactively through the web interface, not via API nor another method. For cases of mass migration to another JSS it sure would be nice to move those keys over rather than decrypt/re-encrypt. Well, I’ve got a few insights regarding this that I’d like to share that may help. ‘Cuz hey it’s 2020 and we’ve learned that hoarding is just silly.

Firstly, it should be pointed out that neither ye olde “Recovery Key Redirection” payload nor it’s replacement “Recovery Key Escrow” are needed to get keys to the JSS. There is another method and it’s what is used by the built-in “Filevault Encryption” policy payload to get the keys back to your JSS. Jamf references this method in this old script at their GitHub. I revamped the core bits a couple years ago in a (nearly 7 year old) feature request: Manually Edit FileVault 2 Recovery Key

Telling the JSS Your Secrets

The takeaway from that is to realize we have a way to explicitly send keys to the JSS by placing 2 XML files in the /Library/Application Support/JAMF/run folder: file_vault_2_id.xml and file_vault_2_recovery_key.xml. Also note, Jamf has updated the process for the better in the last two years: a jamf recon (or two) is no longer required to send the key and validate it, instead JamfDaemon will send it immediately when both the files are detected. Which is nice, but it’s the subsequent recon validations where we have an opportunity to get grabby.

Cold Lamping, Hard Linking

So here’s the fun part: When recon occurs there’s lots of file traffic in /Library/Application Support/JAMF/tmp all sorts of transient scripts hit this folder. What we can do is make hard links to these files as they come in so when the link is removed in tmp another exists elsewhere and the file remains (just in our new location). EAGrabber.sh does exactly that (and a little bit more)

EAGrabber.sh can be easily modified to narrow it’s focus to the FileVault 2 key only, deleting the rest. What you do with the key is up to you: Send it somewhere else for safe keeping or keep it on device temporarily for a migration to another Jamf console. A script on the new JSS could then put that key on-disk into file_vault_2_recovery_key.xml file which will then import and validate, no decrypt/recrypt necessary. Hope this helps.

Cuidado ¡ Achtung ! Alert

Jamf admins take note: Do you have hard coded passwords in your extension attributes or scripts? If so, then all your scripts are belong to us. Now, go read Obfuscation vs. Encryption from Richard Purves. Read it? OK, now consider what happens if you were to add a routine to capture the output of ps aww along with a hard-linking loop like in EAGraber.sh. If you are passing API credentials from policies via parameter, then ps can capture those parameters and even if you try and obscure them, if we’ve captured the script we can de-obfuscate them. This is a good reason to be really careful with what your API accounts can do. If you have an API account with Computer record Read rights that gets passed into a script via policy and you use LAPS, then captured API credentials could be used to harvest LAPS passwords via API. Keep this in mind and we’ll see if any meaningful changes will occur in recon and/or the script running process in the future (if you open a ticket you can reference PI-006270 regarding API credentials in the process list). In the meantime make API actions as short lived as possible and cross your fingers that only you, good and noble #MacAdmins read this blog. 🤞

Track and Tackle com.apple.macl

UPDATE: As of Big Sur (macOS 11) the com.apple.macl extended attribute can be removed using: xattr -rd com.apple.macl <file/folder>


Starting in macOS Catalina, an extended attribute (XA) named com.apple.macl is being added to the files and folder you work with. What does it do? How does it work? When does it get added? Where is the documentation?

All these are good questions, but there’s no official documentation. A good start is this assemblage of articles, here’s the highlights from that page and a few more…

Apple talked about this vaguely in their WWDC 2019 session 701, “Advances in macOS Security“, the Files and Folders fun starts at 21:21 but there’s nothing really about the implementation

Tom Bridge talked about com.apple.macl to the Penn State Macadmins back in August before Catalina’s release. He’s one of the first to notice this XA (and talk about it). Although, he says that curl will add this XA to downloads, it thankfully does not. Most likely it happened when he dragged it to Terminal or performed some other action on it.

Howard Oakley of the prolific Eclectic Light Company blog kicks the tires a bit more and finds some interesting quirks, as he always does.

Jeff Johnson though, really hits the nail on the head in illustrating what’s going on when you simply drag and drop a file or folder into Terminal and com.apple.macl is appended. He dropped this, December 18th and well… the holidays were around the corner and we all had better stuff to do!

It’s 2020 now and time to come back around to this. A very helpful post in the Apple Dev forums from an Apple employee, Quinn “the Eskimo”, decodes the data structure a bit more as well as what some of the conditions for having this XA appended are:

When a user selects a “protected” file or folder in an NSOpenPanel in a non-sandboxed app on Catalina, consent is inferred and the app can access it.

It seems that 01 00 is a header of some form and … is a UUID associated with my test app.  I dug into how that UUID is set up and, well, it’s complex, and more of an implementation detail than I care to go into here on DevForums.

https://forums.developer.apple.com/thread/124121

Well, I would have loved the complex implementation detail! But I’ll tell you this: The app UUID in com.apple.macl is unique to EVERY computer. Jeff Johnson was right when he said: “The macl is effectively untraceable“.

However you can begin to see the shape of things when you write a tool to output the UUID in CSV like I have. Behold maclTrack.command

Run it in Terminal, give it files or folders as arguments, it’ll report on them, you can even specify a maximum depth for folders (-d) and silence reporting on items lacking com.apple.macl (-s), pipe it into tee to see the output and write it to a file.

This poor file got clobbered by multiple app UUIDs

Something interesting I noticed from using this tool is seeing the “Header” as Quinn called it, differ from 0100 to 0200. I believe 0200 is for drag and drop operations vs. a regular save which results in 0100.

Again, the app UUIDs you see on the files on your Mac will never be seen on another Mac ever – why? Because UUIDs are meant to be truly unique. Have you read the man page for uuidgen? They ain’t eff’in around!

 The uuidgen command generates a Universally Unique IDentifier (UUID), a 128-bit value guaranteed to be unique over both space and time.

Apple man page for uuidgen

So what’s the point of having a long lived XA that you can’t get rid of and that’s only useful on your local Mac? If it’s a permissions granting XA (the opposite of com.apple.quarantine which imposes restrictions) then why not let the user remove it? In some ways it’s a cross computer file tracking mechanism, albeit “anonymized”. Perhaps allowing it’s removal though (aka writing “nothing” to the XA) also allows for something to be written? This is where I could get in trouble speculating, it’s just a guess.

Perhaps you’ll forgive me that, since I have found a way to clear com.apple.macl without disabling SIP! Zip it. No, not the one spawned Finder’s “Compress” menu item, I mean /usr/bin/zip! I noticed command line zip would obliterate XAs during a project many years ago and it still does my friends! So behold maclTackle.command

This script has considerably less engineering to it because it’s a PoC and I’m really don’t want to take responsibility for something going awry should you try to clear com.apple.macl on your entire Desktop folder (no I haven’t tested that). But it will strip the XAs off a file that’s for sure! NOTE: USE A NON-IMPORTANT FILE with this script (make a duplicate). The script will overwrite the original (don’t like the behavior? It’s a script: Comment it out!)

🎶 Gonna wash that macl right outta my file… 🎶

Apple may come along and close this loophole now that it’s been pointed out or perhaps they won’t since they’d have to publish the modfication? Perhaps they’ll continue to purge “undesirable” binaries from macOS? They say they will stop shipping Python, perl and ruby in macOS some day and you know what xattr is written in? That’s right Python! ¯\_(ツ)_/¯

Alright, come and get it while the gettin’s good! Thanks for reading!

Java 8 Update 40 Installer App Fun!

So perhaps you saw my previous post: Java 8 without the Adware (aka Java8Unjunker)?

Java 8 U40 App

Good stuff eh? There was something in there that got me thinking: If they didn’t sign the package, is the app doing any integrity checks on the package inside either? Hmmm let’s see…

Voice over: We’ve secretly replaced the JavaAppletPlugin.pkg package with QuickTime 7 let’s see if it can tell the difference!
Not Java

Here we go!
Sure let me authenticate right when you run before any confirmation of action – why not!? (Ugh, bad form already.)

Java8 Auth

Safe and Easy

Oh OK, “safe and easy” – I love it! But just to clarify…
By “easy” you mean: Checking lots of trust boxes and clicking “Run” buttons a lot to get a Java apps working (plus crossing your fingers)?
By “safe” you mean: a steady stream of high scored CVEs with low complexity? Or even running in Unsafe Mode when needed?

OK what’s next?

Ask

Oh dear God no! No Ask.com. UncheckNext.

Oh, right, away we go, I gave you my password at the door. Installing Java are we?
Java8 InstallingInstalled

OK I’ve successfully installed Java then if you say so… I guess I that’s proof alright!
It then takes you to the Verify Java page — but who cares about that!

What does /var/log/install.log say about what was installed?

QT7 install Java8

 

Yep it installed the QuickTime7 package we put in there and Java Updater 40.app was none the wiser.

So in conclusion… That’s a really nifty “Ask Toolbar installer” with arbitrary package installer Oracle. It’s also a great delivery vehicle for malware by nefarious folks. Heck, bundle Java along with your Trojan and the “Verify Java” page would open too! Sheesh. Is the Ask contract that lucrative? Oracle made $38 billion in revenue last year, IAC the parent of Ask.com pulled in $3 billion. I guess IAC have got money to spend and Oracle will take it (but not invest in more secure installers?)

Notes: The first attempt used a QuickTimePlayer7.6.6_SnowLeopard.pkg with an expired certificate, that halted the install. The 2nd attempt I stripped out the expired certificate. It worked. The 3rd time I downloaded a newly signed version from Apple, that too worked.

Parting note for Oracle:
Sign your critical packages! If you insist on using your glorified “Ask Toolbar installer app” to do this, then require that it verify the package integrity in some way, Orable! (heh, that was a typo but I like it: Orable, ha!)

Open JavaAppletPluginJava8 No Lock

 

Update: Oracle is now signing the package within and the installer can no longer be duped into running an arbitrary package. The version when this article was written was 1.8.40.25, it is now 1.8.40.27.

Java 8 Signed
It’s signed now!

 

Damaged Java 8
Attempted JavaAppletPlugin.pkg Replacement

 

Java 8 without the Adware (aka Java8Unjunker)

So you’ve heard the Ask toolbar is now bundled with Java 8 Update 40 for the Mac?
Yep, apparently it is.

Ask

Fortunately there’s a simple workaround! Let’s take control of our Macs and do a little spelunking into this new installer app.

Right or Control-Click the Java 8 Update xx.app and choose Show Package Contents

Show Package Contents

Navigate into Contents then Resources folder
Eureka we’ve found it: JavaAppletPlugin.pkg
JavaAppletPlugin_LocationLet’s run it!

Gatekeeper_Java8

Aw snap. It seems the package isn’t signed and Gatekeeper is not happy about that. I’m flabbergasted that they’d sign the installer app but not the package inside? (Update: I’m really flabbergasted!)

Control or right-click on JavaAppletPlugin.pkg and choose Open

Java 8 PKG Open

Click Open

Open JavaAppletPlugin

Here we are. Your unsigned Java installer awaits.

Installer

Alternately… Java8Unjunker.command

script I just made to do the same thing plus some other nice things like: name the package and un-quarantine it. Of course being a script it’s not signable! Gatekeeper will balk if it’s on. You’ll need to right-click and choose Open as before.

Shell

Drag in your Java 8 Updater xx.app

Unjunker1

Press Enter.
Voilà! A folder with your package ready to double-click and go.

Unjunker2

Enjoy.

TMI…

#!/bin/bash

#Java 8 Unjunker - Joel Bruner
#Simply moves the JavaAppletPlugin.pkg package out of the installer app (which installs the Ask Toolbar) to the Desktop, renames and Un-Quarantines it

#touch file for debugging
[ -f /tmp/debug ] && set -x

#take command line argument too
sourceApp="$1"

#check to see if path provided is present and valid
#otherwise get the path
while [ -z "$sourceApp" -o ! -d "$sourceApp" ]; do
echo -n "Drag in Java 8 Update xx.app and press enter: "
read sourceApp
done

#get the version from the app
sourcePKGVersion=$(defaults read "$sourceApp"/Contents/Info CFBundleVersion)

#make Desktop folder and copy pkg to it, renamed
echo "Creating Directory ~/Desktop/Java $sourcePKGVersion"
mkdir ~/Desktop/"Java $sourcePKGVersion"
echo "Copying JavaAppletPlugin.pkg to ~/Desktop/Java $sourcePKGVersion/JavaAppletPlugin_${sourcePKGVersion}.pkg"
cp "$sourceApp"/Contents/Resources/JavaAppletPlugin.pkg ~/Desktop/"Java $sourcePKGVersion"/JavaAppletPlugin_${sourcePKGVersion}.pkg

#since Oracle doesn't sign the pkg just the .app we need to strip the quarantine xa off to suppress the warning
xattr -d com.apple.quarantine ~/Desktop/"Java $sourcePKGVersion"/JavaAppletPlugin_${sourcePKGVersion}.pkg

echo "Java Unjunked. Opening Folder."
open ~/Desktop/"Java $sourcePKGVersion"

 

 

 

Naming Conventions! Please, Apple?

Apple, there was a time when your updates had naming conventions for the various platforms there were targeted for. Suffixes like Tiger, Leopard, Snow, etc. made it easy to identify for what platform an update package was intended.

SnowSecurityUpdates
Names used to be useful, who did you hire between April and September of 2012?

But then something happened. Somewhere after Snow Leopard 2012-002 and the first appearance of the 10.7/10.8 Java updates: form trumped function and all useful naming conventions were removed.

Which Java
Elegantly named and informational useless packages. Beautiful.

In the case of Java not just the platform name, but even what release number was removed too! Oh sure, someone took the time to change the disk image volume name, thanks, but once it was copied out of there, good luck in keeping things straight! Since these are flat packages now, Finder can’t tell you the version number in column view anymore, either.

WhichSecurityUpdate
What platform are you for? Should I just chuck all these at a machine and see what sticks?

How about the latest security updates? They all named the same! What a mess! Note that now even the disk image names are all the same too and the system has to resort to appending numbers on the volume name to avoid naming conflicts.

So Apple, if you are going to keep putting out security updates for older platforms then let’s stop pretending there is only one OS X release out there and start naming updates appropriately! Please? Thanks!

P.S. I’ve submitted a bug and mirrored it at Open Radar, if you are a systems administrator who is also irked by this trend of needless naming minimalism I encourage you to file a bug report and see if we can turn this around!

Silverlight: the next plugin Apple will be blocking

Shhh… Silverlight’s been updated for Mac

So by shear accident, I was in Windows 7 via Boot Camp today. I decided to run updates and actually look at what was being updated. I noticed there was a new Silverlight update, 5.1.20125.0, speak of the devil, in my XProtect Plugin Checker post, not long ago, I speculate when Silverlight will be blocked by Apple because of a security update. Security bulletin MS13-022 explains the critical nature of this for Windows and Mac, if you want to see an MS engineer tell you it’s Priority 1 this month you can visit the Microsoft March 2013 security update page. You’ll need Silverlight to watch the video, but don’t worry it won’t give you prompt you to update. Neither does Netflix. Apparently Microsoft haven’t pulled the trigger to alert users with old Silverlight plugins! Are they waiting for this 14.9MB package to replicate around the world to all the Akamai distribution servers or something? I think it’s done now.

Whither Thou Goest Check for Updates (or Preferences for that matter)?

So I decided to double check my auto-update settings in Silverlight. Would you like to check your Silverlight Preferences? The easy way is to Control-Click/Right-Click on Silverlight content and select About Silverlight from the menu. But take a real world example: you are at a site that won’t load it’s Silverlight content because the caches need cleaning! (This really happened to someone I had to support remotely via email).

Let’s go spelunking!
Opening Silverlight Preferences the hard way:

Navigate to /Library/Internet Plug-Ins
Control-Click on Silverlight.plugin and Show Package Contents
Navigate into Contents/Resources
Double click Silverlight Preferences.app

Or type this in at Terminal:

open /Library/Internet\ Plug-Ins/Silverlight.plugin/Contents/Resources/Silverlight\ Preferences.app

I ended up making a .command file to do this, zipped it up, and emailed it so the user could simply empty the Silverlight caches and get back to work (if this was for real work or Netflix I’m not sure…) but regardless, a Preference Pane would be kinda nice MS Silverlight dev folks! All it has to do, at bare minimum, is open this very same app inside the plugin bundle (so we don’t have to dig for it). That’s what the Oracle Java 7 prefPane does. I digress here’s my settings:

SilverlightUpdates

Yep that’s set…
OK so Microsoft doesn’t think this Priority 1 update needs updating yet on the Mac?

For fun, in the same folder you can run UpdatePrompt.app to see this:

SilverlightUpdatePrompt

Clicking Install now launches the URL: http://go2.microsoft.com/fwlink/?LinkId=116053 which will automatically start downloading the newest version of Silverlight.

Exploring the XProtect Factor

Now, I though to myself, if Microsoft doesn’t start getting people to update, I think I know what Apple’s gonna do… but they haven’t done it yet. So I did. I edited my XProtect.meta.plist and blocked Silverlight myself:

XprotectMetaBlockSilverlight

Just wedged it right in there with TextWrangler! Now, what happens when I visit a Silverlight page in Safari?

Blocked @ Netflix

Boom, blocked. Aha! This mechanism is quite extensible to whatever plugin Apple deems insecure. Interestingly though, this warning will appear only once in Safari.

Blocked Small

After that your Silverlight content will simply not load and you won’t be told why. The bundle name and version are set under the PreviouslyAnnouncedBlockedPlugins key in com.apple.Safari.plist and that’s it. Clicking OK in a hurry without reading the message might leave you scratching your head, while repeatedly clicking reload at Netlflix.

Safari Warning XML

Taking a peek at my XProtectPluginChecker I see it’s able to compare the installed version to the values XProtect.meta.plist has. My script is working dynamically, as planned, yay! (I fixed a couple bugs the first few days after posting so re-download if you were an early bird user)

XProtectPluginChecker-silverlightBlockedSo while you may not be seeing this yet I have a strong feeling you will… and when you do XProtectPluginChecker will let you know.

System Administrator Bonus

Say, Mac SysAdmins, wanna disable Silverlight on all your deployed Macs right now? Why? Maybe you want to turn it off right away and worry about installing the update later? BTW this does not block the plugin in Firefox (they have their own mechanism), Safari only.

sudo /usr/libexec/PlistBuddy -x -c "add :PlugInBlacklist:10:com.microsoft.SilverlightPlugin dict" /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist
sudo /usr/libexec/PlistBuddy -x -c "add :PlugInBlacklist:10:com.microsoft.SilverlightPlugin:MinimumPlugInBundleVersion string 5.1.20125.0" /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist

That’ll get your XProtect.meta.plist PluginBlacklist dictionary looking something like this (version vary between 10.6 and 10.7/10.8 machines):

XProtectXML Viola, your Silverlight don’t work no more. :] Now go update it!

 

 

XProtect Plugin Checker

Are you a system administrator or power user who needs a quick way to check if your Flash or Java plugins have been blocked by Apple? Like so:XProtectPluginChecker Menu 2

Then XProtectPluginChecker is the status menu app for you!

XProtect Plugin Checker iconClick to download.

Written in BASH, sprinkled with PlistBuddy/awk/sed-Fu with a dash of mdfind magic, and wrapped with Platypus, the aim is for XProtect Plugin Checker to be able to dynamically accommodate any additions Apple might make to the Plugin Blacklist, although only Flash and Java seem to be in their crosshairs right now, who knows? Silverlight might be next, given its lack of updates (going on 10 months).

A bonus idea for making this more useful is to make a launchd script that watches the XProtect plist file(s) then fires off the XProtectPluginChecker script when they change, emailing the results to you, because knowing is half the battle!

If you find this useful or if you have some hiccups with it, let me know. UPDATE: Now with comments enabled! :]

Also related, myXProtectStatus is a similar style menu status script that lists the malware threats Apple is blocking.

Apple’s New Epoch Time for WebComponentsLastUsed

The latest Java update for Lion 2012-003 ( which after 3 revisions is still called JavaForOSX-1.0 in Software Update – oh, Apple! But I digress…) will turn off Java if it hasn’t been used in 30 days (or so I hear). It accomplishes this by writing a value to the WebComponentsLastUsed in ~/Library/Preferences/ByHost/com.apple.java.JavaPreferences.UUID.plist.

It used to be enough to have WebComponentsEnabled set to True, but now WebComponentsLastUsed is required or the unclickable “Plugin-Disabled” button will be shown in Safari’s lower right corner (it totally looks clickable yeah?)

If you work at a company that requires Java web components to be on for things like timesheets, making sure Java stays on helps to avoid getting help desk calls.

So I needed to figure out how this value was computed, it was too small to be the Unix epoch (seconds since January 1, 1970), so I did some sleuthing, some comparitive analysis (just to sound fancy), and figured out it is the number of seconds since January 1, 2001. To get this value you just need to get the Unix epoch and subtract the number of seconds since Jan 1, 2001.

Here’s the way to get this value in a BASH Terminal:

echo $(( $(date "+%s") - 978307200 ))

Toggling the check box in /Applications/Utilities/Java Preferences will reset the WebComponentsLastUsed value and you will find it very close to the value from Terminal.

Wasn’t that fun? The Der Flounder blog has a script using this method to turn on Java. He was a good sport to incorporate my code, too. He enlightened me with his UUID scripting code, so share and share alike, I say.

Bonus link for Apple’s other epoch time, for iTunes’ XML Play Date field: January 1, 1904 – that’s the first year of the last century with a leap year, so says Filemaker! ;)

OpenDNS does not prevent infection of Flashback

While reading the froth around Flashback I came upon this shameless bit of self promotion from OpenDNS: Worried about Mac malware? Just set up OpenDNS.

What, Me Worried?

It’s got some amazing claims:

"All Mac users should switch to OpenDNS now to prevent infection"

A lot of people have commented:
19 pingbacks from various regurgitators: FairerPlatform, Tech 3K, chicagogeek, News4iPhone, ZBlog!, Free Nulled Apps, Tech News, Tutto App, When’s the next Iphone out?, MostOfMyMac.com, iphone 4S issues, Apple Related, keepiphone.com, IT Blogger Blog, Apple Stocks, iHelpBoard, and The Apple Lounge

One very enthusiastic supporter:

"We should change the world for better"

And then my comment:

Just asking...

It’s still awaiting moderation?! Whaaaaa?!

[sarcasm]Why you no like me Allison? Is my English no too good? Do I NOT WRITE IN ENOUGH CAPS?!?! Why you no want make world for better?! Why no share my important tip?[/sarcasm]

Update Java folks. Relying on a DNS company to block DNS queries is just dumb. How do they know what all the Command and Control domains are? Those things can change at whim and I wouldn’t make DNS lookups my first line of defense, it certainly isn’t preventative. If you don’t have your computer updated you can get compromised. Even if you do update, until Apple gets things patched quicker, even that’s not good enough, you need some protection, Sophos makes a good free product. Get it.

Also, if you think “I only go to good clean sites”. I’ll tell you, that you can never know. This site got hacked because of combination of a Dreamhost database compromise and  Wordpress vulnerabilities. That’s been taken care (otherwise you’d be redirected to femalebodyinspector.ru or something like that — gawd, of all the hacks… — and the domain didn’t even work! ). But all it takes is some PHP/Wordpress compromise and your site could be serving up malware. So be safe, be vigilant, and don’t think that someone else is going to protect you because they don’t let your computer talk to strangers (yes, OpenDNS I’m talking to you.)