Attack of the itchy security-minded thread stealer! (Was: Re: setuid for priv sockets?)
Attack of the itchy security-minded thread stealer! (Was: Re: setuid for priv sockets?)
- Subject: Attack of the itchy security-minded thread stealer! (Was: Re: setuid for priv sockets?)
- From: Brian Mastenbrook <email@hidden>
- Date: Tue, 28 Oct 2008 08:04:16 -0500
On Oct 27, 2008, at 11:46 PM, Jordan K. Hubbard wrote:
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.
That would explain why I'm so hot and bothered :-)
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.
Sure.
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.
--
Brian Mastenbrook
email@hidden
http://brian.mastenbrook.net/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden