Mac OSX 10.4 Dashboard Authentication Hijacking Vulnerability

[Jonathan Zdziarski]

I looked around and didn't see any invitation from Apple to report
vulnerabilities, so for now I guess I'll post here and leave it to
someone with a paid developer's account to tell them.

Jonathan

Date: May 19, 2005
Description: OSX 10.4 Dashboard Permits Hijacking of Authenticated
Credentials

Versions Affected:
OSX 10.4.0
OSX 10.4.1

About Dashboard:
Mac OSX 10.4 includes a feature called Dashboard, which provides an
environment for mini-applications, called Widgets, to run. Widgets
are commonly freely available for download from a number of trusted
and untrusted sources. Users running Apple's native browser, Safari,
may have downloaded and installed widgets to their dashboard without
even knowing it due to a related security flaw in the Safari browser.

About the Vulnerability:
Dashboard widgets allow system commands to be executed, which is
normally not considered a vulnerability in itself as they run with
the user's permissions. If the user has recently authenticated to
perform a super-user function, however, Dashboard widgets can hijack
these credentials by calling the system's built-in "sudo" command and
execute arbitrary functions with full administrative privileges.
Because the sudo command trusts users based on username and tty, the
widget is never prompted for a sudo password, but immediately
authenticated based on the user's previous manual authentication for
whatever other task they were performing. Because Dashboard widgets
can be modified to run in the background, they can also sit and wait
for a user to authenticate, executing malicious commands when this
occurs.

Combining this vulnerability with Safari's auto-install
vulnerability, it may be possible for a widget to maliciously install
itself by visiting a website, wait for the user to authenticate to
perform a task, and take full control of a system.

Workarounds:
There is presently no workaround available other than to carefully
examine new widgets and their source code prior to installation, or
to avoid using the Dashboard entirely. Examining code isn't a
guarantee, however, as some widgets may contain code in binary form.
To prevent the auto-installation of widgets (and the potential
malicious applications of this function), disable the "Open Safe
Files" checkbox in Safari's General preferences.



_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Alain Fauconnet]

Post by Jonathan Zdziarski
I looked around and didn't see any invitation from Apple to report
vulnerabilities, so for now I guess I'll post here and leave it to
someone with a paid developer's account to tell them.

Seems to me that you can report bugs from
http://developer.apple.com/bugreporter/index.html
Membership is required, but the free "online" membership is
sufficient.

Greets,
_Alain_

(rest deleted)
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Daniel]

Post by Alain Fauconnet

Post by Jonathan Zdziarski
Dashboard widgets can hijack
these credentials by calling the system's built-in "sudo" command and
execute arbitrary functions with full administrative privileges.
Because the sudo command trusts users based on username and tty, the
widget is never prompted for a sudo password, but immediately
authenticated based on the user's previous manual authentication for
whatever other task they were performing. Because Dashboard widgets
can be modified to run in the background, they can also sit and wait
for a user to authenticate, executing malicious commands when this
occurs.

Ok im running 10.4.1, i have a piece of javascript which calls sudo,
yet im asked for my password straight after the sudo call has been
made, therefore it WILL not run automatically.In order for you to have
this fully exploitable widget, you would need the user to 1st call
sudo to perform and action and then have the widget piggyback onto
that session, surely?

Post by Alain Fauconnet

Post by Jonathan Zdziarski
Combining this vulnerability with Safari's auto-install
vulnerability, it may be possible for a widget to maliciously install
itself by visiting a website, wait for the user to authenticate to
perform a task, and take full control of a system.

with 10.4.1, once any widget has been downloaded, the user is
presented with a box warning of the danger. If they do not do
anything, the download DOES not take place and there is no code stored
on the system.

I'm all for people finding holes in operating systems and reporting
them, but with a matter like this it seems that there is more
theoretical exploitation than actual exploitation.

Tell you what, write up a bad widget and send it to us and lets see if
we can replicate it..

ps.. http://www.apple.com/support/security/

that e-mail address works, ive sent in a few issues myself regarding
10.3 and had no problems so far

