Focus on Apple
Mac OS X Dashboard Widget Vulnerabilities? Dec 04 2007 07:21PM
Todd Woodward (todd_woodward symantec com) (1 replies)
Re: Mac OS X Dashboard Widget Vulnerabilities? Dec 05 2007 01:27PM
Don (drhodes mail colgate edu) (2 replies)
Re: Mac OS X Dashboard Widget Vulnerabilities? Dec 05 2007 08:48PM
Derek Chesterfield (dez mac com) (1 replies)
Re: Mac OS X Dashboard Widget Vulnerabilities? Dec 05 2007 11:27PM
Don (drhodes mail colgate edu) (1 replies)
Re: Mac OS X Dashboard Widget Vulnerabilities? Dec 06 2007 09:21PM
Mark Senior (senatorfrog gmail com) (1 replies)
Re: Mac OS X Dashboard Widget Vulnerabilities? Dec 09 2007 10:59PM
Tyrel McMahan (tyrel mcmahan gmail com)
Re: Mac OS X Dashboard Widget Vulnerabilities? Dec 05 2007 06:34PM
Mark Senior (senatorfrog gmail com)
This is not an issue of silently installing widgets (though that came up a
while ago). It's an issue of exploiting widgets that are already commonly
installed. The trick is that the widgets are supposed to run in a sandbox
where they can't get out. But, many widgets have the sandbox rules
"relaxed" such that they run with the same privilege as regular apps -
access to all commands, files, etc. that the user has. The second part
is, they download javascript over HTTP (not HTTPS), and pass it straight to
eval().

So, attack scenarios would involve an attacker intercepting an HTTP request,
and sending back his own javascript, which the widget would eval(), and
which would then let the attacker run whatever command he wants, as your
account.

Here's the first three that occur to me

- I sit down in a cafe with wireless access. An attacker inserts his own
DNS response, which would be easy since he's much closer to me than the
ISP's DNS server, so the race is stacked in his favour. Then he can become
the server hosting the javascript for my widget, and do anything I can on my
Mac.

- The attacker scales up the previous attack by poisoning my ISP's DNS
server (this is possible far too often). Now every time a computer under
that DNS server launches the vulnerable widget, it runs the attacker's
javascript.

- An attacker finds a cross-site scripting flaw on the legitimate site
that hosts the javascript for the widget, and inserts his
javascript directly on the server. Now every single user of that widget
will get the attacker's javascript.

Note that the first two cases would be prevented by using HTTPS and
verifying the server's cert. The last one would not; it can only be
prevented by tightening the sandbox and/or (preferably 'and') not running
javascript from the network through eval().

My take on the admin question differs from yours - all valuable information
on my Mac is accessible without administrator privs. The stuff you need
admin privs for is stuff I can reinstall from CDs or downloads. With my
user account comes my personal info, bank accounts. Don't forget that you
can insert an input manager for one user, without admin rights - and that
input manager would capture every password and credit card number I type, as
well as an admin password the next time I get around to installing some
software.

Regards
Mark
On Dec 5, 2007 6:27 AM, Don wrote:

