openssh bugs - Jun 2018 - [Bug 2876] New: PAM_TEXT_INFO and PAM_ERROR_MSG conversation not honoured during PAM authentication

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

            Bug ID: 2876
           Summary: PAM_TEXT_INFO and PAM_ERROR_MSG conversation not
                    honoured during PAM authentication
           Product: Portable OpenSSH
           Version: 7.7p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: PAM support
          Assignee: unassigned-bugs at mindrot.org
          Reporter: bugs at mrvanes.com

I built a PAM module which only responsibility is sending a challenge
to the end-user in the form of a (unique) url. No input is required,
nor appreciated.

openssh however, discards all conversation of type PAM_TEXT_INFO and
PAM_ERROR_MSG until the PAM module returns control. All conversation of
type PAM_PROMPT_ECHO_[ON|OFF] is honoured, but I don't want the user to
need to enter something, not even <enter> before returning the
authentication result.

I know displaying messages of type PAM_ERROR_MSG is frowned upon and
regarded as leaking information, but PAM_TEXT_INFO is there for a
reason. Please reconsider displaying them, without the need for user
interaction.

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

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
Which authentication method are you using?

The behaviour that you describe is probably true for password
authentication, because the protocol doesn't really allow arbitrary
messages while that's happening.

You should try disabling password authentication and using
keyboard-interactive authentication instead, as it allows informational
prompts.

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

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

--- Comment #2 from Martin <bugs at mrvanes.com> ---
This is what debug tells me at the moment my PAM pluging takes over:
debug1: Next authentication method: keyboard-interactive

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

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

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at dtucker.net

--- Comment #3 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to Damien Miller from comment #1)
> You should try disabling password authentication and using
> keyboard-interactive authentication instead, as it allows
> informational prompts.
Looking at the code, I think it's the case for keyboard-interactive
too:

