Is the New Security Update Working on My Computers?

Apple has posted XProtect defs v.11. Adds OSX.MacDefender.H.

Three users have reported losing their login.keychain while attempting to manually update their XProtect defs. You may recall that one user in this thread also had keychain errors. Two were using the "Safe Download Version" tool and blamed it, but I am sure it uses the same command line as the Terminal command that uses sudo to launch the XProtect process, which is what the last individual was doing. Although I initially suspected XProtect, I suppose it could be sudo when it checks your admin password.

At this point I would strongly recommend not using either the "Safe Downloads Version" tool or the Terminal sudo command to initiate a manual update to the XProtect defs database. I understand Apple is recommending that you uncheck and recheck the "Automatically update safe downloads list" in the Security Preferences Panel if your Mac is not auto-updating. Rebooting may or may not work for you.

I did not lose my login.keychain but at some point while I was using either the Terminal command or the "Safe Download Version" tool to manually update the definitions, I started getting strange results when I tried to view various items in it, like 'access not allowed' even when I supplied the proper password. Restarting my Mac cured that.

Also, I just noticed that the Security preference to automatically check for updates had somehow become unchecked at some time while I was using one or the other of these manual methods. AFAIK, I did not manually uncheck that preference.

Using the Apple-approved method of checking the box immediately caused an update. My version is now 13, modified June 13 at 4:14:12 GMT, as verified by checking the /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta. plist file directly. I think I will not be using the manual methods for a while & see what happens….

MadMacs0 wrote:

In Terminal type "sudo launchctl list" then do a Find for "xprotect" to see if it's loaded into launchd's root processes. If everything was normal about the last run you should see:

- 1 com.apple.xprotectupdater

I get an exit status of 0 (zero) not 1 for the com.apple.xprotectupdater entry, yet everything seems to be working OK.

If you use "sudo launchctl list -x com.apple.xprotectorupdater" it will show the job information output as an XML property list, which I have not yet been able to fully interpret.

There is a typo in the above (should be "xprotectupdater," not "xprotectorupdater"). For the corrected form I get:

<?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.apple.xprotectupdater</string>

<key>LastExitStatus</key>

<integer>0</integer>

<key>LimitLoadToSessionType</key>

<string>System</string>

<key>OnDemand</key>

<true/>

<key>ProgramArguments</key>

<array>

<string>/usr/libexec/XProtectUpdater</string>

</array>

<key>TimeOut</key>

<integer>30</integer>

</dict>

</plist>

How does this compare with what you get?

@R C-R: I get the same result as you. The value for the key 'LastExitStatus' is of course the same number that is reported in the tabular results from a 'sudo launchctl list' command. In my case the value is 255 right after booting. Then, if a manual update is forced by toggling the System Preferences/Security checkbox, the result is 0, as you have reported.

The convention for a status result from a C program is that 0 means no errors, a successful return. I think we have established that for some people, like me, XProtectUpdater fails at boot time because the internet network is offline, and the status code returned is 255. In an earlier post I hypothesized that this failure is preventing the update task from being entered into the queue for recurring tasks, so that the automatic daily updates do not occur. The fact that triggering a manual update by toggling the Security checkbox does make a change in the 'launchctl list' table means that the launch daemon 'launchd' is involved with running XProtectUpdater. And the returned status code of 0 in this manually triggered (and successful, since new files were installed) case means that the no errors = 0 convention is being followed.

Now MadMacs0 has reported that his return code was 1. This says to me that for him XProtectUpdater encountered a different error. I don't know how he ran XProtectUpdater. If it was from the command line or from running "Safe Downloads Version" then this may not match the environment used when using the toggle method. Or perhaps the code = 1 means that no new update (with higher version number) was available?

I'll mention a couple more observations. The format and values of the XML file returned by 'launchctl list -x filename' for other recurring tasks such as 'periodic-daily' are the same as for the xprotectupdater case that you listed. But for all of these processes there are no keys with information for the timing of any recurring task. All of them are 'OnDemand'. Therefore, launchd has another location where it is storing this queue data. I'm stuck as to how to go further.

I guess the bottom line is that there is a bug in the update launching process and we have to wait for Apple to fix it. It might be fun to revisit this stuff then to see what they changed.