Post by Alain Fauconnet
Seems to me that you can report bugs from
http://developer.apple.com/bugreporter/index.html
Membership is required, but the free "online" membership is
sufficient.
Unfortunately, no. After logging in, I get this error when I try and file a
You do not have access to this Application, Please get access and try again
It appears that you have to pay to report bugs to Apple.
Jonathan
_______________________________________________
Full-Disclosure - We believe in it.
http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Daniel]

But then isnt this an issue with Sudo's grace period (ie should it be
tied down to that terminal process calling it and not other ones?)

I understand the theoretical issue you present, but lets be honest,
its not a vulnerability because to exploit this would require a
serious amount of user interaction beforehand

The same can be said for Linux/Solaris, in fact any OS which uses
sudo. Hell i think Gnomes GDesklets also could be exploited this was
as well, and in the case of them you dont even need to be reminded
that the content is bad as firefox just downloads them onto the
machine anyway

Post by Daniel
Ok im running 10.4.1, i have a piece of javascript which calls sudo,
yet im asked for my password straight after the sudo call has been
made, therefore it WILL not run automatically.In order for you to have
this fully exploitable widget, you would need the user to 1st call
sudo to perform and action and then have the widget piggyback onto
that session, surely?
Right. If you call sudo for anything else on your system, the widget can
hijack this because Apple's implementation of sudo comes default with a
grace period.
with 10.4.1, once any widget has been downloaded, the user is
presented with a box warning of the danger. If they do not do
anything, the download DOES not take place and there is no code stored
on the system.
Actually they're not prompted to execute it. They're prompted to download
it. The user has the option to either download and install, or not download
at all. But even without auto-install, this is still an issue, as people are
likely to run several widgets without any knowledge of a trojan. Like I said
in an earlier reply, you have 5-10 widgets all running in the background,
invisible to a user, and the nature of widgets themselves make them ideal
targets for malware. They're small applications that don't fall under the
same scrutiny as other applications.
I'm all for people finding holes in operating systems and reporting
them, but with a matter like this it seems that there is more
theoretical exploitation than actual exploitation.
Tell you what, write up a bad widget and send it to us and lets see if
we can replicate it..
ps.. http://www.apple.com/support/security/
Just add this line to any existing widget's "show" code, or background code
widget.system("sudo id >> /tmp/out", null);
Then at some point in the future, authenticate for something. The next time
the widget code runs (which could be in the background depending on the
widget, or next time you view the dashboard), you'll see root in that file.
This is not a hard concept to grasp.
that e-mail address works, ive sent in a few issues myself regarding
10.3 and had no problems so far
Thanks for the link.
Jonathan

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Graham Reed]

Post by Daniel
But then isnt this an issue with Sudo's grace period (ie should it be
tied down to that terminal process calling it and not other ones?)

I suspect that since the dash runs as the user, it's sharing the same tty
somehow. It seems to work regardless of where I authenticate.

The entire GUI looks like one TTY ('console', if 'who' is to be believed).
So everything but terminal programs is running under the same TTY.

Also, by default, sudo does not bind authentication credentials to the TTY.
You need to build it with "--with-tty-tickets" or add "Defaults tty_tickets"
is added to the sudoers file.

Consequently, any use of 'sudo' via the GUI will establish a viable ticket
for all processes in the GUI, even with TTY tickets.

2. The default grace period configuration in OSX is somewhat insecure

Well, definately. And I, personally, disapprove of "sudo" without TTY
tickets. Especially if you might be logged in to the same node from several
different directions.

So, I would argue in favor of changing the default timeout to zero (as
someone else already suggested) and enabling TTY tickets:

sudo visudo
/^# Defaults
oDefaults tty_tickets
Defaults timestamp_timeout=0
ESC:x

Then if you have users for whom a timed ticket is appropriate, re-enable it
per-user (but keep the tty_tickets setting):

Defaults:gooduser timestamp_timeout=5

So gooduser will get 5 minutes to keep running sudo without password prompts
(and maybe 1 is a better number). But authenticating in a terminal window
will not give GUI processes any credentials. So gooduser now only has to
worry about authenticating via the GUI.

