A Roundup Of Leopard Security Features
Thomas Ptacek | October 29th, 2007 | Filed Under: Uncategorized
Our friend Rich Mogull suggested that Leopard is “perhaps the most significant update in the history of Mac OS X - perhaps in the history of Apple”. Good little fanboy that I am, I had Leopard installed this weekend. Let’s evaluate the security advances.
The Good
Leopard gets a few things right.
Sandboxing
What It Is.
The XNU kernel now has a role-based access control system, applied at the system call - mach call layer. You can write flexible policies about what any given program can or cannot do.
Why You Care.
Mail.app should not be allowed to add accounts to your system. Safari should not be allowed to load kernel extensions. iChat should not be allowed to install a backdoored SSH server. Smart security people assume that every application they run contains some hidden bug that will allow attackers to upload their own code into the running program. With kernel-enforced access control, even if an attacker does that, you still stand a chance.
What Leopard Gets Right.
Do not be deceived (and, like me, embarassed) by the sandbox(7) documentation. Leopard sandboxes are flexible and interesting. They’re apparently compiled from Scheme programs (sandbox-compilerd embeds TinyScheme) that live in /usr/share/sandbox. You can break sandbox-compilerd open in TextEdit and read the compiled-in Scheme code; they’ve got a lot of the bases covered, including obscure stuff like SYSV IPC, the BSD sysctl interface, and signals.
What Leopard Gets Wrong.
Three things.
1.
They didn’t document any of this. You can’t officially use this API to secure your own code. We can’t read their code or specifications to test whether it’s secure.
2.
The existing profiles suck. For instance, the Leopard “Quick Look” feature is billed as a test case for sandboxing, because it automatically opens and parses content in your download folder. But all Quick Look sandboxing does is restrict network access. Who cares? A Quick Look exploit is just going to install a trojan somewhere else, and that trojan won’t be governed by sandboxes.
3.
Almost nothing you care about is sandboxed. For instance: Mail, Safari, and iChat.
My Verdict.
It’s not a pretty win, but I’ll take it. Sandboxes are better in a variety of ways than what off-the-shelf Vista provides. Apple should provide an “Instruments.app”-style interface on this feature, like they did for DTrace, and let a community develop around hardening Darwin.
Input Manager Restrictions
What It Is.
Input managers are bundles that are loaded into all running programs. Originally intended for the mundane tasks of internationalization and accessibility, they’ve mutated into a generic plugin facility for all Cocoa programs. If you’re using things like SIMBL, Saft, SafariStand, Sogudi, or Pith Helmet, you’re abusing input managers. Leopard “breaks” them.
Why You Care.
Input managers are terrifying. They’re arbitrary blobs of code that get injected into almost every Mac application. They are a “UI extension interface” in the same way that Back Orifice 2k is a “remote system administration facility”.
What Leopard Gets Right.
Input managers in Leopard are only loaded from “/Library/InputManagers”, not from the user’s home directory, and are only loaded if they’re owned by “root”.
What this means is that you can still get them to work, but the most likely code injection exploits in Safari can’t, because they can’t write to “/Library” and they can’t make files be owned by root.
My Verdict.
A clean win. Apple straightforwardly closed off a major attack vector with minimal disruption to existing third-party plugins.
The Bad
I’m prepared to be wrong about these.
Guest Account
What It Is.
The Leopard “Guest” account erases itself at logout, providing an ostensible “clean” environment for people to use your machine without cluttering it with garbage, accessing your personal information, or betraying their own personal information.
Why You Care.
Sometimes people want to use your computer. In Tiger, if you let them, they can hijack your machine.
What Leopard Gets Right.
The idea of a secure guest account is useful.
What Leopard Gets Wrong.
Everything but the idea of a secure guest account.
For example:
Leopard Guest users can install cron jobs. These are scheduled background tasks, run out of launchd, that will execute even if the Guest user is not logged in. Leopard Guest cron jobs persist after logout.
Leopard Guest users can change the wireless network you’re connected to. Even after logout, when you switch to your “real” account, your Guest’s wireless network selection appears to persist.
Leopard Guest users can mount remote filesystems. Even after they log out, the mount mount in “/Volumes” remains.
The long and the short of it? Leopard Guest users can remain resident on your machine, even after their home directory has been deleted by the Leopard log out process. They can install daemons that listen on network ports to allow themselves back in. Or they can wait in the background for the next “Guest” to log in and steal all their information.
My Verdict.
Pretend like this feature doesn’t exist.
Address Space Randomization
What It Is.
A huge portion of all low-level attacks involve bugs that let attackers corrupt program memory. Most of the time, if you can corrupt memory, you can divert the program from its own code and into code of your choosing.
The most common exploit technique for these bugs is called “ret-to-libc”. Without the gory details, the exploit effectively allows a blob of data the attacker writes into your program to be used as a scripting language, invoking (“ret”) all the functionality the OS exposes to programs (“libc”).
Ret-to-libc attacks require the attacker to know where the various facilities are, so they can be scripted. On OS X Tiger, that was easy: every 10.4.9 Mac kept those facilities at the same locations in memory. In Leopard, the OS randomizes the locations, to make them harder to predict. This feature is called “ASLR”.
Why You Care.
This feature gets top billing as “protection against buffer overflows”; it’s also a first line of defense against heap overflows, uninitialized variable attacks, and integer overflows.
What Apple Gets Right.
Some library offsets are in fact randomized.
What Apple Gets Wrong.
The dynamic linker library (dyld) is not randomized. From what I can tell, ten different Leopard macs booted at ten different times will have the same offset to dyld.
You care because dyld is full of useful functionality. Like, dynamically linking new libraries into memory, or recovering the base addresses for existing libraries.
Can I say right now that you can exploit this to take over a Mac? No. But ASLR is either something you get right, or is simply a speed bump for attackers. Some other things to know about Leopard ASLR:
Library offsets don’t change between invocations of the same program.
Library offsets don’t change between invocations of different programs (Safari and iChat have CoreServices at the same location).
I haven’t seen my library offsets change once, although I have observed that they are different from a seperate Leopard install.
So, assuming for a second that dyld and the Objective-C runtime (vastly more complicated than the standard C runtime, or even the C++ runtime) don’t monkeywrench Leopard ASLR: if I can run code on your box for any reason, I can probably walk past ASLR features in any of your programs. If any of your programs leak information (a far more common problem than buffer overflows), I can probably collect enough information to beat ASLR in every other program.
My Verdict.
This feature removes a talking point argument about Microsoft Windows Vista’s superior security, but it doesn’t address the underlying point of that argument. Cocoa programs running in Darwin are less secure than Win32 programs running under NTOSKRNL, and aren’t even in the same ballpark as Managed C++ or C# programs.
The Irrelevant
None of these features are going to stop your Macbook from getting compromised.
Filevault Encryption
Filevault in Tiger used 128-bit AES keys. Now it uses 256-bit AES keys. There’s a Fields Medal waiting for the person who breaks 128-bit AES. That person can’t necessarily break Leopard Filevault. Awesome.
The funny part about this is that the Filevault keys are still protected by the weakest key in the system: your user password.
Application-Aware Firewall
The Tiger firewall provided all-or-nothing policies for what kinds of connections would be allowed or disallowed into your computer. The Leopard firewall breaks them into per-application policies. That would be great, but the interface offers only a blanket all-or-nothing policy on inbound connections; you can’t tell it not to let iTunes connect outbound.
If you care about about application security policy —- and you should —- someone like Unsanity is inevitably going to rig up an OS X intrusion prevention system built on Sandboxes, and that system will give you fine-grained control over what iChat and iTunes are allowed to do. I’ve never bothered configuring the OS X firewall, and I’m not going to start in Leopard.
Tagged Downloads
Yes, it’s true, when you download a program with Safari and run it for the first time, you will get a dialog box warning you that you downloaded the program and are running it for the first time. I give the average Leopard user approximately 6 hours before clicking “OK” on this dialog becomes a function of their autonomous nervous system.
Digital Signatures
You can sign executables in Leopard. If you allow a signed executable to run after you download it, you ostensibly won’t be bothered with dialog boxes for future downloads from the same author. Awesome. That will shave 45 milliseconds off the download process for the average Mac user.
This feature gets prominent billing in some Leopard round-ups, but it shouldn’t. I haven’t found a signed program to verify yet. From what I can tell, nothing shipped with Leopard is signed (possibly excepting kernel extensions). I hexfiended NOPs into a variety of programs, thus invalidating any conceivable RSA signature on them. They ran just fine.
Even if third-party code is signed, if every binary on the system they depend on remains unprotected, code signatures won’t do anything to stop trojans on your system.
bob
October 29th, 2007 2:41 pmDid they add cookies on the stack ? Does the new version of gcc includes propolice ?
dragonfrog
October 29th, 2007 3:27 pmI’m surprised you put the per-application firewall stuff into the “irrelevant” bin.
Granted, if Apple is being true to form, the GUI on the thing will probably be a crippled non-entity, but I never used the GUI to configure the firewall before, and I don’t expect to do so anytime soon.
That said - do you know if the per-application features are available through the ipfw command, or is it a “sandbox” feature? Are they documented in a man page?
Seriously now - Apple’s offering is for inbound connections only? That’s what you were already blocking with your basic packet filtering firewall anyway, innit? The thing you want to do now is to tie outbound access to the apps you trust to have it. There I was figuring they were building the functionality of Little Snitch more robustly into the OS, and it turns out they didn’t even get that far?
Martin
October 29th, 2007 4:35 pmIs MacOSX sandboxing affected by syscall wrappers flaw described by Robert Watson?
grey
October 29th, 2007 5:11 pmI dunno, I’d say the new firewall prompt pretty much makes little snitch not worth buying (not that I bought it in the past). It sure would be nice if OSX ported pf (seeing how I can even run it on Windows now) though; throttledpro is another shareware app that would be put to death on any other OS with a more robust fw system.
I noticed the aes-128->256 change with filevault, but I somehow suspect it’s still susceptible to Ralf & Jacob’s filevault attacks which for the most part didn’t rely on trying to break aes at all [since filevault had several other unlock vectors] (we’ll see).
I don’t think security was really a touted feature of leotard, but it’s nice to see some incremental improvements at least; though yeah Apple still might not /get it/ they’re at least taking steps.
Jane
October 29th, 2007 5:29 pmAs useless as the Leopard firewall is, if you’re looking for an application to monitor outbound connections, use Little Snitch (http://obdev.at/products/littlesnitch/index.html). It’s probably best known for being an app that people use to keep apps from phoning home with a pirated serial, but it does the job well. It’s an annoying initial week or two after setup when you have to whitelist every connection in every app (e.g. all servers over port 80/… in Safari or Firefox, ssh only to some.server.com, etc.), but it’s well worth the effort.
There was some rumor long ago about there being some rudimentary ripoff of Little Snitch in Leopard, but I think that was just a misunderstanding about the way Leopard’s firewall is configured.
Thomas Ptacek
October 29th, 2007 6:54 pmdragonfrog, Jane: my impression is, yes, they have not yet caught up to Little Snitch. This is something Microsoft got beat over the head with in XP SP2. I don’t think inbound firewalling is my Mom’s chief security concern; outbound firewalling, catching the malware she will inevitably install, is.
mds
October 29th, 2007 7:48 pmRe. FileVault: Even with a well-chosen FileVault password, there’s still the problem of the weak RSA-1024 encryption in use. In addition, the keychain shouldn’t be protected by the login password and the FileVault password shouldn’t be stored in the keychain at all.
Re. Firewall: What’s your opinion of the devastating review by Heise Online (http://www.heise-security.co.uk/articles/98120)?
Ralf
October 29th, 2007 8:02 pmASLR: I’ve used printf as a test function and have looked at its address across reboots in mDNSResponder [given its history, this program should be one of the highly secured daemons now]. And yes, indeed the address changed. This is a counterpoint to your 3rd ASLR observation; the first two hold for me as well.
SandboxingThe approach very much remind me of Cowan’s AppArmor. Apple using a TinyScheme interpreter here is more than a bit funny. Did you notice that sandbox-compilerd is be executed as root from the seatbelt kext? And that non-priviliged users can specify their own profiles to sandbox-exec… Moreover, let’s not forget that TinyScheme has I/O functionality and is not the tightest code base… *evilgrin* [caveat: sandbox-compilerd seems to be sandboxed itself, which makes sense]
Code SigningOn my machine, only the kernel extensions seem to be signed, none of the Applications are. You’re looking for a CodeSignature in a Contents directory.
Ralf
October 29th, 2007 8:38 pmOn the topic of ASLR again: dyld seems to get its information from /var/db/dyld which is updated at boot time by update_dyld_shared_cache(1). See /System/Library/LaunchDaemons/com.apple.dyld.plist.
John
October 29th, 2007 8:59 pmThomas, is the stack and heap randomized or is it only certain dynamic libraries loaded by dyld?
Thomas Ptacek
October 29th, 2007 9:04 pmJohn — printf(”%p\n”, &address_of_stack_variable);
[7:56pm:~] CREST:tqbf [0:41]% ./f
0xbffff3bc
[7:56pm:~] CREST:tqbf [0:42]% ./f
0xbffff3bc
[7:56pm:~] CREST:tqbf [0:43]% ./f
0xbffff3bc
Not looking too good there.
Thomas Ptacek
October 29th, 2007 9:05 pmAs for the heap — printf(”%p\n”, malloc(10))
[7:58pm:~] CREST:tqbf [0:53]% ./f
0×100120
[7:58pm:~] CREST:tqbf [0:54]% ./f
0×100120
[7:58pm:~] CREST:tqbf [0:55]% ./f
0×100120
Thomas Ptacek
October 29th, 2007 9:13 pmRalf: awesome data points. I don’t see evidence of tinyscheme I/O compiled in, though — do you?
Ralf
October 29th, 2007 9:31 pmThomas: uhm. where? strings on the sandbox-compilerd binary gives me the initialization file for TinySCHEME 1.38. Isn’t that evidence enough?
The kernel part has a debugging feature btw (security.mac.seatbelt.debug). I haven’t even gotten into how friggin’ kickass DTrace is for vulnerability development.
On a side note: Exec permissions were removed from the stack in 10.4.x (I don’t remember x at the moment) on Intel. As far as I see, the heap however still has exec permissions. Isn’t ASLR mostly pointless if the heap is not at a randomized address and moreover the text segment of the app/daemon (as well as dyld, as you rightly point out) are not ?
Thomas Ptacek
October 29th, 2007 9:35 pmThere’s a “with-output-to-file” defun in there too. But tinyscheme is configurable.
Agree, the ASLR here looks pointless.
Sean
October 29th, 2007 10:10 pmAm I the only one that found the comment about using Application Enhancer to create an IDS haxxie to be ironic?
I mean come on, APE got their heads handed to them by MOAB 8 and then they didn’t do their homework and killed a number of leopard installs.
Thomas Ptacek
October 29th, 2007 10:26 pmWho said anything about APE?
Sean
October 29th, 2007 10:29 pm“If you care about about application security policy —- and you should —- someone like Unsanity is inevitably going to rig up an OS X intrusion prevention system built on Sandboxes, and that system will give you fine-grained control over what iChat and iTunes are allowed to do. I’ve never bothered configuring the OS X firewall, and I’m not going to start in Leopard.”
Thomas Ptacek
October 29th, 2007 10:35 pmYeah Unsanity does things besides APE. They’re pretty smart.
Bbananna
October 29th, 2007 10:50 pm“Yeah Unsanity does things besides APE. They’re pretty smart.”
Ah. I’m sure. I was just reading how their sensible engineering hosed a whole slew of Leopard installs. Cool - and smart too!
Bbananna
October 29th, 2007 10:56 pm“Yeah Unsanity does things besides APE. They’re pretty smart.”
No they’re not smart.
Thomas Ptacek
October 29th, 2007 10:57 pmObviously, we disagree.
Jane
October 30th, 2007 3:00 am@Thomas, now the question would be whether or not your mom, my mom, or for that matter, any user, will be able to discern what is legitimate outbound traffic vs. what isn’t. And even if they did, if they’d have the patience to white/blacklist any of that traffic on a regular basis, particularly after app installation or maybe upgrade.
I’ve been using Little Snitch since forever because it’s been so useful in every way, but I still run into the occasional application where it’ll just be like..wtf? I’ll have no clue as to what it is or where it’s trying to connect to. And then I’ll google around, and it’ll be like, oh, it’s only Maya. And for some applications, I’ll have a whitelist of servers to connect to, but I’ll still want individual confirmation of some unknown server, just in case, and sometimes that leads to a dozen temporary rules in one day (like, say, ssh, ftp, svn).
Even if such a thing was added to Leopard, I can only imagine most people ignoring it and allowing everything all the time.
Ralf
October 30th, 2007 6:45 am@Thomas: Sorry for the incorrect information about sandbox-compilerd. I just re-checked. sandbox-compilerd is now (in the final release) executed with the uid of the user submitting the profile to sandbox-exec. It was different in a earlier beta that I had temporary shell access to.
mark
October 30th, 2007 10:28 amWhile I agree that as a security feature the guest account is pretty useless -as a feature I think it is still ok - for example when someone I know and trust (and is more often than not a ‘non -computer’ person) needs it I can let them use my computer without them messing up my settings or leaving loads of rubbish all over the place (like another account)
Ralf
October 30th, 2007 11:26 am@bob: SSP is integrated into the system gcc. Whether Apple actually compiles their code using -fstack-protector has not yet been checked by me.
Ralf
October 30th, 2007 11:35 amOne more thing: Apparently the libc now detects double free()’s, however it does not cause an abortion of the program. Check the following code:
$ cat > t.c
#include
main(){void *m=malloc(1);free(m);free(m);printf(”will this get executed?\n”);}
EOF
$ gcc -o t t.c && ./t
t(23266) malloc: *** error for object 0×100120: double free
*** set a breakpoint in malloc_error_break to debug
will this get executed?
$
Pity.
Thomas Ptacek
October 30th, 2007 11:55 amLook at the mDNS* functions in mDNSResponder. It looks like some of their code is compiled with stack protection.
It seems like a bit of a moot point: is there any evidence of heap protection at all?
static int
_stub() {
typedef int (*fptr)(void);
u_char *buf = malloc(10);
memcpy(buf, “\xb8\x0a\x00\x00\x00\xc3″, 6);
return(((fptr)buf)());
}
_stub() -> 10
Thomas Ptacek
October 30th, 2007 11:57 amMy guess is that if you set the system up so that everything runs with MallocErrorAbort, things will randomly crash.
Thomas Ptacek
October 30th, 2007 11:57 ammark: the Guest account is safe if the person you’re letting borrow your computer is trusted. But if you trust them, why do you need a secure Guest account?
mark
October 30th, 2007 12:42 pm“But if you trust them, why do you need a secure Guest account?”
Because they can use your computer without making a mess. I don’t like people using my account (because I have bookmarks setup, my recent history is useful for navigation etc. - not security just don’t want my stuff moved) and on my last install I ended up with a couple of ‘guest’ accounts that clutter up backups and take up space. So just tidiness really.
I agree though the ’secure’ bit is a red herring and as you point out totally meaningless. It should say - “let people you trust use your computer without inconveniencing you” but I guess that is not as sexy marketing wise.
bob
October 30th, 2007 3:24 pm@Tom:
“But if you trust them, why do you need a secure Guest account?”
It supposedly the other way around (although I admit Apple’s thinking is totally flawed) : if you need a secure temporary account on any Mac OS X system, then the ‘guest account’ feature garantees you that the owner of the system will not look at your cookies and everything after you log out.
Of course this reasoning is flawed in the sense that if you don’t trust the person who lends you his computer, then there’s nothing to prevent him (or a trojan) from having tempered with it in such a way that he’ll snoop on you. So that feature does not give you any peace of mind.
However, would Mac OS X be 100% signed, checked with TPM with the option of only launching ‘trusted’ binaries (read: entirely crippled), then this feature would make sense — you’d know that no 3rd party tool is snooping on that account.
Maybe in a next release, when they decide to rename it to ‘iPhone OS X’ and finally be done with those pesky 3rd party applications
Thomas Ptacek
October 30th, 2007 3:25 pmDon’t let the “secure” Guest accounts in Leopard fool you. You aren’t just trusting the owner of the Mac; you’re trusting every other person that owner has ever given Guest access to.
Dave G.
October 30th, 2007 4:03 pm@Ralf:
AFAIK, Apple’s malloc implementation has supported double free() detection for awhile. I think I noticed it back in Jaguar. While continuing probably isn’t the right course of action, it won’t actually perform the second free().
Histrionic
October 30th, 2007 4:15 pmI ran:
and got:
Identifier=com.apple.Safari
Format=bundle with Mach-O universal (i386 ppc7400)
CodeDirectory v=20001 size=7621 flags=0×0(none) hashes=375+3 location=embedded
Signature size=4064
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
Info.plist entries=23
Sealed Resources rules=9 files=283
Internal requirements count=1 size=68
Does this not mean that Safari is signed? Am I misinterpreting the output?
Thomas Ptacek
October 30th, 2007 4:32 pmAwesome. Safari is signed.
Now crack it open, jump to the X86-32 code (Safari doesn’t have a X86-64 binary), pick an arbitrary offset, and NOP it (flip a byte to 0×90). Keep a backup copy, because you just broke Safari.
You just patched Safari, just like a virus would.
Restart Safari. Mine restarts just fine! When are these signatures being verified? I didn’t get a warning message of any sort.
I totally believe that binaries can be signed in Leopard, and even that it is easy to do so. I just don’t see what it’s accomplishing.
Alexei Svitkine
October 30th, 2007 5:43 pmYou’re missing the point of Code Signing.
It’s not meant to prevent applications from launching.
It’s meant to verify that the application has been created by the genuine author of a given signature, and not tampered with.
The ONLY place where this is used is for accessing KeyChain. If you get a new version of Safari, and its signed by the same author, then you will not have to click “OK” to KeyChain security dialogs.
You may also access this information programmatically, asking the system “is APP X signed and is the signature still valid?”.
Code signing simply says “X and Y are the same program” because their signature matches. If a signature is compromised, this will no longer be the case, and you will have to manually grant access to the keychain entries the app is interested in.
These things also apply to things like Parental Controls … basically the code signing feature lets Leopard say “is X and Y the same”. If Parental controls specifically allow Safari… then this will only be the case as long as Safari has a valid signature.
Alexei Svitkine
October 30th, 2007 5:50 pmAlso, once something’s signature has been compromised, you may no longer use an “Always allow” option in a KeyChain dialog.
Thomas Ptacek
October 30th, 2007 5:52 pmThank you for the test case. I glibly report: still broken. I locked down the Guest account to nothing but Safari. I verified that I couldn’t start arbitrary apps. I verified that I could start Safari. I scribbled over the Safari image. I started Safari in the Guest account. Still ran.
When are they verifying these signatures?
In addition to questioning whether you’re correct in fact, I’d also like to question whether you’re correct in spirit:
You say “I’m missing the point of code signing”.
I don’t think I’m missing the point. I’m questioning the point. So Safari (say) has to be signed before it presents me with that useless Keychain dialog? Ok! The attacker that can overwrite Safari can run arbitrary code under your UID, long before that dialog comes into play. They can also overwrite files inside your home directory and Library folder.
I am again suggesting that Leopard code signing does not yet do anything to improve security.
Chris Adams
October 30th, 2007 7:42 pmI have to agree with you - even if we assume that users would never blindly okay the changed application, it’d be much better if Safari was sandboxed and couldn’t trivially trojan your account in the first place.
Thomas Ptacek
October 30th, 2007 11:07 pmBy the way, one of the best parts about working on security in a single-user environment — even if program Z can programmatically ask if program X has been signed by user Y, if Z and X are running under the same UID, X can guarantee the answer to the question is “yes”, without knowing Y’s key.
bobdole
October 30th, 2007 11:38 pmThe first thing I did was run out and try to see ASLR in action with a simple printf the function pointer main()…I saw what you say, addresses not changing…however I don’t think it’s necessarily a correct test…while searching around I saw this in the ld man page
” -pie This makes a special kind of main executable that is position independent (PIE). On Mac OS X 10.5, the OS will load a PIE at a ran-
dom address each time it is executed. You cannot create a PIE from .o files compiled with -mdynamic-no-pic. That means the codegen
is less optimal, but the address randomization adds some security.
“
and then I noticed that my gcc -v doesn’t include ld anywhere in it, must less have anything related to this -pie option…
something to look into anyway, as I dropped it there and had to move on and wait for proper documentation of what’s going on
Also, can you explain what you did with the cron test with guest? I just want to try it (for instance to see it opening a backdoor listener)
bobdole
October 30th, 2007 11:41 pmI’m not bob btw
Thomas Ptacek
October 30th, 2007 11:44 pmThe OSX stack isn’t randomized. It wasn’t advertised as randomized.
Nobody is disputing that libraries are randomized. They are. Unfortunately, there are core system libraries that are not; therefore, memory corruption bugs probably still yield control of the process.
(PIE, by the way, is not really a security feature).
Regarding cron? Easy! Turn on fast user switching. Switch to Guest. Launch a shell. Type “crontab -e”; you’ll get a crontab file. In another window, you can “man 5 crontab” to see how this work.
A simple cron job:
*/1 * * * * /bin/sh -c “echo foo > /tmp/bar”
This will run every second (the fields are minute, hour, weekday, day-of-month, month-of-year, if I remember correctly).
Rosyna
October 31st, 2007 12:01 amWanted to make a quick point before I went to bed.
Just about everything shipped on 10.5 is signed.
codesign -dvv /bin/ls
And if you want to test the trust on 10.5 and Safari, turn on save passwords in safari, make a webpage with a password field, type something in it (to save the password), quit Safari, reopen it, go back to that page, confirm the password was saved, quit Safari, modificate the Safari binary, reopen the page, and see how it handles the password page.
I have not actually tested this yet.
Thomas Ptacek
October 31st, 2007 1:44 amAnother excellent data point. This is my whole scam; write something hyperbolic, wait for smarter people to correct me. ON MY BLOG. HAH HAH HAH.
Thomas Ptacek
October 31st, 2007 1:52 amI should go look this up, but even if it’s easy to verify the signature on /bin/ls, is it easy to check the signatures on everything ls(1) depends on? By default, that includes curses, gcc_s, and libSystem.
This is a _classic_ Unix attack.
darkalias
October 31st, 2007 4:27 amThomas, thanks for your insight. There seem to be some concerns regarding the Leopard firewall, what’s your opinion to these points?
http://www.eweek.com/article2/0,1895,2209676,00.asp
Andy
October 31st, 2007 5:28 amGuest accounts can also be managed via Parental Controls - which I imagine addresses a lot of the issues mentioned (eg. ‘user cannot mount network volumes’, ‘user cannot use Terminal application’ etc)
Paul Suh
October 31st, 2007 7:31 amTo Martin: no, sandboxing is not affected by the race condition attack that Robert Watson came up with on syscall wrappers. I talked to him about this directly at WWDC. I’m pretty sure that’s one reason why the sandbox profiles are pre-compiled and handed to the seatbelt kext, so that there is no context switch between the kernel and userland.
To folks who are concerned that they can write nulls to the Safari binary and still have it execute: code signing is checked when a particular block of a binary is loaded into memory from disk. Each block apparently has a separate embedded signature. This is so that if you have a huge binary the system does not need to check the whole thing before it launches. If the virtual memory manager tries to load a block with a bad signature, the app will exit. Thus, just writing a few nulls to an arbitrary point in the binary will not test the app signing capabilities if the code path does not cause the block you modified to load. Testing by using the keychain dialog is a correct test, since that will check the signature on the entire binary.
According to the materials presented at the code hardening session at WWDC, stack canaries are available on Leopard. I don’t know if they’re on by default. I’m on the road on a crappy hotel connection with no access to check right now.
I also disagree about the effects of ASLR being the same across boots *of the same machine* for non-dyld libraries. If the offsets are different across different installs, that vastly complicates the problems of an attacker, since an attack that succeeds against one machine is much less likely to succeed on a second machine. It reduces the attack surface that is open to worms and attack trojans.
Thomas - one thing that you didn’t touch on is W^X protection on the heap. I believe this is on by default. Thus, any memory page that is writable is not executable, and an attempt to write to an executable page will crash the app. There are special provisions for making W and X memory pages for things like JIT compilers, but those people should know what they’re doing.
I do agree about the weakness of protections on the Guest account — but then if you are serious about securing your machine you shouldn’t be opening up the Guest account.
Riccardo Mori
October 31st, 2007 8:39 amYou know, maybe it was just a typo. “Co-designing”, not “Code signing”…
Thomas Ptacek
October 31st, 2007 8:58 amPaul:
The Watson syscall wrapper attack has nothing to do with context switches in acquiring the policy. It has to do with operations inside the kernel that sleep kernel threads or processes: if you, for instance, do a NAMEI multiple times, there’s a potential race between them.
I’m not saying Leopard is vulnerable to the problem, just that it’s not easy to simply know whether it’s there.
Stack canaries are present on Leopard. They don’t do anything about (far more common) write32 problems from heap and integer overflows. But they’re there.
Regarding ASLR: not randomizing dyld is gameover.
Regarding W^X: check the comment thread. I have a snippet of code that tests whether the heap is nonexecutable; it is not. You can malloc a buffer, copy a string of assembly opcodes into it, and call it.
Andrew Jaquith
October 31st, 2007 9:38 amTom, totally rockin’ post, as always.
Thomas Ptacek
October 31st, 2007 9:40 amRegarding code signing the whole binary versus individual blobs: give me a use case that demonstrates signature verification in action. If it’s reasonable, I’ll take the time to test it, and report my results back here.
Note that this basically has no bearing on anything. Code signatures on Safari don’t mean anything if Safari will still run when the signature doesn’t verify; protecting nothing but keychain was a bad security call on Apple’s part (or a necessary tradeoff with the same effect as a bad call).
Thomas Ptacek
October 31st, 2007 9:41 am… but those data points, also excellent, and thanks for taking the time to write them.
Thomas Ptacek
October 31st, 2007 9:43 amdarkalias: my take on the firewall kerfluffle is that it’s a relatively minor issue. I want to know how they performed the upgrade, and get a definitive answer on whether the Leopard upgrader clears firewall settings.
I don’t know whether it does because I have never bothered with the OS X firewall, which has always had a ridiculously lax built in policy. I see the value in outbound firewalling, but if your security out-of-the-box depends in any way on OS X’s inbound firewalling, you are playing to lose.
Ralf
October 31st, 2007 10:21 am@Rosnya: riiiiiiight. So everything’s signed but no action is taken upon verification failure. I did the following test, which you can easily repeat:
$ mkdir /tmp/cstest
$ cd /tmp/cstest
$ cp /bin/ls .
$ otool -l ./ls|grep eip
ss 0×00000000 eflags 0×00000000 eip 0×000023c4 cs 0×00000000
$ # ok, we see the entry point is at 0×23c4, let’s fire up gdb
$ gdb ./ls
(gdb) x/10i 0×23c4
0×23c4 : push $0×0
0×23c6 : mov %esp,%ebp
0×23c8 : and $0xfffffff0,%esp
0×23cb : sub $0×10,%esp
0×23ce : mov 0×4(%ebp),%ebx
0×23d1 : mov %ebx,0×0(%esp)
0×23d5 : lea 0×8(%ebp),%ecx
0×23d8 : mov %ecx,0×4(%esp)
0×23dc : add $0×1,%ebx
0×23df : shl $0×2,%ebx
(gdb) q
$ # great, the above code can be optimized
$ port install hexedit
$ # goes into hexedit and changes the first occurence of 83c301
$ # (add $0×1,%ebx) to 0×43 0×90 0×90 (inc %bx)
$ ./ls
$ ls
ls
$ # great, where’s the codesigning check again???
$ sudo dmesg
CODE SIGNING: cs_invalid_page: p=6208[ls] clearing CS_VALID
$ # ahh.. it logs it, but it doesn’t do anything about it.
As 0×23c4 is the entry point and there are no branches up to the inc %bx statement, this lies clearly in the codepath. So it seems to me that everything is signed, but not much is checked. I consulted the codesign(1) man page for further information. The “OPTION FLAGS“ section is interesting. It looks like you can specify several events to occur when verification fails: kill looks like the most appropriate action to me for system tools and apps/daemons that should not be modified.
Thomas Ptacek
October 31st, 2007 10:25 amSo kern_exec is checking signatures?
Ralf
October 31st, 2007 10:26 am@Thomas: there are actually two firewalls included with Leopard now. ipfw which seems have no rules set by default and a hybrid kernel-level/user-level firewall which consists of a socketfilterfw userspace process and the com.apple.nke.applicationfirewall kext module. The ALF looks interesting because apparently it can interact with the code signing verification facility. I have not further investigated this, I hope Apple release some 10.5 source soon.
Ralf
October 31st, 2007 10:28 am@Thomas: “So kern_exec is checking signatures?”. I do not exactly know which part of the kernel checks the signatures, but yes they are checked. And running strings /mach_kernel|grep “CODE SIGNING” indicates to me that they are checked by the core kernel and not by some kext.
Nick
October 31st, 2007 10:37 amI think you’re missing the point of guest accounts somewhat. Security has different meanings to different people.
I would never dream of giving my computer to someone who I thought had the skills and inclination to hack into my admin account and install malware.
I might well lend my computer to someone that I would expect to have a nose around my private documents, or who might accidentally delete something important due to a lack of computer skills.
The secure guest account means I don’t have to look over my little brother’s shoulder when he asks if he can borrow my laptop to check his email.
Histrionic
October 31st, 2007 11:04 amI was just trying to point out that the signature was there in Safari (and other apps I’ve examined), not implying anything else.
The original post said “I haven’t found a signed program to verify yet,” so I was trying to helpfully find one.
Also, AFAIK, Parental Controls (aka Managed Client) looks at the path of the application being controlled. It assumes that a system administrator or authorized user has control of the filesystem, which of course may or may not be the case but should be in a managed environment. But, it sounds as if the controls should at least be less breakable than they were in earlier Mac OS X versions (i.e. copy the application and change the application ID). If you allow only Safari in /Applications, that should be the only copy of Safari that is allowed to run.
It would be nice to have code signing tie into Managed Client application controls, if not now then in the future.
Thomas Ptacek
October 31st, 2007 12:04 pmNick: two obvious responses. First, if you’re only giving the machine to trusted guests, why bother with a security feature for them? Second, it was advertised as a security feature.
bobdole
October 31st, 2007 12:22 pm@Ralf
If you want to see the code signing interact with the per-application firewall, open the developer tool “BigTop”…it adds itself with a “allow all incoming connections” rule
p.s. this IS retarded having this conversation via blog comments rather than mailing list…
Thomas Ptacek
October 31st, 2007 12:28 pmTrue, Google does do a much better job indexing mailing list posts.
Andy Fore
October 31st, 2007 12:31 pmOne possible solution for the guest account is to set the login shell to be
. This should prevent anyone from being able to login with the Guest account.
Ralf
October 31st, 2007 12:33 pm@Thomas: so how about switching to a google-groups thingie or creating a mailing list for further OSX security discussions? I could set one up.
@bobdole: thanks for the BigTop hint?
Ralf
October 31st, 2007 12:38 pm@bobdole: no question there of course. thanks!
@Dave G.: I could swear that I tested the double free() on my old 10.4.10 pbg4 a couple of weeks ago without any warnings. I’ll re-check later this evening, when home.
Thomas Ptacek
October 31st, 2007 12:40 pmAndy, it’s pretty easy to disable the Guest account, and I’d recommend doing so.
Ralf: I’ll move to a Google Group when Dave Aitel moves to one. =)
Ralf
October 31st, 2007 12:48 pmOK, then. I’ve set up a mailing: osxsec AT coderpunks DOT ORG.
The address works, the mailman installation isn’t quite finished. System should be ready a go-go in about 6 hours. Interested parties may already subscribe, mail will be queued.
dragonfrog
October 31st, 2007 1:10 pm@Ralf
There’s also the securityfocus group focus-apple.
It was rather lively when it first started, but has quieted down since then. An infusion of curious and technical people wouln’t hurt anything there.
Ralf
October 31st, 2007 1:10 pmI’m surprised. Apple actually has some decent info on code signing:
http://developer.apple.com/releasenotes/Security/RN-CodeSigning/
(no ADC account required). Unfortunately no info on sandboxing, stack protection the ALF and and library randomization…
Nick
October 31st, 2007 1:35 pmThomas: “if you’re only giving the machine to trusted guests, why bother with a security feature for them?”
I stated in my post that security (and so, by implication, trust) has graded meaning. There are plenty of people that I trust not to hack into my computer (I don’t know anyone who would try, in fact) but there are very few people I would want to give the full run of my machine to do with as they pleased.
When other people (whom I trust) use my computer they may:
1) Read personal stuff I don’t want them to like my email or diary
2) Leave downloaded files all over my desktop
3) Install random applications that I have no use for
4) Change my settings or delete important files
The guest account gives them the freedom to mess around in a non-malicous way without causing any damage. Despite what you assert, security against casual or non-malicious harm *is* a useful feature.
That in no way dimishes your argument that security against a targeted, malicous attack would be a *more* useful feature, of course. I just fail to see how guest accounts are “bad”. “Bad” to me implies that we are less secure with them than we were without.
“Second, it was advertised as a security feature.”
If we accept that yours and my definitions of security are not the same, it is safe to suppose that perhaps yours and Apple’s views are not the same either.
Please note that I do not actually disagree that many of Apple’s security enhancements are flawed, and I think that you’ve hit the nail on the head with this post. But I think you should recognise that features like the guest account actually do address the privacy concerns of a lot of Apple’s users, most of whom do not find themselves under constant attack from uber-hackers in the course of their day.
Matt
October 31st, 2007 1:49 pmThomas: You and Nick are looking at Guest Account with two different threat models in mind. For the attacker that you’re thinking about (technically skilled, highly motivated), you’re correct, Guest Account is horribly broken. For the attacker that he’s thinking about (unskilled, unmotivated, perhaps more likely to do damage via stupidity than malice), he’s correct, Guest Account is a nice safety net.
Ralf: Join focus-apple at securityfocus. If nothing else, you can troll Dave Schroeder when you’re bored.
PaX Team
October 31st, 2007 1:59 pmaccording to paxtest (just the ones that i think test the system properly, ASLR tests need some patching for OS X):
Executable anonymous mapping : Vulnerable
Executable bss : Vulnerable
Executable data : Vulnerable
Executable heap : Vulnerable
Executable stack : Killed
Executable anonymous mapping (mprotect) : Vulnerable
Executable bss (mprotect) : Vulnerable
Executable data (mprotect) : Vulnerable
Executable heap (mprotect) : Vulnerable
Executable shared library bss (mprotect) : Vulnerable
Executable shared library data (mprotect): Vulnerable
Executable stack (mprotect) : Vulnerable
Executable shared library bss : Vulnerable
Executable shared library data : Vulnerable
Writable text segments : Vulnerable
that is, only the stack is non-exec by default, and mprotect has free reign.
thomas said:
> (PIE, by the way, is not really a security feature).
it is a security feature inasmuch ASLR itself is (obfuscation that happens to be useful in practice) as it is the last piece needed to fully randomize the address space (other parts don’t need userland support, the main executable on ELF and similar systems does).
Mike
October 31st, 2007 2:25 pmThomas: I don’t understand why you think using signing to protect the keychain is “irrelevant”? You argued for dozens of posts back in April that it was a really big deal that you could use (a now closed) vector to get access to a user’s keychain:
http://www.matasano.com/log/809/a-little-challenge-to-our-mac-advocate-friends/
Either protecting the keychain is important or it’s not. You can’t have it both ways. If you want to argue that signing should be used for even more purposes, fine. But you can’t argue that this is an “irrelevant” feature unless you want to argue that your entire exercise back in April was just an exercise in idiocy.
As an academic researcher myself, I understand that your default instinct is to be critical wherever possible. But you should at least try to be intellectually consistent in your criticisms.
Thomas Ptacek
October 31st, 2007 2:26 pmI concede, the “Guest” account in Leopard is not useless. Just dangerous. =)
Thomas Ptacek
October 31st, 2007 2:27 pmThe “mprotect” tests just test whether you can ret-to-mprotect to make the stack executable again?
jf
October 31st, 2007 2:30 pmThe issue that Apple is no doubt hitting with its ASLR implementation is that the Mach-O spec is totally broken in this respect, it requires that sections/segments be at fixed/constant offsets from each other. I’ve never verified that things work the way the ABI docs say they do, but basically this is what Apple has to say:
“Mach-O position-independent code design is based on the observation that the __DATA segment is always located at a constant offset from the __TEXT segment. That is, the dynamic loader, when loading any Mach-O file, never moves a file’s __TEXT segment relative to its __DATA segment. Therefore, a function can use its own current address plus a fixed offset to determine the location of the data it wishes to access. All segments of a Mach-O file, not only the __TEXT and __DATA segments, are at fixed offsets relative to the other segments.
Note: If you are familiar with the Executable and Linking Format (ELF), you may note that Mach-O position-independent code is similar to the GOT (global offset table) scheme. The primary difference is that Mach-O code references data using a direct offset, while ELF indirects all data access through the global offset table.”
So Basically, ASLR in OSX is always going to be broken/limited to base randomization unless they change the ABI.
Thomas Ptacek
October 31st, 2007 2:33 pmMike, take a second and explain how exactly code signing stops people from using LD_PRELOAD from accessing keychains?
Thomas Ptacek
October 31st, 2007 2:44 pm(Point being, if you can run any code anywhere under the UID of the person who will run the Keychain-accessing app, you can use DYLD_INSERT_LIBRARIES to add arbitrary code — there’s no one key domain for any given Cocoa application).
Gordon
October 31st, 2007 2:50 pmSo does this stuff get reported to Apple? Would you expect it to be fixed in 10.5.1?
Sigivald
October 31st, 2007 3:25 pmTo double up on what Matt said, wouldn’t a “technically skilled, highly motivated” attacker that you leave along with the guest account long enough to do anything useful (ie, you’ve left him alone for at least a few minutes) be able to just reboot the machine with a boot image on a CD or flash key, and do whatever he felt like?
A really motivated attacker would have an image that would automatically mount and backdoor your root drive, in fact.
Security (and “secure”) is definitely a graduated sort of thing.
“Guest” might well be vulnerable to some sort of cron attack (though of course the worst it seems able to do is run jobs as guest), but as far as threats go, that’s very low on the scale.
Not a big “security” win for Apple, but a useful convenience that helps with a more practical sort of security that maps to a reasonably common real-world use case and threat model.
Thomas Ptacek
October 31st, 2007 3:42 pmI concede that there is some use to a “Guest” account that cleans itself up after use. None of that use has anything to do with security, though.
Coding my Life
October 31st, 2007 3:54 pmSecurity Features in Leopard
Ein interessanter Artikel über die neuen Security Features des MacOSX 10.5
Mike
October 31st, 2007 3:55 pmThomas, I think I may have confused you when I mentioned “now closed” vector. That was a reference to the fact that Input Managers are better protected now (a crucial component in your previous hypothetical attack). It wasn’t referring to LD_PRELOAD.
Your 9:40 am post states that you agree code signing is helping protect the keychain. Nobody said that it would reduce the probability of an exploit to 0. That would just be stupid.
So my question remains: In April you made a big fuss about gaining access to a user’s keychain. Now you say it’s not worth protecting. Which is it?
(My personal opinion is that it’s worth protecting, but that’s not the question.)
Ralf
October 31st, 2007 4:55 pmOK. Quiz time: Does anyone have a clue what exactly the TMSafetyNet kext does? It is a security policy loaded by default, called “Safety net for Time Machine”, in the kext directory there’s a binary called bypass that uses mac_set_proc(3) (see http://fuse4bsd.creo.hu/localcgi/man-cgi.cgi?mac_set_proc+3 for example, unforunately 10.5 has no man page for this function).
Michael
October 31st, 2007 6:35 pm“I give the average Leopard user approximately 6 hours before clicking “OK” on this dialog becomes a function of their autonomous nervous system.”
I disagree, I think the average Leopard user will rarely see this dialog, and will quickly learn that it should only show after they have downloaded a new application.
When they first see this dialog out of the blue, unexpected, with a web site and app name they don’t recognise, _that’s_ when it will really help. And I also think it’s one of the more practical and immediately useful ways of blocking malware.
Mitchel Ashley
October 31st, 2007 6:52 pmSeems kind of late to me. Apple is really just an also ran. There are still way more windows users and at the end of the day and that isn’t changing, Vista is a fortress with out many peers, the only I can think of is Cobia, in terms of security. These are all just bolt-ons trying to add security, after the fact, to an iPod syncing platform. Where is the NAC integration?
And I’m no apple hater, I used to use them quite a bit.
bobdole
October 31st, 2007 7:21 pm@Ralf
Seriously, that is exactly the type of question to put on the apple-focus list instead…this will all get sorted out in time, but you need to have it somewhere with more visibility than buried 87 comments down on a blog post!
I mean, I definitely support this discussion 100%, but I don’t like reading it like this, with everything jumbled together
Come on Thomas…step up and move the discussion to a reasonable location
Thomas Ptacek
October 31st, 2007 7:44 pmI guess, Mitchell. I mean, like we say about Apple, market irrelevance is a security feature. If running MacOS is like living in Elgin instead of the West Side, running Cobia is, what? Decatur?
Thomas Ptacek
October 31st, 2007 7:45 pmbobdole: you are suggesting I should — what, close comments on this post?
Thomas Ptacek
October 31st, 2007 7:49 pmMike: if you believe reducing the known vulnerabilities in a product to zero is “just stupid”, you reject the concept of software security, and I don’t have much more to contribute to the discussion after that.
Security is hard. Cryptographic security is harder. An RSA signing scheme where verification happens in an untrusted environment fails.
Thomas Ptacek
October 31st, 2007 7:50 pmAlso: I didn’t make any comment about whether the keychain was “worth protecting”. I said Tiger doesn’t protect it. And I don’t believe Leopard does either.
Rosyna
November 1st, 2007 1:58 amDid you try that thing with saved passwords in Safari (which uses the keychain)?
Thomas Ptacek
November 1st, 2007 12:34 pmI did as you said:
- Switched to Guest
- Launched Safari
- Turned on Password Saving
- Logged Into GMail
- Quit Safari
- Relaunched Safari
- Visited GMail, observed password
- Switched back to me
- Hex edited crap over the mach-o-le i386 text segment
- Saved
- Switched back to Guest
- Launched Safari
- Visited GMail
- Observed passwords still there.
I’m doing something wrong. I don’t come to this doubting that Apple can actually implement code signing; I’m just dubious of the value.
Thomas Ptacek
November 1st, 2007 12:46 pmAlso, happy to confirm: DYLD_INSERT_LIBRARIES still beats code signing; for instance, you can use it to trivially beat Parental Controls.
Parental Controls in Jaguar by the way — really interesting. Not just Finder-based.
Nectar
November 1st, 2007 1:20 pm@PaX Team: It would be interesting to compile and run the test for a 64-bit executable instead to see if there are any differences.
Ralf
November 1st, 2007 1:57 pmYippiiiee!! 10.5 src is out!
http://www.opensource.apple.com/darwinsource/10.5/
Mike
November 1st, 2007 2:35 pmThomas: Don’t be silly - nobody ever said that reducing vulnerabilities was bad. Well, nobody except the straw man that you made up.
I did say that it is impossible to engineer a system with zero probability of exploit. This is just trivially true - if you believe you can reduce the probability of exploitation to 0, you reject the fundamental laws of mathematics and the universe in which we live. But I’m sure we both agree that reducing vulnerabilities, and thus reducing the probability of an exploit, is a good idea.
I wish you would just give a straight answer on the keychain rather than continually dancing around and trying to have it both ways. At this point I don’t know if this is supposed to be a security forum or a legal forum. If you don’t think Leopard does anything at all to protect the keychain, why did you write, “protecting nothing but keychain was a bad security call on Apple’s part (or a necessary tradeoff with the same effect as a bad call)”? Were you wrong at 9:40 am, or are you wrong now? It’s got to be one or the other.
Thomas Ptacek
November 1st, 2007 5:47 pmMike, I have literally no idea what you are talking about. Code signing does not protect the keychain; it signs binaries, not the entire runnable text area of a process. An attacker can inject libraries into any running Cocoa program, without special privileges, without corrupting the signature.
What I’m saying when I say “protecting nothing but the Keychain was a bad idea…” is not that protecting the Keychain is a bad idea — it’s that it was a mistake not to make key validation pervasive throughout the runtime, and instead trying to enforce it programmatically only at a single point.
I’m not saying “it’s not enough just to make sure hijacked programs can’t touch Keychain”. I’m saying “Apple hasn’t even accomplished that limited security objective”.
I’m happy to be proven wrong, but confident at this point that it won’t be by you, and with that I leave you to the last word in this thread of the comments.
Thomas Ptacek
November 1st, 2007 7:06 pmWeird, Ralf. I can’t find the Seatbelt source (sbf_*.[ch]), but TrustedBSD is in the source tree. Seatbelt doesn’t look like TrustedBSD. What is TrustedBSD doing there?
Ralf
November 1st, 2007 8:32 pmSeatbelt is a policy that hooks into the TrustedBSD framework. SEDarwin was derived from TrustedBSD and got folded into Darwin 9 it seems.
Seatbelt is Apple proprietary apparently (otherwise it would be in the release). There are references to sandboxing/seatbelt in the kernel code if you grep closely enough. For example: There is a new mach port for seatbelt in osfmk/kern/ipc_tt.c.
Kirk: Arm shields. Fire up disassembler.
PaX Team
November 4th, 2007 8:12 amNectar: the paxtest sources are public, feel free to play with them (thing is, i don’t have access to a Mac myself, the tests were done by some other helpful folks). btw, you’ll need an OS X specific makefile, email me if you want the first cut.
Diegus
November 8th, 2007 9:14 am“I locked down the Guest account to nothing but Safari. I verified that I couldn’t start arbitrary apps.”
Well, if you check again you can actually run FrontRow even if it is unchecked in the list of allowed apps. You can launch FrontRow via Command-Esc or if using the simplified version of Finder, Right click Finder in the Dock, Go To… and type /Applications.
Gonna check if you can get it to open iTunes like previus version did in Tiger.
bobdole
November 16th, 2007 11:32 pmumm…Tom, did you ever try that cron -e thing you suggested? Because it doesn’t work (which I didn’t really think it would) since cron stuff is handled by launchd, not crontab proper…
theed
December 4th, 2007 2:04 pmwhether the cron thing works or not, it’s only there for historical compatibility. If you’re looking to make Leopard secure, ditch the legacy support. Turn off cron, it’s not used.
sudo launchctl unload -w /System/Library/LaunchDaemons/com.vix.cron.plist
constantly.at » Alien technology sighted in Leopard
February 9th, 2008 5:59 am[…] http://www.matasano.com/log/981/a-roundup-of-leopard-security-features/ […]
Mac OS X Security | NerdStarGamer
March 12th, 2008 7:30 pm[…] provides kernel level control over what individual applications have access to and can do. See: A Roundup Of Leopard Security Features In the case of an exploit that might use a browser to arbitrarily execute code, a sandbox- type […]
Muskoka Mac User Group » Blog Archive » Upgrading to Leopard? TURN ON THAT FIREWALL!
April 29th, 2008 12:47 pm[…] again this blog post and extensive comments looks to me to be pretty definitive. Bottom line, is still check that firewall, with the new caveat […]
Leave a reply