Re: [Full-disclosure] Mac OSX 10.4 Dashboard Authentication Hijacking Vulnerability
From: Graham Reed (greed_at_pobox.com)
To: email@example.com Date: Thu, 19 May 2005 13:33:37 -0400
Jonathan Zdziarski writes:
>> 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
So, I would argue in favor of changing the default timeout to zero (as
someone else already suggested) and enabling TTY tickets:
Then if you have users for whom a timed ticket is appropriate, re-enable it
per-user (but keep the tty_tickets setting):
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
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.
Hosted and sponsored by Secunia - http://secunia.com/