Bug 12181 - dropbear: norootlogin (-w) no longer works when PAM is enabled
Summary: dropbear: norootlogin (-w) no longer works when PAM is enabled
Status: RESOLVED FIXED
Alias: None
Product: buildroot
Classification: Unclassified
Component: Other (show other bugs)
Version: 2019.02.5
Hardware: All Linux
: P5 critical
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-04 14:06 UTC by Jan Dumon
Modified: 2019-09-05 10:16 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Dumon 2019-09-04 14:06:27 UTC 
This affects dropbear 2018.76 in 2019.02.5 and earlier.

The vanilla dropbear 2018.76 doesn't have this problem, it is introduced (ironically) by the patch for CVE-2018-15599 in https://git.busybox.net/buildroot/commit?id=4a3b0ba38fde05e8f8c3512d516d86803efa44c0

It only happens when PAM is enabled & used.

When invoked with the -w command line argument, root logins should be disallowed, but when someone attempts to login as root, the following happens:

- login attempt for root
- password is asked
- norootlogin is set but pam is invoked anyway
- pam validates the password and an 'already authenticated flag' gets set
- login still fails (as is expected) and password is asked again
- regardless of input, root can log in because he was authenticated before.
  (completely unexpected !!!)

It's still required to have a proper password but the root login should not be allowed per the -w command line argument.
Comment 1 Jan Dumon 2019-09-04 14:10:13 UTC 
2019.08 is not affected as it uses a more recent dropbear (2019.78) and no longer has the CVE patch.
This bug is only applicable to the LTS (2019.02.xx)
Comment 2 Peter Korsgaard 2019-09-04 20:02:43 UTC 
(In reply to Jan Dumon from comment #1)
So that presumably means that it has gotten fixed upstream. Looking at the git history:

git shortlog DROPBEAR_2018.76..DROPBEAR_2019.78 -- svr-authpam.c
Matt Johnston (1):
      Wait to fail invalid usernames

vincentto13 (1):
      Fix for issue successfull login of disabled user (#78)

Presumably this is fixed by the 2nd patch. Can you try applying this patch to the 2019.02.x version and test:

commit a0aa2749813331134452f80bb8a808bdc871ba41
Author: vincentto13 <33652988+vincentto13@users.noreply.github.com>
Date:   Wed Mar 20 15:03:40 2019 +0100

This commit introduces fix for scenario:
1. Root login disabled on dropbear
2. PAM authentication model enabled

While login as root user, after prompt for password
user is being notified about login failrue, but
after second attempt of prompt for password within
same session, login becames succesfull.

Signed-off-by: Pawel Rapkiewicz <pawel.rapkiewicz@gmail.com>
---
 svr-authpam.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/svr-authpam.c b/svr-authpam.c
index d201bc9..e236db4 100644
--- a/svr-authpam.c
+++ b/svr-authpam.c
@@ -275,6 +275,7 @@ void svr_auth_pam(int valid_user) {
                /* PAM auth succeeded but the username isn't allowed in for another reason
                (checkusername() failed) */
                send_msg_userauth_failure(0, 1);
+               goto cleanup;
        }

        /* successful authentication */
Comment 3 Jan Dumon 2019-09-05 07:58:41 UTC 
(In reply to Peter Korsgaard from comment #2)
> Presumably this is fixed by the 2nd patch. Can you try applying this patch to
> the 2019.02.x version and test:

Tried it and it works, no more root logins with -w.