Seriously Adobe? You release CS 5.5 May 2011 and InDesign CS5 plugins seem to load just fine, but then just last week, you release an update to InDesign, and under Resolved Issues you list: “CS5 plug-ins can be loaded in CS5.5, leading to code conflicts and instability [2867833]”, translated: “Every plugin you thought worked in CS 5.5, doesn’t really, so we aren’t allowing them to load anymore.”
Boo.
You suck.
myXProtectStatus – A drop down status menulet for XProtect, showing date, version, and threats protected against. Written in bash, and wrapped with Platypus, it is informational only, so don’t ask me to add some menu item to do something, it just reports. However I did add the Command Line and GUI ways to update XProtect in the output, so it’s of some use for that. When run, it’ll reside in your menu bar and call a script inside itself each time it runs. Tuck it away somewhere, add it to your loginitems. Check it every once and a while…
Screenshot of myXProtectStatus:
Other notes: I pipe the output of the threat list though /usr/bin/uniq, because while Hell.RTS has three different signatures it retains the same name in each and it seemed redundant to list all of them out! So all recurring names will be reduced to one entry.
The menu bar icon: it’s an X with a grey picket fence around it, I made it tiny… then realized I need an icon for the App too rather than Platypus’ so I sized it up, it’s fugly, but you’ll never see it! :)
Bonus: When run as root, it will show the auto-update on/off status, which can only be determined on the command line by root.
Going to WWDC 2011! See you all there! (although, I got a haircut so it’s all short now and not the curls you see on the site :)) and whatever is not NDA I’ll tweet via brunerd
So I submitted a hint for getting info about the Safe Downloads protection list, then I made a widget, now delving deeper into Safe Downloads list and the command line
Let’s look at the BOM for the update:
/Library/Preferences/com.apple.ReportMessages.domains
/Library/Preferences/com.apple.ReportMessages.v2.domains
/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.plist
/System/Library/CoreServices/MRTAgent.app
/System/Library/LaunchAgents/com.apple.mrt.uiagent.plist
/System/Library/LaunchDaemons/com.apple.mrt.plist
/System/Library/LaunchDaemons/com.apple.xprotectupdater.plist
/System/Library/PreferencePanes/Security.prefPane
/usr/libexec/MRT
/usr/libexec/XProtectUpdater
What’s interesting is after installation /usr/libexec/MRT, com.apple.mrt.plist, and com.apple.mrt.uiagent.plist delete themselves after they run?! This is odd, yes? From what it looks like MRT has a lot of pattern matching code in it… Also notable is that in the postflight action loadMRT, the launchagent and daemon are unloaded and reloaded in the postflight actions, however the loadXProtectUpdater script does not do this. So the XProtectUpdater does not run again if you rerun the installer since launchctl will report it’s already loaded, so you’ll have to wait a day for it to check again and update as seen in com.apple.xprotectupdater.plist (86400 seconds = 1 day).
If you want to manually force an update, you can run this command:
sudo /usr/libexec/XprotectUpdaterYou must run as root or else it informs you:
XprotectUpdater[pids] Unable to write new signature meta plist
You can also just toggle the preference in the Security prefpane, this causes the launchd job to be unloaded an reloaded, however from an admin POV it’s nice to have a non-GUI way to do this. Also there seems to be a bug in the prefpane so values are not written after it is open for more than 30 seconds! Come on 10.6.8! (It feels like this was Lion stuff that’s getting shoe-horned into Snow Leopard a bit earlier than they expected )
Another interesting tidbit is the actual malware list that is squirreled away here:
/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.plist
If you attempt to use the defaults command to read it you are given this:
defaults[pids] Preference plist was NOT a dictionary.
defaults[pids] Domain /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect does not exist
It seems the Apple folks have done some creative things so while this is still valid XML it is not a defaults compatible plist. The values are dictionaries stored in an array at the top level. Is this protection against script-kiddies who’d use defaults to change values in the list? While the file is root owned, one must wonder if there are safeguards to check its checksum against a server to detect unauthorized changes to it? Since admin status is enough to escalate to root using sudo (and every initial user in OS X is an admin), combine this with the fact that installer runs as root when installing a pkg, and this is something to keep an eye on… (oh right my point being this thwarts a script to list detected threats, at least easily using defaults)
And some parting advice: Turn off Open Safe Downloads in Safari! It’s an oddly bad decision by Apple, its paralells to Windows’ AutoPlay/AutoRun give me goose bumps! I don’t want a dmg opening itself up and copying out it’s pkg payload into Downloads, then auto launching it! CRAZY BAD! Malware on a platinum platter, Apple couldn’t have made it easier!
Here’s the code for turning this off in Safari, it is a per user preference:
defaults write com.apple.Safari AutoOpenSafeDownloads -bool FALSE
And so concludes this expedition, hope you learned something, and can teach me something back in the process, thanks!
UPDATE: The AUTOUPDATE code only works as root and so is not useful in the Dashboard environment! This has been removed from the widget.
So I slapped together a widget for the Safe Downloads commands I post at OSXHints:
Nothing glamorous just the facts and the following code is how it gets it’s values:
defaults read /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta LastModification
defaults read /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta Version
The auto updates status took a bit more massaging:
eval $(sudo defaults read /private/var/db/launchd.db/com.apple.launchd/overrides com.apple.xprotectupdater | sed 's/ //g')
if [ ${Disabled:=0} -eq 0 ]; then
echo ON
else
echo OFF
fi
All apologies to Dashboard coding perfectionists but the calls for the widget are synchronous, and reading up on Dashboard coding best practices, Apple says a shipping widget should only use asynchronous calls for info… oh well it works well enough for me! :) Perhaps I’ll go back and throw in extra lines of code for asynchronous handlers when I can, if my widget freezes up any other widgets you can simply restart Dashboard by killing to Dock process from Activity Monitor.
Related:
myXprotect Status – a drop down list of threats protected against for the menu bar