What sudo is lacking for that case is a way of specifying defaults per TTY.

Also, it is lacking a way of saying, "Authenticate and do not set a
timestamp".

Hmmm. This is turning out to be less of a OS X thing than OS X simply
making it easy to social engineer use of features in sudo.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Brian K.]

Post by Alain Fauconnet

Post by Jonathan Zdziarski
I looked around and didn't see any invitation from Apple to report
vulnerabilities, so for now I guess I'll post here and leave it to
someone with a paid developer's account to tell them.

Seems to me that you can report bugs from
http://developer.apple.com/bugreporter/index.html
Membership is required, but the free "online" membership is
sufficient.

Also, if you don't want to register, you may submit security issues
via e-mail to <product-***@apple.com>. (cf. <http://
www.apple.com/support/security/>)

It should be noted that the Mac OS X 10.4.1 Update should have
already fixed the Safari auto-install issue, as it now supposedly
prompts "<file> is an application. Are you sure you want to download
the application <file>?", if the "Open Safe Files" checkbox is
checked. (cf. <http://stephan.com/widgets/zaptastic/> )

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[ZATAZ.net]

Hello,

http://stephan.com/widgets/zaptastic/

Regards.

Post by Jonathan Zdziarski
Date: May 19, 2005
Description: OSX 10.4 Dashboard Permits Hijacking of Authenticated
Credentials

http://www.osvdb.org/16499

Post by Jonathan Zdziarski
OSX 10.4.0
OSX 10.4.1

10.4.1 doesn't seem to be vulnerable. Could you please show how do
you exploit this when the option in Safari is turned on?
www.osvdb.org -- everything is vulnerable.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Cordialement

-----------------------------------------------------

Eric Romang / ZATAZ Production
Co-fondateur de ZATAZ
***@zataz.net
www.zataz.com / www.zataz.net
GSM : [phone]
B.P. 311
59474 Seclin Cedex
France



_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Daniel]

"Combining this vulnerability with Safari's auto-install
vulnerability, it may be possible for a widget to maliciously install
itself by visiting a website, wait for the user to authenticate to
perform a task, and take full control of a system."

Have you tested this on 10.4.1 or is this a theoretical issue?
Safari now pops up the window saying "this is an app, blah blah blah",
so user interaction is required for the widget to be downloaded (hence
negating the whole widget installing itself"

Post by Brian K.
http://stephan.com/widgets/zaptastic/
well, I know this already and maybe I wasn't clear in my last mail: How do
you exploit this under 10.4.1 when the option in Safari is turned on,
because Jonathan Zdziarski described 10.4.1 as vulnerable?
www.osvdb.org -- everything is vulnerable.
_______________________________________________
Full-Disclosure - We believe in it.
http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Frederic Charpentier]

hi list,
I could not found an answer to my problem, so I ask the list :

I use snort to detect attackers playing with my web application.
I try to detect some specific text in html response, like "Bad User" ou
" Warning Mysql Error". But snort stay blind.

Sample :
1 - Attacker -> web-server : http://server/script.asp?param=' or 1=1--
2 - web-server -> attacker : 200 OK, ......<html>......datatype error....

I try to catch the string "datatype error" with a snort rule like that :

alert tcp $HTTP_SERVERS $HTTP_PORTS -> any any (msg:"web-server attack";
flow:from_server,established; content:"datatype error";
classtype:web-application-attack; sid:80005; rev:1;)

But Snort never detects that.

I try with binary mode, same.
When I sniff with ethereal, the packet I try to catch is like that :

attcker -> web-webser : HTTP : GET http://server/script.asp?param='
web-server -> attacker : HTTP : HTTP/1.1 304 Not Modified
web-server -> attacker : HTTP : Continuation or non-HTTP traffic (*HERE)

If anyone have an idea ?

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Jonathan Zdziarski]

Post by ZATAZ.net
Hello,
http://stephan.com/widgets/zaptastic/

This only deals with the Safari auto-install issue, which I've said
is known about already. Please read the advisory more thoroughly. I
am addressing an authentication hijacking issue.

