Bug#105476: proc and auth not robust

[Marcus Brinkmann]

Package: hurd

Hi,

proc and auth both have an easy exploitable defect.  I noticed it when
reading proc_reauthenticate, which calls auth_server_authenticate within the
global lock.  This makes proc to block until the caller goes ahead and calls
auth_user_authenticate.  But if he never does, proc will be locked up.

There are two bugs here, in my opinion.  First, I think that proc should
just loose the global lock while calling auth_server_authenticate (XXX have
to check if this introduces any races).  This will occupy the current
thread, though, and we must be careful not to make it wait for all eternity
(see below). Alternatively, proc could make use of asynchronous communication
(eg call auth_server_authentication_request and return MIG_NO_REPLY, then send 
the
real answer later in S_auth_server_authenticate_reply).  Either will prevent
proc from being stuck.

The other issue is that even if we do this, both auth and proc will sit on
memory and threads if the user destroys the rendezvous port.  I think that
auth should request a dead name notification for the rendezvous port, and on
getting such a notification, go ahead and signal the associated condition.
The sleepers should check if the rendezvous port was destroyed and return with
an appropriate error message.  This prevents the auth server and the server
with a pending authentification from leaking any resources.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de