Did they add cookies on the stack ? Does the new version of gcc includes propolice ?
dragonfrog
· 2 years ago
I'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
· 2 years ago
Is MacOSX sandboxing affected by syscall wrappers flaw described by Robert Watson?
grey
· 2 years ago
I 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
· 2 years ago
As 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
· 2 years ago
dragonfrog, 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
· 2 years ago
Re. 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.
ASLR: 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
· 2 years ago
On 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
· 2 years ago
Thomas, is the stack and heap randomized or is it only certain dynamic libraries loaded by dyld?
Thomas Ptacek
· 2 years ago
John --- printf("%p\n", &address;_of_stack_variable);
Ralf: awesome data points. I don't see evidence of tinyscheme I/O compiled in, though --- do you?
Ralf
· 2 years ago
Thomas: 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
· 2 years ago
There's a "with-output-to-file" defun in there too. But tinyscheme is configurable.
Agree, the ASLR here looks pointless.
Sean
· 2 years ago
Am 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
· 2 years ago
Who said anything about APE?
Sean
· 2 years ago
"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
· 2 years ago
Yeah Unsanity does things besides APE. They're pretty smart.
Bbananna
· 2 years ago
"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
· 2 years ago
"Yeah Unsanity does things besides APE. They’re pretty smart."
No they're not smart.
Thomas Ptacek
· 2 years ago
Obviously, we disagree.
Jane
· 2 years ago
@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
· 2 years ago
@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
· 2 years ago
While 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
· 2 years ago
@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
· 2 years ago
One 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 0x100120: double free *** set a breakpoint in malloc_error_break to debug will this get executed? $
Pity.
Thomas Ptacek
· 2 years ago
Look 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
· 2 years ago
My guess is that if you set the system up so that everything runs with MallocErrorAbort, things will randomly crash.
Thomas Ptacek
· 2 years ago
mark: 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
· 2 years ago
"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
· 2 years ago
@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 :P
Thomas Ptacek
· 2 years ago
Don'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.
· 2 years ago
@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().
Does this not mean that Safari is signed? Am I misinterpreting the output?
Thomas Ptacek
· 2 years ago
Awesome. 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 0x90). 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
· 2 years ago
You'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
· 2 years ago
Also, once something's signature has been compromised, you may no longer use an "Always allow" option in a KeyChain dialog.
Thomas Ptacek
· 2 years ago
Thank 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.
acdha
· 2 years ago
I 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
· 2 years ago
By 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
· 2 years ago
The 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
· 2 years ago
I'm not bob btw :)
Thomas Ptacek
· 2 years ago
The 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
· 2 years ago
Wanted 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
· 2 years ago
Another 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
· 2 years ago
I 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
· 2 years ago
Thomas, thanks for your insight. There seem to be some concerns regarding the Leopard firewall, what's your opinion to these points?
Guest 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
· 2 years ago
To 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
· 2 years ago
You know, maybe it was just a typo. "Co-designing", not "Code signing"...
Thomas Ptacek
· 2 years ago
Paul:
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
· 2 years ago
Tom, totally rockin' post, as always.
Thomas Ptacek
· 2 years ago
Regarding 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
· 2 years ago
... but those data points, also excellent, and thanks for taking the time to write them.
Thomas Ptacek
· 2 years ago
darkalias: 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
· 2 years ago
@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 0x00000000 eflags 0x00000000 eip 0x000023c4 cs 0x00000000 $ # ok, we see the entry point is at 0x23c4, let's fire up gdb $ gdb ./ls (gdb) x/10i 0x23c4 0x23c4 : push $0x0 0x23c6 : mov %esp,%ebp 0x23c8 : and $0xfffffff0,%esp 0x23cb : sub $0x10,%esp 0x23ce : mov 0x4(%ebp),%ebx 0x23d1 : mov %ebx,0x0(%esp) 0x23d5 : lea 0x8(%ebp),%ecx 0x23d8 : mov %ecx,0x4(%esp) 0x23dc : add $0x1,%ebx 0x23df : shl $0x2,%ebx (gdb) q $ # great, the above code can be optimized $ port install hexedit $ # goes into hexedit and changes the first occurence of 83c301 $ # (add $0x1,%ebx) to 0x43 0x90 0x90 (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 0x23c4 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
· 2 years ago
So kern_exec is checking signatures?
Ralf
· 2 years ago
@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
· 2 years ago
@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
· 2 years ago
I 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
· 2 years ago
I 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
· 2 years ago
Nick: 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
· 2 years ago
@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
· 2 years ago
True, Google does do a much better job indexing mailing list posts.
Andy Fore
· 2 years ago
One possible solution for the guest account is to set the login shell to be /dev/null. This should prevent anyone from being able to login with the Guest account.
Ralf
· 2 years ago
@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
· 2 years ago
@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
· 2 years ago
Andy, 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
· 2 years ago
OK, 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
· 2 years ago
@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
· 2 years ago
I'm surprised. Apple actually has some decent info on code signing:
(no ADC account required). Unfortunately no info on sandboxing, stack protection the ALF and and library randomization...
Nick
· 2 years ago
Thomas: "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
· 2 years ago
Thomas: 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
· 2 years ago
according to paxtest (just the ones that i think test the system properly, ASLR tests need some patching for OS X):
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
· 2 years ago
Thomas: 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:
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
· 2 years ago
I concede, the "Guest" account in Leopard is not useless. Just dangerous. =)
Thomas Ptacek
· 2 years ago
The "mprotect" tests just test whether you can ret-to-mprotect to make the stack executable again?
jf
· 2 years ago
The 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
· 2 years ago
Mike, take a second and explain how exactly code signing stops people from using LD_PRELOAD from accessing keychains?
Thomas Ptacek
· 2 years ago
(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
· 2 years ago
So does this stuff get reported to Apple? Would you expect it to be fixed in 10.5.1?
Sigivald
· 2 years ago
To 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
· 2 years ago
I 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.
Mike
· 2 years ago
Thomas, 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
· 2 years ago
OK. 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?ma... for example, unforunately 10.5 has no man page for this function).
Michael
· 2 years ago
"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
· 2 years ago
Seems 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
· 2 years ago
@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
· 2 years ago
I 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
· 2 years ago
bobdole: you are suggesting I should --- what, close comments on this post?
Thomas Ptacek
· 2 years ago
Mike: 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
· 2 years ago
Also: 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
· 2 years ago
Did you try that thing with saved passwords in Safari (which uses the keychain)?
Thomas Ptacek
· 2 years ago
I 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
· 2 years ago
Also, 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
· 2 years ago
@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.
Thomas: 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
· 2 years ago
Mike, 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
· 2 years ago
Weird, 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
· 2 years ago
Seatbelt 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
· 2 years ago
Nectar: 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
· 2 years ago
"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
· 1 year ago
umm...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
· 1 year ago
whether 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.
All Comments
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?
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.
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.
Re. Firewall: What's your opinion of the devastating review by Heise Online (http://www.heise-security.co.uk/articles/98120)?
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.
[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.
[7:58pm:~] CREST:tqbf [0:53]% ./f
0x100120
[7:58pm:~] CREST:tqbf [0:54]% ./f
0x100120
[7:58pm:~] CREST:tqbf [0:55]% ./f
0x100120
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 ?
Agree, the ASLR here looks pointless.
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.
Ah. I'm sure. I was just reading how their sensible engineering hosed a whole slew of Leopard installs. Cool - and smart too!
No they're not smart.
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.
$ 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 0x100120: double free
*** set a breakpoint in malloc_error_break to debug
will this get executed?
$
Pity.
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
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.
“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 :P
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().
$ codesign -dvv /Applications/Safari.appand got:
Executable=/Applications/Safari.app/Contents/MacOS/SafariIdentifier=com.apple.Safari
Format=bundle with Mach-O universal (i386 ppc7400)
CodeDirectory v=20001 size=7621 flags=0x0(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?
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 0x90). 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.
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.
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.
" -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)
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).
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.
This is a _classic_ Unix attack.
http://www.eweek.com/article2/0,1895,2209676,00...
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.
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.
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).
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.
$ mkdir /tmp/cstest
$ cd /tmp/cstest
$ cp /bin/ls .
$ otool -l ./ls|grep eip
ss 0x00000000 eflags 0x00000000 eip 0x000023c4 cs 0x00000000
$ # ok, we see the entry point is at 0x23c4, let's fire up gdb
$ gdb ./ls
(gdb) x/10i 0x23c4
0x23c4 : push $0x0
0x23c6 : mov %esp,%ebp
0x23c8 : and $0xfffffff0,%esp
0x23cb : sub $0x10,%esp
0x23ce : mov 0x4(%ebp),%ebx
0x23d1 : mov %ebx,0x0(%esp)
0x23d5 : lea 0x8(%ebp),%ecx
0x23d8 : mov %ecx,0x4(%esp)
0x23dc : add $0x1,%ebx
0x23df : shl $0x2,%ebx
(gdb) q
$ # great, the above code can be optimized
$ port install hexedit
$ # goes into hexedit and changes the first occurence of 83c301
$ # (add $0x1,%ebx) to 0x43 0x90 0x90 (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 0x23c4 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.
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.
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.
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...
/dev/null. This should prevent anyone from being able to login with the Guest account.@bobdole: thanks for the BigTop hint?
@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.
Ralf: I'll move to a Google Group when Dave Aitel moves to one. =)
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.
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.
http://developer.apple.com/releasenotes/Securit...
(no ADC account required). Unfortunately no info on sandboxing, stack protection the ALF and and library randomization...
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.
Ralf: Join focus-apple at securityfocus. If nothing else, you can troll Dave Schroeder when you're bored.
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).
http://www.matasano.com/log/809/a-little-challe...
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.
"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.
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.
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.)
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.
And I'm no apple hater, I used to use them quite a bit.
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
Security is hard. Cryptographic security is harder. An RSA signing scheme where verification happens in an untrusted environment fails.
- 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.
Parental Controls in Jaguar by the way --- really interesting. Not just Finder-based.
http://www.opensource.apple.com/darwinsource/10.5/
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.
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.
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.
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.
sudo launchctl unload -w /System/Library/LaunchDaemons/com.vix.cron.plist