Jonathan

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Jonathan Zdziarski]

Except, it won't truly auto-install without user confirmation first.

How many newbie users are going to know what that warning means? It
doesn't warn that someone could run malicious software by downloading
and installing this...and the wording even fooled me. I thought I was
clicking the 'Download' button, but really I was clicking a
'Download, then Auto-Install' button. Big difference. The
confirmation is misleading at best. But alas, this is a different bug
which I still feel is unaddressed.

The real issue is the dialog in that sheet should be more along
the lines of warning that it'll be "opened" as well... it's not
enough of a warning, but it does block against the non-user-
intervention issue.

Agreed.

However, you CAN download it without wanting to auto-install it.
Even with the "open safe files" preference checked, a user can
option+click the widget download link and it will ONLY download it
and not attempt to open it. At which point, you can double click
on the ZIP archive to expand it, and then safely analyze the widget
package. (And, as already established, if "open safe files" isn't
checked, then it won't install itself either.)

I don't understand why Safari has to open it at all. It's none of
Safari's business to execute applications after you download them.
There's a big difference between unzipping it for you (which I'm cool
with) and executing it. Although I am an avid Windows-hater, the one
thing I like about XP SP2 is that it prompts you to download OR open
the file.

The sudo issue is a different issue entirely, is a well known
issue, and goes beyond widgets. From a technical standpoint,
widgets are no more dangerous than any other application that a
user may download.

I have to disagree with you there. The Dashboard has a specific
interface for allowing javascript applications to execute system
commands. This opens up a big can of worms. Dashboard widgets also
run in the background (invisible to the user), unless they are
viewing their dashboard, and people on average run several. This
suggests that:

1. Any kid could code up a malicious widget and stick it on a
website. It takes a lot more to code an application someone would
want to download and insert malware into it (I realize both are
fairly trivial, but now you can do it with javascript).
2. People are likely to download and run several widgets without
checking them out or evaluating their credibility (when was the last
time you grep'd for sudo in a widget?)
3. People are likely to let a malicious widget run on their system
24x7 in the background without even knowing it

It's not like an application where, you boot it up and you notice
there's some "funny" behavior, so you get rid of it. A widget could
be sitting there, lost in obscurity, not even visible to a user and
sending all your keychain passwords and other information somewhere.

I think the bigger issue here is that widgets shouldn't have the
ability to gain administrative control. Javascript is supposed to be
considered "safe". What concerns me more is that this is integrated
with Safari, and since you can run widgets in a browser, I am
starting to wonder if you could execute system commands remotely by
visiting a website - e.g. instead of injecting the widget, whether
you could run one or take advantage of the widget interfaces remotely.

Jonathan

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Brian K.]

Post by Jonathan Zdziarski
I don't understand why Safari has to open it at all.

It doesn't _have_ to, as there is a preference against it.

Post by Jonathan Zdziarski
It's none of Safari's business to execute applications after you
download them.

Well, Safari really doesn't execute the widgets. It'll allow for the
install of the widget (which is just moving the file to ~/Library/
Widgets/), but the widget itself won't be executed until a user drags
it out.

*However*, this does bring up different issue, and that is that
someone could write a fake widget (e.g. a fake Tile Game) that uses
the same Bundle Identifier (e.g. com.apple.widget.tilegame), and
although the real Tile Game widget will be used if already dragged
out, if new Tile Game widgets are dragged out, they will be the fake
ones, as the ~/Library/Widgets content will be preferred in that
case. However, the widgets dragged out from the real Tile Game will
still reference the real widget. (Note: Stickies would probably be a
more likely target.)

Post by Jonathan Zdziarski

The sudo issue is a different issue entirely, is a well known
issue, and goes beyond widgets. From a technical standpoint,
widgets are no more dangerous than any other application that a
user may download.

Dashboard widgets also run in the background (invisible to the user),

So can normal applications.

Post by Jonathan Zdziarski
1. Any kid could code up a malicious widget and stick it on a
website. It takes a lot more to code an application someone would
want to download and insert malware into it (I realize both are
fairly trivial, but now you can do it with javascript).