sshpam_query([...]
                case PAM_ERROR_MSG:
                case PAM_TEXT_INFO:
                        /* accumulate messages */
                        len = plen + mlen + 2;
[etc]

I think it's that way because the same conversation function had to
handle both Protocol 2 keyboard-interactive and Protocol 1 TIS
challenge-response.  The latter is fairly limited, but is now
(mercifully) gone.

-- 
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=2876

--- Comment #4 from Damien Miller <djm at mindrot.org> ---
The code below that comment appears to be filling in the
challenge-response prompts, which gets sent immediately via

auth2-chall.c:send_userauth_info_request ->
kbdintctxt->device->query (auth-pam.c:sshpam_query)

AFAIK this already supports multiple rounds of prompting, but maybe the
PAM code doesn't? I'm rusty on that...

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

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

--- Comment #5 from Martin <bugs at mrvanes.com> ---
All I know is that it works for PAM_PROMPT_ECHO_[ON|OFF] in OpenSSH and
it doesn't for PAM_TEXT_INFO.

Also, in pamtester they work both.

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

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

--- Comment #6 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to Damien Miller from comment #4)
> The code below that comment appears to be filling in the
> challenge-response prompts, which gets sent immediately via
It's dependent on the ordering of the PAM messages with the
conversation struct.  INFO first will probably work, PROMPT_ECHO.*
probably won't.
> AFAIK this already supports multiple rounds of prompting, but maybe
> the PAM code doesn't? I'm rusty on that...
It sort of does but not in the general case.  The way it currently
works with only one prompt per round was required for SSH1 TIS but not
SSH2 keyboard-int.

-- 
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=2876

--- Comment #7 from Martin <bugs at mrvanes.com> ---
INFO is the only message I want to send and first doesn't make a
difference (in my case it's always first). It's never sent immediately.
PROMPT allways gets sent immediately.

-- 
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=2876

--- Comment #8 from Damien Miller <djm at mindrot.org> ---
Created attachment 3160
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3160&action=edit
assign ERROR_MSG/TEXT_INFO messages to kbd-int information field

I think we can just assign these messages to *info - this ends up in
the instruction field in SSH_MSG_USERAUTH_INFO_REQUEST and being
printed by the client too.

This would mean we send SSH_MSG_USERAUTH_INFO_REQUEST messages to the
client with no prompts, but this is permitted by the protocol AFAIK and
our client at least seems to support it (though I bet there are others
that will choke...)

We don't really have a choice though - we can't tell a priori what the
next message from the PAM subprocess is going to be and it will block
for prompt messages.

-- 
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=2876

--- Comment #9 from Damien Miller <djm at mindrot.org> ---
That diff is insufficient (or maybe wrong). It gets the PAM subprocess
desyncronised in sshpam_respond(), since that expects num==1 only.

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

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

James Ralston <ralston at pobox.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ralston at pobox.com

--- Comment #10 from James Ralston <ralston at pobox.com> ---
Hi Damien. Is there any way we could assist with the effort here?

MFA logins (e.g., Duo) are becoming more and more ubiquitous. When MFA
is in play, it can be pretty important that PAM_TEXT_INFO messages are
pushed immediately, instead of being collected until the next
PAM_PROMPT_ECHO_[ON|OFF] response.

E.g., the PAM_TEXT_INFO message could be this:

"Hey, we just auto-pushed an auth request to your mobile device, so if
it looks like your login session just hung, maybe go grab your phone
and approve the request? Or just sit there staring dumbly at the screen
for 90 seconds until the push request times out. Your call."

I get why the /* accumulate messages */ logic was the case historically
(because SSH protocol version 1 was teh suck), but now that SSHv1 is
(deservedly) dead, it would be great to address this for SSHv2
keyboard-interactive auth.

If there's a concern about potentially breaking other ssh clients (e.g.
comment 8), perhaps the "push PAM_TEXT_INFO messages immediately"
behavior could be toggled by an option? E.g.,
PAMImmmediateNotifications?

If you can come up with a tentative patch, we'd be happy to help test
it, against multiple different ssh clients we have here (OpenSSH,
Putty, et. al.)

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

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

Magnus Svendsen <magnusgsvend at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |magnusgsvend at gmail.com

--- Comment #11 from Magnus Svendsen <magnusgsvend at gmail.com> ---
Created attachment 3610
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3610&action=edit
Extension to Damien Millers patch

-- 
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=2876

--- Comment #12 from Magnus Svendsen <magnusgsvend at gmail.com> ---
Sorry, forgot to comment my patch, quite new to this bugzilla stuff.

Does anyone know why sshpam_respond only wants num=1? I tried doing
num=2 from the PAM_TEXT_INFO case, but ended up just getting
sshpam_device.query failed back as an error.

(also, my patch seems to be the one where i tried num=2, but that
seemed to fail, the actual patch i wanted to upload doesn't have num=2,
just checks if its 0).

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

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

bill.lazenby at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bill.lazenby at gmail.com

--- Comment #13 from bill.lazenby at gmail.com ---
Has there been any progress on this issue?  It really makes using
something like Duo more confusing for the end user.

-- 
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=2876

--- Comment #14 from Magnus Svendsen <magnusgsvend at gmail.com> ---
https://github.com/openssh/openssh-portable/pull/337

Made a PR here which solves it (although, it did take a few attempts,
seems like sshd pam behaviour changed sometime last year)

This fixed the issue for my personal project, haven't pushed much to
get it accepted though

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

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

Marco Trevisan <mail at 3v1n0.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mail at 3v1n0.net

--- Comment #15 from Marco Trevisan <mail at 3v1n0.net> ---
Hey,

Another attempt here at
https://github.com/openssh/openssh-portable/pull/452

Sadly this change also required some client changes (mostly
"cosmetic")
as the handling of the instructions was not supported as utf-8 text (as
it should be according to the spec).

I've also added a setting to control this and in order to continue
supporting legacy clients without requiring any change on their side,
the device `pam-legacy-instructions` (e.g.
KbdInteractiveDevices=pam-legacy-instructions) can be used to make new
daemons to act as before.

Commits should explain better the rationale.

-- 
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=2876

Tim Connors <tim.w.connors at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tim.w.connors at gmail.com

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