openssh bugs - Jan 2013 - [Bug 2061] New: Request for PermitRootLogin to be enforced prior to credential check

https://bugzilla.mindrot.org/show_bug.cgi?id=2061

            Bug ID: 2061
           Summary: Request for PermitRootLogin to be enforced prior to
                    credential check
    Classification: Unclassified
           Product: Portable OpenSSH
           Version: 6.1p1
          Hardware: Other
                OS: OpenBSD
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: vram at tradermail.info

Unless I am misreading the code, at present, when an attempt is made to
log in as "root", first the login attempt is authenticated.  Only
afterwards is auth_root_allowed(...) called.  Thus if someone wants to
try to login as root via ssh even when PermitRootLogin=no it is only
*after* they succesfully use the correct password/key that the option
is enforced, and the "ROOT LOGIN REFUSED" log message is emitted. 
Otherwise, it is logged like any other failed attempt.

However, if we have PermitRootLogin=no set, then knowing immediately
via the big glaring "ROOT LOGIN REFUSED" log message sooner rather
than
later allows the administrator to more quickly and easily know that an
inappropriate access attempt is being made.  After all, this log
message exists for a reason.

I'd like to politely request that PermitRootLogin be honored by instead
enforcing the negative option values even prior to checking the
credentials.  Once authctxt->pw is valid and the corresponding UID is
known to be 0, then auth_root_allowed(...) should be called upstream of
the userauth(...) call for that authctxt.

Thanks for your consideration and for OpenSSH.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2061

--- Comment #1 from V. Ram <vram at tradermail.info> ---
Created attachment 2208
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2208&action=edit
Patch to auth2.c to move check to see if permissible root login is
being attempted prior to calling m->userauth

I apologize ahead of time for any whitespace, formatting, or style
screwups.  I basically moved the check being done for whether the user
is root and the method is permitted by the configuration out of
userauth_finish(...) and up into input_userauth_request(...).  This
should satisfy the gist of what I'm asking.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2061

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at zip.com.au
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #2 from Darren Tucker <dtucker at zip.com.au> ---
In general we try to leak as little information as possible to a
potential attacker, and this would give them an early warning that
they'll be denied by policy.  (strictly by that policy sshd wouldn't
tell you why it's not permitting the login at all, so in theory we
should be removing the ROOT LOGIN REFUSED message entirely).

sorry, but if anything we'll be making it less obvious rather than
more.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2061

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #3 from Damien Miller <djm at mindrot.org> ---
Close all resolved bugs after 7.3p1 release

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.