Yes, I agree. On a social/practical-level, due to "availability" of
an "easier" programming language to make applications there is
increased statistical risk. At the technical-level, it's no more
dangerous than any other application (which can be dangerous). The
"cool" aspect of widgets only affects the likelyhood that a bit of
code will be run. The code is not any more or less dangerous than
other application code. Moreover, you still have to take action to
run a Widget, the Widget code is not executed without the user taking
action to do so.

Post by Jonathan Zdziarski
2. People are likely to download and run several widgets without
checking them out or evaluating their credibility (when was the
last time you grep'd for sudo in a widget?)

Again, risky user behaviors.

Post by Jonathan Zdziarski
It's not like an application where, you boot it up and you notice
there's some "funny" behavior,

It wouldn't need to seem "funny" in order to accomplish what it
needs. The application could seem perfectly fine, just the same.

Post by Jonathan Zdziarski
A widget could be sitting there, lost in obscurity, not even
visible to a user and sending all your keychain passwords and other
information somewhere.

And so could any application a user has executed taking advantage of
sudo.

Post by Jonathan Zdziarski
I think the bigger issue here is that widgets shouldn't have the
ability to gain administrative control.

The issue is *any* application shouldn't have the ability to gain
administrative control (by waiting for sudo to be done).

Post by Jonathan Zdziarski
Javascript is supposed to be considered "safe". What concerns me
more is that this is integrated with Safari, and since you can run
widgets in a browser, I am starting to wonder if you could execute
system commands remotely by visiting a website - e.g. instead of
injecting the widget, whether you could run one or take advantage
of the widget interfaces remotely.

Safari won't execute that stuff, though. All that "application"-
level access is not available to widgets while viewed in Safari.


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Brian K.]

Post by Brian K.
The issue is *any* application shouldn't have the ability to gain
administrative control (by waiting for sudo [intended for something
else] to be done).

Self correction/elaboration note: Sorry, that was a tad terse to the
point of being incomplete. It was intended to be framed in the
context of what was already discussed in this thread. (i.e.
something else doing the sudo intended for its own purposes, etc.,
all of which everyone is already well aware of.)
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Brian Phillips]

I read some time ago that malicious code when reporting home did not use
port 80 or any of the other well known ports used for simple internet
work. This means, as I understand it, that the home computer of the
malicious code is constantly listening on some port other than port 80.

Is it still the case that the standard ports are not used by malicious
code when reporting home?

If malicious code does not used the standard ports, then why not? As
far as I can see (and my knowledge is very basic) there seems to be no
reason why outgoing traffic from, say, a home computer, should not be
directed to port 80 on the IP address of the home computer of the
malicious code.

This question is of interest because one frequently see advice to the
effect that all outgoing ports other than those which are required for
use should be blocked. Clearly, if malicious code now uses, say port
80, then blocking unused ports will not increase the security of a
computer.

Any comments (or corrections) would be gratefully received.

Regards

Brian
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Who?]

Malicious code can be run on any port, and even more malicious code
wont run with TCP ports anyways, it will use icmp or some other form
of ip protocol to bypass filtering software. Blocking ports does
increase the security of a system, but further measures are needed if
you wish to have a "secure" system.

Post by Brian Phillips
I read some time ago that malicious code when reporting home did not use
port 80 or any of the other well known ports used for simple internet
work. This means, as I understand it, that the home computer of the
malicious code is constantly listening on some port other than port 80.
Is it still the case that the standard ports are not used by malicious
code when reporting home?
If malicious code does not used the standard ports, then why not? As
far as I can see (and my knowledge is very basic) there seems to be no
reason why outgoing traffic from, say, a home computer, should not be
directed to port 80 on the IP address of the home computer of the
malicious code.
This question is of interest because one frequently see advice to the
effect that all outgoing ports other than those which are required for
use should be blocked. Clearly, if malicious code now uses, say port
80, then blocking unused ports will not increase the security of a
computer.
Any comments (or corrections) would be gratefully received.
Regards
Brian
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/