A Little Challenge To Our Mac Advocate Friends
Thomas Ptacek | April 21st, 2007 | Filed Under: Apple, Uncategorized
Apparently this vulnerability is not that big of a deal because it doesn’t break root; it just gives attackers local user-level code execution.
Ok. So, commenters, fire away: name the assets you keep on your computer (email, personal documents, the contents of your Keychain) that I can’t get if I can run code under the same UID as you normally do.
[Update: 4/22]
Read the comments. Rosyna schooled me: Keychain is tighter than I gave it credit for, and X86 xnu made inter-process code injection harder. I hadn’t kept up with either of those things.
But, at the end of the day, it’s all still possible; you can’t ptrace-attach or Mach-inject if you’re an unprivileged user (anymore), but the dynamic linker and the Input Manager Cocoa feature still allows an unprivileged attacker to hop processes.
So, the challenge still stands. I broke your UID with a clientside code exec vulnerability. I got your Keychain secret by spoofing the dialog to you. I got your sudo password and your GPG key. Tell me what I can’t get from your UID that I could get from root —- on your box, right this minute.
Thomas Ptacek
April 21st, 2007 9:13 pmLet’s kick it off. Your GPG key. OH WAIT NO YOU LOST IT. Hm, let’s try again.
Rosyna
April 21st, 2007 9:36 pmHow would you get items in the keychain? The system that controls that (securityd) is run under a different UID.
petard
April 21st, 2007 10:23 pm@Rosyna:
If you’re running code at the same privilege level as the logged-in user, injecting code (using a technique similar to mach_inject or APE) into whatever browser is running would get you the vast majority of keychain items you’d care to have. Injecting into the running mail client would get you most of the rest.
As for assets you couldn’t get… you couldn’t get at my netinfo database. While you could get at my keychain, there’s nothing there that’s not public (i.e. certificates). You also wouldn’t get any interesting emails, since those tend to be encrypted and I don’t leave my token in when I’m not using it. (I don’t do software keys.)
So on what desktop platform wouldn’t code execution at the user’s privilege level be a big deal?
Thomas Ptacek
April 21st, 2007 10:32 pmReasonable people can argue about whether the Keychain can be kept secure, but if you want to argue it, I’ll kick it off by saying that if I control the process invoking Security Agent, I can hook any code path that invokes it and spoof the Agent prompt.
Thomas Ptacek
April 21st, 2007 10:38 pmI can get the data the way petard says, but obviously I’d rather just steal your authentication secret.
Matt
April 21st, 2007 10:44 pmC’mon Ptacek, quit baiting the Mac zealots and get back to the DNSSEC epic
As far as I’m concerned, this is a trick question. Replace “code” with “a keylogger,” and bam, there goes my root password.
Thomas Ptacek
April 21st, 2007 10:49 pmSingle-user machines are a bitch, as the Windows folks found out like 10 years ago. I’d still like to see what people come up with.
DNSSEC epic proceeding, although I have an, uh, algorithmic interlude in the pipe.
Matt
April 21st, 2007 11:08 pmIn the absence of the keylogger-to-root argument (”Assume false; argument proceeds naturally from there”): SSH host keys are root-owned and mode 600. Also, I believe that the postgres DB that I was using for authentication when I ran a Jabber server on my desktop was inaccessible to my UID.
Thomas Ptacek
April 21st, 2007 11:14 pmIf you are running things like Jabber servers on your machine, “you don’t count”. I’m definitely not arguing that user -> root -> user is an irrelevant transition.
BobTurbo
April 21st, 2007 11:31 pmWhat if you have multiple user accounts and one main one that sudo’s everything such as Safari under a user that has no access to any personal files.
Rosyna
April 21st, 2007 11:33 pmNo, it wouldn’t give you the vast majority of keychain items. It wouldn’t give you the iTunes password, for example, nor would it give you the .Mac password, or any application passwords you might use such as the transmit password.
Being inside safari would only you access to the Autofill information (if you have that enabled, I do not). It would not give you access to anything else.
And no, on the ICBMs you cannot inject from one application (like Safari) to another (like Mail.app).
” I’ll kick it off by saying that if I control the process invoking Security Agent”
How can you control that process? It runs as a different UID. Even the dialog that asks for your permission to access Keychain is run under a different UID from the Application asking for the item.
Every keychain item has a set of access controls. Which applications are allowed to access the item and which have been denied so you won’t even get a prompt. The access to the list is handled by a separate process, which runs under a different UID from the logged in user. The applications themselves never get direct access to the keychain.
And as for the keylogger thing, the window server itself does not forward events going into password fields to other applications.
Thomas Ptacek
April 21st, 2007 11:39 pmYou’re not following, Rosyna. If I want your iTunes password, iTunes runs under your UID. I can make iTunes do whatever I want and intercept any operation iTunes attempts to invoke, before the IPC operation ever happens.
Thomas Ptacek
April 21st, 2007 11:39 pmBobTurbo: do YOU actually do that, RIGHT NOW?
BobTurbo
April 21st, 2007 11:41 pmGod no.
Aaron Axvig
April 21st, 2007 11:45 pmEveryone is obviously missing the point. You were all supposed to say, “OMG, there is a lot of info in my personal documents and e-mail that I really don’t want other people to get. OK, well maybe _I_ encrypt all that, but my mom doesn’t, and neither does anyone else who doesn’t work in the computer industry. Thomas, you are brilliant, thanks for pointing out to us that this is actually an important security hole.”
Rosyna
April 21st, 2007 11:46 pmYou miss the point of my entire previous comment, how are you going to get into iTunes from an exploit running in Safari?
Rosyna
April 21st, 2007 11:49 pmLet me rephrase the question to be more specific.
The goal is to get your iTunes password in one step, without asking the user to approve/deny anything. All you have available at your disposal is an exploit in Safari. How do you get the iTunes password?
Matt
April 21st, 2007 11:50 pmBobTurbo, Thomas:
http://www.vmware.com/vmtn/appliances/directory/browserapp.html
Thomas Ptacek
April 21st, 2007 11:51 pmAaron: you’re not reading very carefully. You CAN’T encrypt it, unless you’re only DECRYPTING it OFFLINE or in a DIFFERENT ACCOUNT.
Single user machines are a bitch, yo.
Thomas Ptacek
April 21st, 2007 11:51 pmRosyna, good point. I wonder how you get Safari to bind a shell to a port; after all, Safari doesn’t bind ports to shells either. Oh, wait…
Thomas Ptacek
April 21st, 2007 11:52 pmMatt, if I can get Mac users to use VMWare appliances for browsing because they’re too worried about the security of OSX to trust it to attacker-controller content, well, that’s a victory condition.
Thomas Ptacek
April 21st, 2007 11:55 pmRosyna: in case my snarkiness masked my actual point, the first thing I’m going to do with remote code execution under your UID is inject a backdoor payload that will let me execute arbitrary system calls based on commands I send to your machine.
Rosyna
April 21st, 2007 11:58 pm“I wonder how you get Safari to bind a shell to a port; after all, Safari doesn’t bind ports to shells either. Oh, wait…”
uhm, what does this have to do with getting the iTunes password?
Thomas Ptacek
April 21st, 2007 11:59 pm(Also: if you’re the Rosyna I think you are, why isn’t this obvious? I feel like I might be missing something here. What system calls do you think make GDB work? Why don’t you think a Safari exploit payload gets to use them? Back Orifice hopped from process to process using code injection 9 years ago; Rentzch publishes Darwin code execution as helpful user utilities today)
Aaron Axvig
April 22nd, 2007 12:03 amAlright, I’m no security expert or even hardly an amateur, and my first post here was pretty sarcastic. Let me clarify a bit:
First, I’m going to assume based on the above article text that this exploit would allow an attacker to download personal files (any files that the user can normally read) from any user that visited their maliciously crafted website.
Can you imagine how bad that would sound to the average person (hell, it should sound bad to a security expert)? Visit the wrong website, or a good website that’s been hacked, and any information that’s not encrypted on your computer is theirs. My sister/dad/mom/any relative would flip out if they knew that could happen (and it probably can, especially since they all run Windows, but anyways…).
So what are we arguing about iTunes passwords and keychains for? Merely for academic purposes, as far as I can tell.
P.S. Thomas, I’m not really sure why you directed that comment at me. Was it misdirected?
Thomas Ptacek
April 22nd, 2007 12:04 amHuh? No, Aaron, of course that’s not what the exploit does. The exploit allows the attacker to execute arbitrary code on the victim’s machine.
Thomas Ptacek
April 22nd, 2007 12:06 amAlso, the reason I directed that comment at you was that you were implying that encryption was a solution for this problem. Of course it isn’t. When you decrypt your file, or provide any program in the system running under your creds with the accesses needed to decrypt your file, I’ll have your data.
Rosyna
April 22nd, 2007 12:16 amThomas, I’m confused as to why you ask. I’m giving the site my email address….
And yes, I do know how GDB works. GDB is setgid which is the only way for it to attach to other processes on the ICBMs. Apple made a change on the ICBMs back in Jan of 2006 (which means every ICBM ever shipped has this change) that prevents processes run as the current user from attaching to other processes.
Aaron Axvig
April 22nd, 2007 12:20 amHmm, so if there was code on the victim’s machine that was capable of uploading files to a specified address it could run that?
Thomas Ptacek
April 22nd, 2007 12:25 amOk I’m going to say, before trying to save face by finding a Mach API way to read/write process memory without using PT_ATTACH, that Rosyna just startled me; I can’t PT_ATTACH programs as a normal user on my MacBook.
I mean, I’ll just run something SGID procmod (which I didn’t know existed 2 minutes ago), like, uh, GDB, but still. Thanks for the heads up, Rosyna.
Thomas Ptacek
April 22nd, 2007 12:27 amAaron: you’re about 12 years behind the times (if you exclude the Morris worm). Vulnerabilities today let attackers upload assembly opcodes directly into other processes. You might start by Googling for “Smashing the Stack”.
Rosyna
April 22nd, 2007 12:32 am“I mean, I’ll just run something SGID procmod”
How is your exploit going to become setgid procmod? That’d be a nifty trick
Rosyna
April 22nd, 2007 12:33 amFWIW, the only reason I’m hammering the keychain issue is because the keychain did something to me a few months ago that really pissed me the hell off. And I had to spent quite a bit of time figuring out how to resolve the problem without losing any data. And I’m still pissed as hell at the keychain for doing that.
Thomas Ptacek
April 22nd, 2007 12:36 amRosyna: With an input manager?
Incidentally, if you think about it, any input manager is already fundamentally equivalent to “procmod” anyways.
Rosyna
April 22nd, 2007 12:37 amThomas, iTunes isn’t cocoa, InputManagers won’t be loaded.
Drew Thaler
April 22nd, 2007 12:39 amAh, good, it was about time to give up on the direct approach and start writing to the filesystem. Good thinking.
Too bad Cocoa input managers don’t load into Carbon apps like iTunes.
Thomas Ptacek
April 22nd, 2007 12:42 amAhh! You got me with your legal mumbo jumbo.
Thomas Ptacek
April 22nd, 2007 12:45 amDYLD. DY.
http://www.digitalmunition.com/InqTanaThroughTheEyes.txt
Thomas Ptacek
April 22nd, 2007 12:49 am(For what it’s worth, the 2 minutes of testing I gave this doesn’t bear out that it works; I can’t tell if iTunes is honoring DYLD_*, but it doesn’t seem to be).
Thomas Ptacek
April 22nd, 2007 12:51 amOk on second glance: iTunes totally does honor DYLD_*, at least if I set it on the command line.
Thomas Ptacek
April 22nd, 2007 12:53 amDrew: unless iTunes doesn’t honor environment.plist settings, you can just LD_PRELOAD a library into it and that’s game over.
Drew Thaler
April 22nd, 2007 1:26 amGood job. That would work, and may be the only way to get code into iTunes without user interaction.
Still, if anyone was running basic virus-detection software, both the environment variable and any library/InputManager installation would raise giant red flags. (I’m not implying that most Mac users do this, because they don’t. It’s just an observation.)
Thomas Ptacek
April 22nd, 2007 1:30 amWe make fun of people who run OSX antivirus. =)
Matt
April 22nd, 2007 1:43 amUCLA makes me run Sophos on my Mac. (They also offer Sophos downloads for Linux, FreeBSD, AIX, UnixWare, Solaris (Intel and Sparc), OpenVMS, and OS/2; I don’t think their NAC actually enforces AV on most of those, though.) I should check to see if it actually catches suspicious behavior like that, but I sort of doubt it.
Drew Thaler
April 22nd, 2007 1:48 amWell, sure.
By the way, I just want to clarify — I definitely think remote user-level code execution is a huge deal. No argument there. Rosyna and I were just chatting and felt it was worth pointing out that code injection from an unprivileged app is actually significantly harder than it used to be.
It’s also getting harder: Leopard closes down at least one of the methods mentioned here.
Ryan Russell
April 22nd, 2007 2:25 amWell, if you’re a single user Mac, your user is probably in the Admin group. So, /Applications will be writable, meaning I can modify or replace iTunes…
Matt
April 22nd, 2007 2:26 amI’d suggest that if you popped up the screensaver and then a (faked) “You must authenticate to unlock the screen” window, most people would comply. Give the password to extractkeychain and you’ve got the secrets.
Sure it’s not automated, but should work.
Roland Dobbins
April 22nd, 2007 3:17 amSince 99.99999% of Mac users run as admin, and since Apple have dorked up the perms for the /Applications hierarchy such that the admin user can write to /Applications and everything below it, a browser exploit for OSX can be used to trojan anything under /Applications, so that the user can be induced to run arbitrary code of the attacker’s choice. FileVault doesn’t matter, as the code will be running in the context of the user; the contents of his home directory can be rifled, copied off somewhere, etc.
Rosyna
April 22nd, 2007 3:49 amThomas, third time’s the charm
Although I find it odd that apple left that in when they redefined the requirements for task_for_pid(). Kind of makes the latter less useful.
Ryan, Matt, Roland, if you’re all talking in the context of the iTunes keychain item(s), you could not access them this way even if you did manage to have write access directly to the iTunes binary.
The keychain won’t allow access to an item in the keychain if the application is modified without user interaction. Instead, you’ll see a dialog like this (the dialog differs based on how much the application has changed, this dialog is for an application that changed by one byte) http://www.unsanity.org/rosyna/imgs/sexy_keychain.png
And the point in my original summarized question was to get the iTunes password without user interaction using a Safari exploit. Modifying the iTunes binary won’t do it.
Robert Moir
April 22nd, 2007 6:03 amI’ve said it before and I’ll say it again. You don’t need root to break someone’s heart. People are fixated on getting root access to a machine, because they think in terms of 0wning the machine.
Obviously the is is still a goal for some people, obviously it’s the holy grail of hacking for the sake of hacking.
But… There appears to be a rather large phishing industry that has sprung up and is doing rather well for itself thank-you by *not* being interested in your computer but rather in the user. Can I re-write your bank bookmarks to send you to ‘www.happy-phishing.com/1stBankofPhish’ instead of your normal bank site?
How many people store passwords for things like their bank account in a text file tucked away somewhere in their home folders? The answer is… a lot.
How many people are properly ‘equipped’ to evaluate the risks of answering an unexpected popup on their desktop? Not so many.
How many Mac users blindly authenticate when asked to do so by an app installer without thinking of the consequences? And how many of these would even ‘notice’ if Safari popped up with something like this at an unexpected time?
Who would even notice if something like this dropped its own input manager into ‘~/library/inputmanagers’? Who would even know what that meant? Most of the Mac knowledgeable people who read blogs like this should know or would be able to google it up easily, but what about the average person in the street who just got drawn in by the “I’m a Mac” adverts?
Rosyna, how many users would recognise that dialog box as inappropriate? After all, they see it every time iTunes updates. Yes, that would be user interaction, I know. But the user wouldn’t be faced with “Do you want to send your keychain to a total stranger, Y/N?”, they’d be faced with a normal dialog box they see every couple of months anyway. Hiding behind things like that wasn’t acceptable when Microsoft tried it to defend some of the mistakes they made and I’m rather sad to see it now.
Rosyna
April 22nd, 2007 6:49 amRobert, the point of my exercise was to use an exploit without any kind of social engineering.
If you include Social engineering and human judgment into the equation, then you couldn’t even stop something that says,
“Download this widget. Click OK on the dialog that says this software is malicious. Windows is currently mislabeling the software. We are working with microsoft to address the issue. We promise it is not malicious, click the Install button if you see this dialog. “
ALong with a screenshot with a huge red circle around the install button.
I can assure you, people will still install the software. There’s only so much you can do to protect computer users from themselves. And this is why it’s a moot point to try to discuss potential social engineering exploits. No matter what is said in these arguments, both sides are right.
Brian R
April 22nd, 2007 8:07 amYep, it’s key to differentiate social engineering induced exploits from those that don’t require same. Just like the issue of incursion by someone with physical access to the computer. With the latter, you’re SOL anyway.
Regarding Keychain commandeering, I’m wondering how effective a filter I use, 1Passwd, would be in making this more difficult.
Robert Moir
April 22nd, 2007 8:17 am“Robert, the point of my exercise was to use an exploit without any kind of social engineering.”
Fair enough.
In which case I’ll go with malicious input manager copied to ~/libraries/inputmanagers. Quite possible from what Thomas says, and while I wouldn’t own your machine I’d own your data. The data might be worth more.
Jon Bowie
April 22nd, 2007 8:46 amIs there any platform on the planet that has a secure enough kernel code base to negate the fact that the ability to execute arbitrary code as a non-privilleged account is essentially already Game Over for local root (Hi Argus!!)? Let alone Mac OS X?
I call shennanigans on Tom for posing a trick question. You all fell for the bait too
Robert C.
April 22nd, 2007 10:52 amI think I have some assets you can’t get. I don’t run as admin normally, so that might keep you away from Applications (?). I keep important / sensitive financial & other documents in an encrypted disk image.
Questions: Would those things be safe? Does it help me that I don’t run as admin?
Thomas Ptacek
April 22nd, 2007 11:36 amIt’s not a trick question. The point is, non-admin user code execution is game-over, even if you don’t have root.
Thomas Ptacek
April 22nd, 2007 11:37 amRobert: how do you decryt the disk image? The disk image helper program runs with your user creds.
Robert Moir
April 22nd, 2007 11:56 amRobertC:
Not running as admin certainly helps reduce(but doesn’t prevent)the chances of people taking over your machine, but the question remains, what data can be mined?
As Thomas says, how do you decrypt that image. Couldn’t someone just install an input manager to watch you do it?
tiresome
April 22nd, 2007 2:09 pm*Sigh* Rosyna. *sigh* You’re arguing that people don’t care if you slurp their entire home folder (and everything else they have read permission to on the computer) up to a web/ftp site. That is not an argument you can win. The password B*llsh*t is meaningless. People in general are not happy when they lose every bit of data they have due to a system crash, but they would be even LESS happy if everything on their computer was posted to usenet. To demonstrate this point, allow me to give you the simple test I use on beurocrats who like to use my SSN on documents where it’s public. Post YOUR (SSN) home folder on the internet for everyone to see, and then tell me you don’t care.
I saw a great talk by Marc Stiegler of HP research back in Feb where he showed their capabilities-based system which stops applications from fscking your over except, of course, in the presence of social engineering attacks. But even social engineering attacks are limited because the applications ask for their capabilities the first time they load or you can just set them based on profiles (like “web-browser”, which is something which needs to read your bookmarks and cache files, but DOESN’T need to read or write files anywhere else on the system…). There were lots of caveats to the talk (like the fact that everything has to be written in an OO langauge like java, and excluding things like C++ which have those evil pointers), but the message is clear, and has been repeated in other contexts over the years: even user-level applications need to be heavily sandboxed and partitioned, and given “least privilege” (fo’ real…not just given lip service) because otherwise, as the example he used repeatedly, we are left with a world where solitaire can send your turbotax pdf printout to my good friends over at 1.1dy.us and citi-bank.ru (don’t go there ;)).
For those of you who may have missed it, 10.5 is supposed to have Mandatory Access Control based on the TrustedBSD code base. I am cautiously optimistic that the sandboxing therein when combined with ability that darwin already has to spawn mini-vms for applications, will help stop my applications from being able to access everything everywhere in my user account.
Thomas Ptacek
April 22nd, 2007 3:43 pmMAC is great and all, but let’s not lose sight of the real issue. You can, with a bit of userland C code, tighten up Mac permissions so that it is really hard to transition from “owning Safari” (and thus the auth cookie for your bank account) to “owning iTunes”. It’s not that MacOS X lacks the features to pull this off.
The problem is, “single user machine” is a really hostile setting for deploying those features.
DG
April 23rd, 2007 9:32 amThomas,
I can see how it’s game over for me if you can run code as my UID, but (forgive my ignorance) do you have any more details as to how/why the “single user machine” is more hostile for the tightening up you just mentioned?
I was under the impression that the saving grace was “on a multi user machine, you’d have only ‘lost’ one user not everybody”, but your last comment makes me think I’m still not getting the whole picture…
Also, if I did split off, say, all “my financial stuff” into a completely separate account, would it actually be any safer despite the inconveniences? Sure it’s toast if you get root, but would my other account topple anyway? Say, if I normally fast user switch from the now compromised user account?
Daniel
April 23rd, 2007 10:12 am1: Thinking yer the shnizzle for all things anti-mac $100
2: Posting a little challenge to prove the point $25
3: Telling people “You’re not following…” whilst huffing and pufffing and strutting your stuff $10
4: Getting smacked in the face and told to STFU and listen for once $priceless
Daniel
April 23rd, 2007 10:33 amps..
Thomas we love you anyway, but it’s good to be humbled every now and then, it makes us better people ;0)
Thomas Ptacek
April 23rd, 2007 10:36 amNot sure you read the whole comment thread, but, uh, the challenge still stands? I can inject code into iTunes (or any Cocoa app) from a Safari exploit.
So, not close to “STFU” yet.
What can’t I get to on YOUR MacBook from UID 501?
dre
April 23rd, 2007 12:19 pmi thought filevault (and therefore keychain) had serious implementation problems as talked about at 23C3?
dragonfrog
April 23rd, 2007 12:27 pmWell, if you assume that I’m the only user of my computer, then the answer is indeed, there is nothing important you don’t have with my UID.
But in fact, they’re not single-user machines. With my UID, on my computer, you win (given that you can get my password sooner or later and then have UID 0).
But with my UID on my wife’s computer, you have not so much of interest. Some audio projects, but nothing of major value. With my UID on my mom’s computer, you have practically nothing - I check webmail when I go back home, and that’s about it.
Bert JW Regeer
April 23rd, 2007 12:44 pmwideload:~ xistence$ id
uid=1001(xistence) gid=1001(xistence) groups=1001(xistence)
(NFS on my FreeBSD has that uid for that account, so had to be the same on my Mac to be able to read/write, took me a while to figure out how to change it)
If you got my UID 501 account, i’d be up shit creek without a paddle since it has admin privs.
wideload:~ xistence$ id 501
uid=501(administrator) gid=501(administrator) groups=501(administrator), 81(appserveradm), 79(appserverusr), 80(admin)
I almost never use that account. The only time I use it is when I get a stubborn installer that does some shell script ninjutzu, and needs to do it as root. I look at you KisMac.
Now as for my current user account, you’d get a whole lot of data about me. Keychain however is under a different password, and I am very suspicious when an app needs access to it. I keep my mail password in it for example, and if it is locked, it will ask me for access.
InputManager? The folder is set to chmod 000. No read or write access, also, just in case something is put in there, AppleScript will pop up letting me know something was dumped there (can only be done as root on a chmod 000).
Thing that would suck the most, is if my SSH keys were stolen. Access to too many machines, and no real fast way to remove them from each of the machines it has access to.
What I would worry about the most is just general information about me, stuff that could probably be found on the Internet, but would take a lot of time. I don’t think that what I do have is interesting. A few PDF’s, a shitload of TV Shows, Movies, projects for school, and just some open source projects I am working on.
Rosyna: Only way I have found that a keylogger would work under Mac OS X is if it was a kernel module. But that is a general problem with all operating systems, not just Mac OS X.
Thomas: The assumption that everyone that is reading your blog would run under UID 501 is a really bad one. The only reason someone would be reading your blog is if they were interested in security, and those people would be smarter than your average grandma or grandpa. That being said, my dad is a Mac OS X user and I set him up with split accounts, just so that he would do everything under his own UID and only when installing apps use Administrator.
Cheerio!
Daniel
April 23rd, 2007 3:02 pmThomas you can have what you want, in fact if you fancy doing some retouching on the images i currently need to send to client, hell, have those as well
Again this is one area where security researchers sometimes forget about applying risk. Yes you can root a box, but at what risk factor?
seriously you lot take this too seriously, maybe it’s because i’ve been doing it since 94, but damn… IT ONLY A FUCKING OS!!!
Thomas Ptacek
April 23rd, 2007 4:05 pm“At what risk factor”? I’m the attacker. Am I going to trip and fall over my exploit script?
I guess if you just declare the whole discussion moot, it’s easy to “win”. You win! I mean no offense when I continue to respond to the rest of the comments in the thread as if you hadn’t won. For, indeed, you have won.
Ryan Russell
April 23rd, 2007 4:32 pmRosyna: thanks for the info about the keychain and binary modifications, I learned something. When did they do that? OS X used to do a rebasing step that would change your binaries, and I always thought that was really stupid.
JohnGruberIsARobot
April 23rd, 2007 4:34 pmdre: Hrm? The only thing they showed at 23c3 is that filevault is cryptographically secure, but it can be brute forced quicker than extremely slow (read: somewhat slowly) in hardware. And everyone already knew that anyway.
Robert C.
April 23rd, 2007 11:08 pm@Thomas: Your last comment is hilarious.
What sorts of things should Mac users be doing? Does Bert have the right idea with that InputManager thing he’s talking about?
Or is the point simply that this kind of vulnerability is really going to hurt no matter what we do? Because I believe you. It will hurt. I’d just like to find out if there’s anything I should do to mitigate my risk.
Thomas Ptacek
April 23rd, 2007 11:33 pmI know I sound like I know what I’m talking about, and that serves me well when I’m poking holes in things, but I’m going to leave it to Dave G. to give actual recommendations on how to deal with this stuff.
Like I said, I live dangerously, and I live by what Dave wrote about safety vs. security;
http://www.matasano.com/log/644/safety-vs-security-2/
Max
April 24th, 2007 4:10 amThomas, Rosyna, et al. Thanks for the discussion here. I learned something.
BTW Thomas,
$ id 501
id: 501: no such user
Dave G.
April 24th, 2007 12:22 pm@Robert C:
Overall, I think Bert gives some solid advice. I am not sure I know everything that Bert is doing to protect the InputManagers directory, but it will probably provide some protection, specifically around automated attacks.
The most solid recommendation is to make sure that your user account is not an administative user. I definitely recommend not running with a user in the admin group. While it won’t help you with your data, it will prevent someone from immediately running amok with your /Applications diretory.
Jesse
April 24th, 2007 5:30 pmJohnGruberIsARobot: At 23c3 there was a talk about the security of file vault and that the key derivation didn’t suck in an obvious way. However there were some very serious flaws mentioned but not focused on in that talk including: The low power behavior of OS X includes writing the encryption key to the disk without protection.
This means that the main goal for disk encryption, “protecting your data when your machine is stolen” is not achieved. I would consider this a fatal flaw - although not apropos to the rest of the discussion here.
Jordan Wiens
April 27th, 2007 2:34 pmSorry to post on an old thread, but anybody know how this might work?
http://www.subrosasoft.com/OSXSoftware/index.php?main_page=product_info&cPath=200&products_id=195
They seem to think they’ve got a way to get access to all the keychain passwords and it doesn’t look like they’re hijacking the individual applications. They also claim it’s forensically sound, though that seems… well, patently false since the very fact of mounting the usb drive modifies the system, but I’ll save that for the forensic experts to argue.
Leave a reply