site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Oct 27, 2008, at 11:46 PM, Jordan K. Hubbard wrote: That would explain why I'm so hot and bothered :-) Sure. -- Brian Mastenbrook brian@mastenbrook.net http://brian.mastenbrook.net/ _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... Well, I also think you are taking a couple of threads of disagreement and weaving an entire sweater out of them here. It looks itchy. I think Apple's most recent efforts in sandboxing, code signing and verified downloads speak very much to the contrary, to say nothing of the security hardening work in many other areas. In what way is sandboxing meaningfully used in the operating system? If you're using Safari, any web page can view and upload any file your user has permissions to view. (rdar://6069307, which is over three months old, is P1, and is still parked in somebody's queue). I am also pretty sure that this would still apply to users of certain unreleased operating systems which have been made available to users outside Apple through developer programs. This class of vulnerability is to the best of my knowledge not possible in IE7 on Vista, because the browser really is sandboxed. I can't speak to how well OS X's sandboxing works if it is actually used. My general impression of sandboxing at the system call level is that it's a bit like playing Battleship (getpid! geteuid! vfork! execve! Darn, you sunk my vulnerability), but maybe it does work better than I expect. There is a lot more than "dumb luck" keeping malware off the platform, though, of course, it still remains the case that any substantially determined user can download and run any number of things, up to and including running them with admin privs. If, in other words, a user is determined to practice the computing equivalent of hanging out in Bangkok's red light district, they're going to catch something eventually and there's not a whole lot we can do about that without closing the system up so tightly that users who don't make a practice of grabbing random software from untrusted sources and running it will start grabbing the torches and the pitchforks in order to march down here to teach us a thing or two about practical security. Deliberately downloading untrusted software is not the only way that untrusted software can get its hands on my user account. If something manages to get in the front door (the browser), the battle is *not* lost, and it certainly can be fought a lot harder than it's being fought right now. Of course, you really don't want anything to get in the front door, because having access to all of my documents is bad enough. Getting root is even worse because it can turn a trojan into a virus. It's a balancing act involving the intersection of people and computers, Brian, not something that conveniently reduces to an engineering problem you can just throw money at until it goes away. And I really don't want anything that would annoy the users - quite the contrary, I want the users *not* to become inured to putting in their admin account username and password to every dialog box that asks for it. Twice this year I have submitted security bugs which I have stumbled across that have allowed easy execution of arbitrary shell scripts from Safari without user interaction. I wouldn't mind having the radar #s, so I can look at these as well. rdar://5652640 revisits an old problem in Terminal's URL handlers that allows easy arbitrary shell script execution from Safari rdar://5737359 revisits an old problem in Help's URL handlers, which allows execution of a number of AppleScript files that are shipped with the system rdar://5737366 covers a file type that executes a shell script when opened but was not marked as quarantined, which could be trivially combined with the previous vulnerability to run shell scripts from an arbitrary web page Once again, I'd like to stress that you do not need to be practicing "the computing equivalent of hanging out in Bangkok's red light district" to be affected by these issues. There are a million ways that a careful user can still run across a malicious web page, from SQL injection errors on ill-designed web sites to the possibility of an infected user on the (W)LAN acting as a rogue DHCP server and handing out IPs with a default route that goes right to their portal of doom. With these issues alone, a Leopard Safari user who installed 10.5.0 on October 27th, 2007 was vulnerable until March 19, 2008 to having malware installed on his or her computer without any user action other than visiting a malicious web page. Combined with the widely- publicized ARDAgent escalation of privileges vulnerability, this means that the operating system was vulnerable to a virus of the form I described in my previous email during that entire time as well. Don't take my word for it - grab a 10.5.0 installation disc and try it yourself if you'd like. I will never, ever assume that the black hats are not as smart or as well-informed as I am. If I can see this and imagine a world of malicious possibilities, I'm sure the evil people of the world can too. I also will not assume that if I could easily stumble across a few vulnerabilities that allow execution of arbitrary code from the browser that these are the last few such vulnerabilities, especially when they happen to be slight variants of things that were already exposed and fixed back in the Panther area. That's why I said that it's only dumb luck keeping malware off the platform at this point. For five months the system was wide open and nobody (to the best of my knowledge) exploited it. It's a bit like coming home and finding out you left the front door unlocked. It's great that nobody got in, but don't draw any conclusions from that. I'm not saying there are "no security bugs in the system" here by any means, but our past interaction also suggests that you tend to see a lot of "you need privilege X to do job Y" scenarios as architectural flaws, so much so that it almost seems like simply disconnecting your computer from the network (or AC power) would be the only way to reach the level of security nirvana you're seeking. There's a lot of ground in between where we are now and the unplugged- computer scenario. I would be quite a lot happier if the browser was reasonably secure and users weren't asked at least every few weeks to put their administrative credentials in a pop-up box that could be very easily hijacked by any infestation that was previously confined to their user account. If I see architectural problems, it's because I see many problems. Maybe these are all true singletons and there's no architectural solution to these problems. That wouldn't be my default assumption, but I could easily be wrong. I'm sure you don't actually feel that way, so clearly, we're somehow failing to communicate on some pretty fundamental level here and I'm not sure why. Many of the benefits that the launchd + AuthorizationServices approach seems to provide are applicable in a large, multi-user environment where restricting the access of whole user accounts to certain rights is the goal. My focus is squarely on the users who have taken home their new Mac from the Apple store, followed the setup assistant, and now have one user account with administrative privileges. In this scenario, I really still don't understand how what Apple is doing will decrease the likeliness of the type of drive-by malware that is prevalent on Windows becoming common on OS X as well. On the contrary, I see a predictable way for these programs to gain root by silently hijacking the very API that's supposed to control access to root privileges. Two times in as many months I've had to help close relatives whose Windows XP systems were infected by this kind of malware after they clicked on a popup. The scary thing is that for the first five months of Leopard's life, it wasn't even necessary to click. This email sent to site_archiver@lists.apple.com