About | Buy | Forum | Industry Watch | Learning Curve | Products | Search | Twitter | Xnews
Home » Industry Watch » Coldspots

.SoftwareUpdateAtLogout Revisited

Victory - and the elusive clue - can come in small packages.


Buy It

Try It

Start here.

http://arstechnica.com/civis/viewtopic.php?f=19&t=1110877

'Admin Password not required for Software Update if..... the active account is an Admin account. Has anyone else experienced this?'


Grandpa (modelamac here - 'Grandpa' at the Apple forums) noticed something. He noticed it on its own. Hey - it's not trivial: if you don't stop to think about it, what you know about the system running in SUM after logout, you won't get it.

But the key is: who tells the system to alter its default logout procedure? And as this procedure runs with the highest level of authentication possible - even higher than root itself - how secure is this request system? For if the system can be debugged and the request method tracked, then isn't it possible to hack the entire Mac OS X and introduce a really nasty rootkit installer?

Again:

  1. Code running after logout runs at the same privilege level as code running before login. Code like that doesn't run on a user account. Not even on the root account. No one's logged in. It's called 'single user mode' because it essentially turns the 'rock solid foundation' of a multiuser Unix into a clone of MS-DOS, to use a bad analogy.

    Single user mode isn't a bad thing. All systems need it. And Unix has always had it - it's not something Apple invented. But single user mode (SUM) has to be protected.

    1. Unix admins in the 'old days' with a single box and dumb terminals made sure the server room was locked.

    2. Unix boxes today are in fact vulnerable in the same way the old servers were: if the wrong person gets their hands on a Mac, they can get at anything on the box (unless a firmware password is used - but that's not without different types of risks).

  2. As soon as you logout or start shutting down or rebooting, your system starts running in single user mode. It's the logout itself that causes this. Obviously the code that runs in these situations can't be something that can be influenced by something from 'user land' - something done on an ordinary user account.

    For if it were, then any hacker could instruct the logout procedure to do anything at all - such as install a rootkit.

    Some of the details of how this new Apple 'enhancement' works are known: there's an empty file called '.SoftwareUpdateAtLogout' that's placed in a protected directory: the logout code sees this file and knows there's an authentic request for an update requiring root privileges to install.



    The rest seems to be predefined - the location of the files in question, the way to install (following install scripts that explicitly say in their comments that they presume they'll be running as root) and so forth.

    The key - the weakness - seems to be in that file '.SoftwareUpdateAtLogout'. There may be more to it (it'd be a surprise if there weren't) but ceteris paribus if you can get that file on disk, then you can get the logout procedure to install anything you want.

  3. But the issue goes beyond this. Even more important is the fact that someone is coming in remote to your system with no authentication whatsoever and completely owning it. No password, no nothing.

How does this happen? Some details are known but unfortunately no one seems to give enough of a shit to investigate it further. Macs are cool and Apple and Steve Jobs have never fucked up. We might not fully understand what's going on but hey - we're all sure it's alright. Right?

Maybe. But as consumers we want to know why and how we're secure - and if we are. And if there's a possibility of hacker code exploiting this rather unnecessary mechanism, then we want to know - in such case we're all vulnerable right now.

Put another way: we want full disclosure.

And again and above all else: these computers are our computers. They're not Apple's. Not only should Apple ask for authentication to initiate system sensitive procedures, they should be required to do so. There should be no mechanism available on a 'rock solid' Unix system to do something like this. And if there is such a mechanism on Mac OS X (as there seems to be) then it has to be investigated and analysed, and the hole needs to be plugged. By yesterday.

The Ars Discussion

Grandpa was anxious because unlike what he'd been used to with 10.0 - 10.5, he saw Apple installer code breeze through his system without authentication on 10.6.

He says he wasn't well received at Apple, and so he started a new topic at Ars instead.

Grandpa cites these two links.

AdminAuthorization
http://rixstep.com/1/2/20100331,00.shtml
runner
http://rixstep.com/1/2/20100331,01.shtml

'Do I really need a Dope Slap?' asks Grandpa. No you don't need a slap, Grandpa. You're already fully 100% awake. Worry about your brothers in arms instead.

Fenis-Wolf immediately replies.

I believe the Java update is special - I've been prompted for other updates as I should be.

His mileage may vary, but that's simply not true. All systems prompt except Snow Leopard. Snow Leopard doesn't.

Graham Perks points out that an issue something like this was corrected in 2006. That's true, Graham, but that one was a completely different thing. That was about authenticated installs misinterpreting how much privilege they should give to other parts of the process. Unbelievably enough, this security blooper became well known and many third party software houses used it actively in their install scripts - yet none of them seem to have wondered if such a thing should be possible or asked Apple about it.

Graham goes on to hurl some really stinky fanboy bullshit.

Nowadays the updater supports signed applications. Apple signs the Java update. OS X knows Apple's signature is trusted. The update can happen without further authorization. No user nagging required. Nobody can fake a signed app. Any tinkering at all - deleting a file, adding a file, changing a file - and the signature becomes invalid. So OS X is safe to assume, after checking the update matches the signature from Apple, that the update is safe to apply.

No, Graham - that's not the way Unix works. Or is supposed to work. It doesn't matter one iota how much something is signed - you still have to authenticate to get into system protected areas. The file system is an entity unto itself. And protects itself.

And what's going to get you to root level? The applications you run, the processes you create, run on your account, your user account - they're limited by their very nature in what they can do. Thank goodness for that. It's called 'security'.

No user land process can override system permissions without authentication. And it doesn't matter a hoot how many certificates you find on a download package. Certificates aren't authentication and the code recognising the certificate would need to be already running as root to have that opportunity. And your code is not running as root.

Yet something obviously is running as root - something beyond your control. And perhaps you trust in Apple, Graham, but other people may find the whole thing just a mite creepy - something like Mark Zuckerberg telling you that Facebook privacy settings haven't changed over the years.

sonicdeath doesn't agree with Graham. sonicdeath gets it right.

Yeah but just because it's correctly signed doesn't mean it shouldn't prompt you... that's pretty weird behavior.

All major Linux distributions have signed packages, but they don't automatically update your system ;)

Exactly.

Here comes fanboy Yam-Koo. Maybe he's a Kawasaki lovechild.

Still, it's dangerous to prompt users all the time with low-priority messages that they aren't going to read anyhow... trains users to ignore all messages.

That's so ridiculous it doesn't even deserve comment. But Yam-Koo Egg Foo: how exactly is an update that's going to alter your protected system files 'low-priority'?

Oh please, you dork: if you train people to not react to obvious system holes, if you train them to think their Unix boxes are open like Windows, if you desensitise their security instincts, to not react to anything: what good have you done then?

Absolutely the worst comment in the thread. Unforgivable.

But now Graham's back to make things even worse. People are trying - they're trying to understand. But boy do they ever fumble in the dark.

You are prompted to do the upgrade or not, via the normal SU dialog. All signing does is remove the extra password dialog.

That's a real LOLZ alright. Yam-Koo and Graham can perhaps keep each other company. It's amazing how people just make things up and pull things out of their arses, trying to convince others (and themselves) they actually know what they're doing.

The sweet-breathed Hal Itosis has an observation to offer. And he's completely spot on about this particular matter.

Also, it seems to happen only when going through Software Update itself. I.e., if we download the same package directly from http://support.apple.com/kb/DL972 using Safari, then the password will be requested during the install. (at least that was my experience)

And that's completely correct. Inanimate matter can't rise up to root as living entities all by itself. It's in fact the Software Update process that somehow triggers the system to start that nasty bugger 'suhelper' which is spawned not by user land's launch control daemon but by the root-owned one.

So the issue is ultimately how you get root-owned launchd processes to start things as root when you yourself don't have authentication to do so. Apple are circumventing (literally they're hacking) standard Unix system security here.

launchd is Apple's replacement for the traditional Unix startup and other 'etc' routines. They've offered the code back to the open source community but so far there haven't been many takers. Perhaps there's a reason for this?

Grandpa/modelamac is back again.

Thanks.

When I posted the same problem as 'Grandpa' in the Apple Discussions forum, it was not treated with open minds.

What he probably ran into was something like this.



[That may be difficult for a fanboy to make sense out of but anyone else will see it clearly straightaway.]

So now - anyway - Grandpa goes and sets up a pristine test machine to see what's going on.

Update on this. Ran this test:

Step 1: Fresh GUID formatted drive (never used before). Installed Snow Leopard by the book (per Prompts). Finished standard setup with the one Admin account (me). Deferred any/all migration of data from another drive.

Step 2. Selected S/U from Menu Bar. Download:
Combo Update, Remote D/T Client, Airport Base Station, iLife Support, iTunes. Clicked INSTALL. Had to enter Admin P/W. Did so, and an hour or so later that finished.

Step 3. Selected S/U again. Downloaded Security Update, Java Update 2, Safari Update, and the installation began WITHOUT requiring a password.

MY conclusion: I have no idea under what circumstances I will be required to enter a password when Software Update is invoked.

I do know that my password will NOT always be required by S/U for an installation.

I'm going to keep this drive pristine, and do only the S/U on it when notified on my other Macs' startup drives.

Grandpa should be given kudos not only for going through so much effort to investigate the issue but also for having the perspicacity to understand there's an issue there and the determination to get to the bottom of the matter instead of giving up and chugging a jug of Kool-Aid.

KD5MDK has a final post. It's a question but even if it seems a bit left field, it's a valid question.

Do you think that the fact you have already authenticated once for this task in this user session might be involved?

Aye, there's the rub. For authentication (and the need to repeat the procedure) is governed by one facility in Unix itself and by a completely different facility in Apple's 'add-ons'.

Authentication in the basic Unix sense takes place through use of sudo. And the behaviour and requirements of sudo are governed by protected configuration files.

The only way to go is to enable 'TTY tickets' and set the timestamp timeout to zero. Otherwise you can be hacked at any time by the sudo piggyback exploit:

A rogue process (a trojan) sits in stealth and continually attempts to perform - for example - a rootkit install without authentication. How? Because by default, sudo will authenticate you as a user for all your command line (Terminal.app) 'TTYs' and for five minutes afterward. So you don't have to keep entering your password over and over again.

Obviously this default configuration setting is a carefully considered design decision but it also implies a horrible risk. Using CLIX effectively lets you have your cake and eat it - you input your password once but all sudo sessions are protected with TTY tickets enabled and a zero timestamp timeout, no hidden trojan can piggyback in.

Use of sudo is governed by '/etc/sudoers', a file that's normally not even readable by users other than root.

# sudoers file.
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the sudoers man page for the details on how to write a sudoers file.
#

# Host alias specification

# User alias specification

# Cmnd alias specification

# Defaults specification
Defaults    env_reset
Defaults    env_keep += "BLOCKSIZE"
Defaults    env_keep += "COLORFGBG COLORTERM"
Defaults    env_keep += "__CF_USER_TEXT_ENCODING"
Defaults    env_keep += "CHARSET LANG LANGUAGE LC_ALL LC_COLLATE LC_CTYPE"
Defaults    env_keep += "LC_MESSAGES LC_MONETARY LC_NUMERIC LC_TIME"
Defaults    env_keep += "LINES COLUMNS"
Defaults    env_keep += "LSCOLORS"
Defaults    env_keep += "SSH_AUTH_SOCK"
Defaults    env_keep += "TZ"
Defaults    env_keep += "DISPLAY XAUTHORIZATION XAUTHORITY"
Defaults    env_keep += "EDITOR VISUAL"
Defaults tty_tickets
Defaults:ALL timestamp_timeout=0

# Runas alias specification

# User privilege specification
root    ALL=(ALL) ALL
%admin    ALL=(ALL) ALL

# Uncomment to allow people in group wheel to run all commands
# %wheel    ALL=(ALL)    ALL

# Same thing without a password
# %wheel    ALL=(ALL)    NOPASSWD: ALL

# Samples
# %users  ALL=/sbin/mount /cdrom,/sbin/umount /cdrom
# %users  localhost=/sbin/shutdown -h now

Things are a bit different with Apple authorisation services. A lot of thought has gone into them but they're not perfect. It's easy to put up a 'fake' password prompt that looks like it's coming from the system - it's easy to 'phish' passwords on a Mac OS X system (even though no one's bothered yet what most users know). And the nature of privilege escalation is completely apart from the one used by sudo (which isn't a Unix default anyway: it's originally part of OpenBSD, commonly considered the far and away most secure and security-conscious Unix, but still and all).

Look inside /etc/authorization - it's a plain text formatted property list file. You'll see the 'timeout' key at the bottom of almost all items. That's the timeout in seconds for each of the privileges mentioned.

[Note: the timeouts here are not in minutes - they're in seconds. They're expected to be used immediately in code.]

The privileges - the 'keys' - are cited directly in application code by their names. Application code requests a privilege, the Apple authorisation services prompt the user of the application for 'authentication' - normally a pass phrase. The privilege lasts as long as the timeout field says it should.

The privilege usually associated with 'privilege escalation' is 'system.privilege.admin'.

<key>system.privilege.admin</key>
<dict>
    <key>allow-root</key>
    <true/>
    <key>class</key>
    <string>user</string>
    <key>comment</key>
    <string>Used by AuthorizationExecuteWithPrivileges(...).
AuthorizationExecuteWithPrivileges() is used by programs requesting
to run a tool as root (e.g., some installers).</string>
    <key>group</key>
    <string>admin</string>
    <key>shared</key>
    <false/>
    <key>timeout</key>
    <integer>300</integer>
</dict>

As the description string explains, it's used by installers (or at least used to be used by them).

Your authorization file may have two items similar to the following. Note they both deal specifically with installs in protected system areas and they both grant a huge timeout.

<key>system.install.root.admin</key>
<dict>
    <key>class</key>
    <string>user</string>
    <key>comment</key>
    <string>Checked when admin is installing in root domain (/System).</string>
    <key>group</key>
    <string>admin</string>
    <key>shared</key>
    <false/>
    <key>timeout</key>
    <integer>300</integer>
</dict>
<key>system.install.root.user</key>
<dict>
    <key>class</key>
    <string>user</string>
    <key>comment</key>
    <string>Checked when user is installing in root domain (/System).</string>
    <key>group</key>
    <string>admin</string>
    <key>shared</key>
    <false/>
    <key>timeout</key>
    <integer>300</integer>
</dict>

Comparing a Snow Leopard authorization file with one from Leopard reveals (amongst others) the following new privileges for Snow Leopard.

<key>com.apple.DiskManagement.</key>
<key>com.apple.ServiceManagement.blesshelper</key>
<key>com.apple.ServiceManagement.daemons.modify</key>
<key>com.apple.ZFSManager.</key>
<key>com.apple.pcastagentconfigd.</key>
<key>system.preferences.security</key>
<key>system.print.operator</key>
<key>system.privilege.taskport.debug</key>
<key>system.privilege.taskport.safe</key>
<key>authenticate-admin-30</key>
<key>authenticate-developer</key>
<key>authenticate-session-user</key>

At the end of the day, Apple may have some way of limiting their suhelper module. That's fine.

What is not fine is it's not been documented, users are left in the dark about what's going on - and above all: the system's spawning root processes from user land without user authentication, without requiring the user to approve - by a method that can very well be susceptible to exploitation by the wrong people.

Personal computers may not be personal anymore - they're all multiuser save for Microsoft's - but they're still unequivocally the property of those who use them - and not the property of Apple.

Special Links
Coldspots: runner
Coldspots: Fingers in the Pie
Coldspots: AdminAuthorization
Rixstep Coldspots: .SoftwareUpdateAtLogout
Radsoft: Apple Rooting Their Own Computers?
Digg: How a Malformed Installer Package Can Crack Mac OS X
Mac Geekery: How a Malformed Installer Package Can Crack Mac OS X

'I didn't have to enter my password to update. Is this typical for everyone?'
 - 'zapblast' at the MacRumors forums
'The media buzz over Opener went on the better part of a month and was then forgotten, but the fact remains that it is the single biggest security hole ever in the history of modern operating systems. No other operating system has ever offered such effortless escalation to superuser.'
 - Rixstep Industry Watch on Opener 3.9

See Also
Industry Watch: Opener 3.9
Learning Curve: Rooting 10.5.4
Developers Workshop: 061-7784
Industry Watch: Get Root on 10.5.4
Industry Watch: ARDAgent Here to Stay?
Coldspots: The Strange Case of Safari 4.0.5
Learning Curve: Of Sticky Bits & Preferences
Learning Curve: ARDAgent on Snow Leopard
Hotspots: SLIPOC — Root Exploit of Mac OS X
The Technological: Walking into an Apple Store
Red Hat Diaries: Number One at Almost Everything
Learning Curve: Symantec's OS X Threat Landscape
Learning Curve: Rootkits Roam the World of Windows
Industry Watch: For Apple, This is the Year That Wasn't

About | Buy | Forum | Industry Watch | Learning Curve | Products | Search | Twitter | Xnews
Copyright © Rixstep. All rights reserved.