steveBinLA wrote:

I'll mention a couple more observations. The format and values of the XML file returned by 'launchctl list -x filename' for other recurring tasks such as 'periodic-daily' are the same as for the xprotectupdater case that you listed. But for all of these processes there are no keys with information for the timing of any recurring task. All of them are 'OnDemand'. Therefore, launchd has another location where it is storing this queue data. I'm stuck as to how to go further.

First a bit of full disclosure. I do not have access to an Intel Mac at this time. I have kludged together a working model of the XProtect system using components from the Security Update along with an updater process that simply displays a dialog telling me that it ran and when (in fact it just went off). That was OK for the initial tests, but we have now crossed over into areas that I cannot personally test. I'm fully reliant on the participants in this thread as well as several others in other forums and email lists to test these theories and provide feedback, so I'm now functioning as just an information exchange tool. I realize I don't belong to this forum, just trying to help out.

That being said, everything I know about you question I learned from this site: http://www.brunerd.com/blog/2011/06/03/safe-downloads-widget/

You'll see he has found the location used by the Security preference pane to turn updates on and off </private/var/db/launchd.db/com.apple.launchd/overrides>, but since that database does not exist (or is elsewhere) in my OS, I don't know whether it also contains the count-down timer or not.

BTW, I believe this widget to be perfectly safe in that it does not attempt to force an update nor change anything. It is also possible to read the entire script that he uses.

MadMacs0 wrote:

You'll see he has found the location used by the Security preference pane to turn updates on and off </private/var/db/launchd.db/com.apple.launchd/overrides>, but since that database does not exist (or is elsewhere) in my OS, I don't know whether it also contains the count-down timer or not.

All it has is a Disabled item, unchecked if you haven't turned off the option in the Security prefPane.

NOTICE: I just noted that the updates are at version 14 as of a couple of hours ago, and add two more MacDefender items.

These MacDefender bad guys are really pushing out stuff at an alarming rate. I wonder if a once daily "phone home" update approach is adequate, or if a "phone home" approach is even a good idea. Perhaps some push mechanism is needed, so when an update is ready, our machines would be notified to come get it. If so, then the Apple fix to this problem may take a bit longer. Does anyone know if a system infrastructure feature like this is in place already in Snow Leopard? Hmm. I suspect that if you do know, you are under an NDA, and so must keep silent. Oh well...

steveBinLA wrote:

NOTICE: I just noted that the updates are at version 14 as of a couple of hours ago, and add two more MacDefender items.

V14 added OSX.MacDefender.J and V15 just added .K.

These MacDefender bad guys are really pushing out stuff at an alarming rate. I wonder if a once daily "phone home" update approach is adequate, or if a "phone home" approach is even a good idea. Perhaps some push mechanism is needed, so when an update is ready, our machines would be notified to come get it. If so, then the Apple fix to this problem may take a bit longer. Does anyone know if a system infrastructure feature like this is in place already in Snow Leopard? Hmm. I suspect that if you do know, you are under an NDA, and so must keep silent. Oh well...

I'm not sure it's time to push the alarm button yet, after all MacDefender isn't capable of doing anything except running up the credit card balance of a user who doesn't think before he acts. This effort by Apple strikes me as being more of a PR campaign than a serious counter-security threat, but I would agree that they need to get it working in case the next piece of malware poses real concern.

As far as doing it only once a day, they have made it clear that it is not going to adequately keep up with the rate at which they are capable of posting updates, but they before they can increase the frequency they need to make sure that the update server network is capable of handling the additional traffic. The problem now is that many users are even getting the once a day check, so it's probably difficult for them to judge whether or not they need to beef things up before increasing the frequency.

It seems to me that the current system is about as close to a push system as I would want in that once I choose to be routinely updated, it is supposed to take place automatically, without my having to take any further action or approve anything. You can do the same with Software Updates (daily/weekly/monthly) and MobileMe Sync Services(hourly/daily/weekly), if you choose. I just don't think I want anything from anybody being pushed to may computer that I haven't approved somewhere along the line. I suppose as long as I could choose whether or not to update once notified that a new version was available, that would be OK. But I'm certainly not aware of any mechanism today that would allow such a notification. And how would it work if your Mac was off or sleeping when the announcement was made, where would these announcements queue up? Perhaps one could simply subscribe to an email list that would send out such notifications. Thinking out loud now.

Now at version 15, with a 'LastModification' stamp of Jun 2011 05:36:40 GMT. It includes MacDefender definitions A through K.

I think the once a day check is fine. The chances of encountering the trojan are fairly small to begin with & I doubt that it would be practical to try to push the latest version to several million Snow Leopard users at the same time, even if it was possible.

I also think some of the reports of the XProtect version not updating automatically are due to Apple intentionally not causing all of those millions of systems to try to phone home at the same time, instead spreading that out over a 24 hour or so period.

I am also beginning to suspect some of the problems with automatic updates may actually be caused by forcing the update manually using the various third party methods. I have quit using them in favor of the Apple suggested method of toggling the "Automatically update safe downloads" Security preference off & then back on again. Not only does this work, after doing some maintenance with Onyx to delete caches & other stuff that the other methods might have messed up, the automatic update is now working for me as it originally did -- I did not have to do anything to get version 15.

While it's and additional step, toggling the system preference is easy to do. All we really need is for Apple to officially name an app "Xprotect" and put a seperate system preference called "Xprotect" and give us some options:

• check now
• check for updates frequency (hourly, daily, weekly, monthly, etc) via a popup
• Date of last installed or version number

I agree the MacDefender is a low threat for now, but it has shown the gateway for others to cause issues.

I realize, right now, this whole feature is rolled into the Security Preference pane, but my thoughts above could easily be worked into that, much like the current software update function works...

The version is now 16, with a 'LastModification' stamp of 15 Jun 2011 18:13:47 GMT. It includes definitions for MacDefender variants A through M. Once again, I did not have to do anything to get it; as described earlier the auto-update feature is still working fine now that I have quit using the manual update methods.

Regarding what you say we need, 'check now' can be accomplished by toggling the system preference. The version number, when Apple released it, & when it was installed can be determined easily from the file /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta. plist. For those not willing to navigate to that file in Finder, note its creation date, & open it with TextEdit or Property List Editor, it would be easy for someone to create an AppleScript to display that info.

An option to set the update frequency to less than the once every 24 hour default would be inadvisable given how often the definitions are updated. One to set it to greater than that would be pointless unless Apple started releasing updates more frequently, & would just burden the servers with needless queries.

With the above in mind, the only Apple addition I personally think would be appropriate is perhaps to display a warning in the Security preference if no check for an update has been done in the last 24 hours (or whatever interval Apple determines is appropriate).

As for MacDefender showing others how to cause problems, what it does is not new. It is a social engineering exploit that relies on tricking the user into installing something they would not otherwise install. The most sophisticated thing it does is to download a file to a would-be victim's Mac via a Javascript embedded in a web page without any overt notification or an explicit request to do so. But that is basically the same thing loading many URL's in browsers already do, the only difference being we usually load them on purpose.

If anything, what MacDefender has shown other would-be trojan writers is that if they are successful in creating a nuisance for enough Mac OS X users, they will provoke Apple into adding built-in detection for their exploit, greatly reducing their chances of a payoff significant enough to justify their efforts.

I suspect MacDefender's creator did not get much of a payoff from the first variant, & the payoff from each new one is less than the one before. I doubt anyone using the same techniques will do any better.

R C-R wrote:

The version is now 16 (...) unless Apple started releasing updates more frequently...

It may be interesting to see when you get the current version 17 (or later) without toggling the Sys Prefs > Security pane:

If you know how to read the XProtect.meta.plist file, would you mind posting the value of its "LastModification" key? That should show (in GMT format) when Apple updated the definitions. It is easier to work with that than trying to guess about everybody's local time.

EDIT: I just rechecked my XProtect.meta.plist file & yes, it is now at version 17, with a "LastModification" key value of 16 Jun 2011 04:44:48 GMT.

R C-R wrote:

If you know how to read the XProtect.meta.plist file, would you mind posting the value of its "LastModification" key? That should show (in GMT format)...

Okay: