full-disclosure - Mac OSX 10.4 Dashboard Authentication Hijacking Vulnerability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20050519173337.F41DD1EE15@greed.dyndns.org>
Date: Thu May 19 18:33:56 2005
From: greed at pobox.com (Graham Reed)
Subject: Mac OSX 10.4 Dashboard Authentication
	Hijacking Vulnerability

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 
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.