> That does sound bad. It relies on people downloading and installing
> widgets
> from an unknown source, which would probably be the biggest area this
> would
> be exploited; which is much easier than installing a programs since it
> does
> not even ask for a password to install widgets.
>
> Now if someone could take over a widget after it has been installed, that
> would be another issue, i.e. the any of the 'default' widgets. That would
> greatly increase the seriousness of this threat.
>
> All roads lead back to operating your Mac with an non-administrator
> account.
> If the attack was via hijacking an already installed widget and you were
> running under a non-privileged account that should 'protect' the system
> somewhat. However if it was through a bad widget that is going to be
> installed only your fingers can truly stop that.
>
> Hopefully I am not too far off base on this.
>
> --
> Don
>
>
> On 12/4/07 1:21 PM, "Todd Woodward" <todd_woodward (at) symantec (dot) com [email concealed]> wrote:
>
> > Over on bugtraq, there's an interesting new thread regarding
> vulnerabilities
> > in Mac OSX widgets.
> >
> > http://www.securityfocus.com/archive/1/484542/30/0/threaded
> > http://www.securityfocus.com/archive/1/484567/30/0/threaded
> >
> > Essentially, widgets can "relax the Dashboard's JavaScript sandbox to
> enable
> > the widget.system() call, which indeed amounts to the equivalent of
> system(3);
> > i.e., if an attacker can take over the widget, the attacker can take
> over the
> > user's account
> > (and, quite often, the system)."
> >
> >
> > Security Response Researcher
> > Focus-Apple Moderator
> >
> > ________________________________________
> > Todd D. Woodward
> > Technical Support Engineer
> > NetBackup Support
> > Symantec Corporation
> > www.symantec.com
> > Springfield, Oregon
> > ________________________________________
> > Office:541-335-7441
> > ________________________________________
> >
> >
>
>
>
<div>This is not an issue of silently installing widgets (though that came up a while ago).  It's an issue of exploiting widgets that are already commonly installed.    The trick is that the widgets are supposed to run in a sandbox where they can't get out.  But, many widgets have the sandbox rules "relaxed" such that they run with the same privilege as regular apps - access to all commands, files, etc. that the user has.  The second part is, they download javascript over HTTP (not HTTPS), and pass it straight to eval().
</div>
<div> </div>
<div>So, attack scenarios would involve an attacker intercepting an HTTP request, and sending back his own javascript, which the widget would eval(), and which would then let the attacker run whatever command he wants, as your account.
</div>
<div> </div>
<div>Here's the first three that occur to me</div>
<div> </div>
<div>- I sit down in a cafe with wireless access.  An attacker inserts his own DNS response, which would be easy since he's much closer to me than the ISP's DNS server, so the race is stacked in his favour.  Then he can become the server hosting the javascript for my widget, and do anything I can on my Mac.
</div>
<div> </div>
<div>-  The attacker scales up the previous attack by poisoning my ISP's DNS server (this is possible far too often).  Now every time a computer under that DNS server launches the vulnerable widget, it runs the attacker's javascript.
</div>
<div> </div>
<div>- An attacker finds a cross-site scripting flaw on the legitimate site that hosts the javascript for the widget, and inserts his javascript directly on the server.  Now every single user of that widget will get the attacker's javascript.
</div>
<div> </div>
<div>Note that the first two cases would be prevented by using HTTPS and verifying the server's cert.  The last one would not; it can only be prevented by tightening the sandbox and/or (preferably 'and') not running javascript from the network through eval().
</div>
<div> </div>
<div>
<div>My take on the admin question differs from yours - all valuable information on my Mac is accessible without administrator privs.  The stuff you need admin privs for is stuff I can reinstall from CDs or downloads.  With my user account comes my personal info, bank accounts.  Don't forget that you can insert an input manager for one user, without admin rights - and that input manager would capture every password and credit card number I type, as well as an admin password the next time I get around to installing some software.
</div></div>
<div> </div>
<div>Regards</div>
<div>Mark<br></div>
<div class="gmail_quote">On Dec 5, 2007 6:27 AM, Don wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">That does sound bad. It relies on people downloading and installing widgets<br>from an unknown source, which would probably be the biggest area this would
<br>be exploited; which is much easier than installing a programs since it does<br>not even ask for a password to install widgets.<br><br>Now if someone could take over a widget after it has been installed, that<br>would be another issue,
i.e. the any of the 'default' widgets. That would<br>greatly increase the seriousness of this threat.<br><br>All roads lead back to operating your Mac with an non-administrator account.<br>If the attack was via hijacking an already installed widget and you were
<br>running under a non-privileged account that should 'protect' the system<br>somewhat. However if it was through a bad widget that is going to be<br>installed only your fingers can truly stop that.<br><br>Hopefully I am not too far off base on this.
<br><br>--<br><font color="#888888">Don<br></font>
<div>
<div></div>
<div class="Wj3C7c"><br><br>On 12/4/07 1:21 PM, "Todd Woodward" <<a href="mailto:todd_woodward (at) symantec (dot) com [email concealed]">todd_woodward (at) symantec (dot) com [email concealed]</a>&
gt; wrote:<br><br>> Over on bugtraq, there's an interesting new thread regarding vulnerabilities
<br>> in Mac OSX widgets.<br>><br>> <a href="http://www.securityfocus.com/archive/1/484542/30/0/threaded" target="_blank">http://www.securityfocus.com/archive/1/484542/30/0/threa
ded</a><br>> <a href="http://www.securityfocus.com/archive/1/484567/30/0/threaded" target="_blank">
http://www.securityfocus.com/archive/1/484567/30/0/threaded</a><br>><
br>> Essentially, widgets can "relax the Dashboard's JavaScript sandbox to enable<br>> the widget.system() call, which indeed amounts to the equivalent of system(3);
<br>> i.e., if an attacker can take over the widget, the attacker can take over the<br>> user's account<br>> (and, quite often, the system)."<br>><br>> <br>> Security Response Researcher<br>> Focus-Apple Moderator
<br>> <br>> ________________________________________<br>> Todd D. Woodward<br>> Technical Support Engineer<br>> NetBackup Support<br>> Symantec Corporation<br>> <a href="http://www.symantec.com/" target="_blank">
www.symantec.com</a><br>> Springfield, Oregon<br>> ________________________________________<br>> Office:541-335-7441<br>> ________________________________________<br>><br>><br><br><br></di
v></div></blockquote>
</div><br>

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus