openssh unix dev - Feb 2016 - Test Failure OpenSSH 7.1 P2 on HPE NSE for integrity

On February 9, 2016 9:30 PM, Darren Tucker wrote:
> To: Randall S. Becker <rsbecker at nexbridge.com>
> Cc: OpenSSH Devel List <openssh-unix-dev at mindrot.org>
> Subject: Re: Test Failure OpenSSH 7.1 P2 on HPE NSE for integrity
> 
[...]
> This one looks odd.  The ssh session itself looks OK: it authenticates then
> sends a printf shell command (basically, just a way of guaranteeing a
> minimum amount of output being sent back:
> 
> > debug1: Sending command: printf "%4096s" " "
> 
> The session then closes OK but ssh exists with a -1 error code, which gets
> propagated back up the stack as a failure.
> 
> > debug1: Exit status -1
> 
> Exit statuses in POSIX should be 0-255.  We can see in the sshd.log that
the
> server sent an exit status (session_exit_message), so either your printf
> command/builtin returns a bogus exit code, or ssh is mishandling it.
> 
> What's the return code of printf?  ie:
> 
> printf "%4096s" " "; echo $?
Dumps 4K of blanks. Exit code reports 0, as expected. Tried in bash and ksh. Is
there a missing return buried that ssh is pulling a non-zero off the stack
somewhere?

On February 10, 2016 10:23 AM, I wrote:
> On February 9, 2016 9:30 PM, Darren Tucker wrote:
> [...]
> > This one looks odd.  The ssh session itself looks OK: it authenticates
> > then sends a printf shell command (basically, just a way of
> > guaranteeing a minimum amount of output being sent back:
> >
> > > debug1: Sending command: printf "%4096s" " "
> >
> > The session then closes OK but ssh exists with a -1 error code, which
> > gets propagated back up the stack as a failure.
> >
> > > debug1: Exit status -1
I put in a couple of debug statements in clientloop.c where exit_status is
set. It looks like the initialization of exit_status = -1 is the only point
where the value is modified. I'm trying to figure out how the while can exit
without exit_status being modified. Can you shed some light on that? The
neither of the packet_get_int() calls that set exit_status (approx. near
1790 and 2091) are being invoked. Modpipe seems happy enough, with the read
and write calls working and internal aborts.

Cheers,
Randall

On Fri, Feb 12, 2016 at 9:25 AM, Randall S. Becker
<rsbecker at nexbridge.com> wrote:
> On February 10, 2016 10:23 AM, I wrote:
>> On February 9, 2016 9:30 PM, Darren Tucker wrote:
>> [...]
>> > This one looks odd.  The ssh session itself looks OK: it
authenticates
>> > then sends a printf shell command (basically, just a way of
>> > guaranteeing a minimum amount of output being sent back:
>> >
>> > > debug1: Sending command: printf "%4096s" "
"
>> >
>> > The session then closes OK but ssh exists with a -1 error code,
which
>> > gets propagated back up the stack as a failure.
>> >
>> > > debug1: Exit status -1
>
> I put in a couple of debug statements in clientloop.c where exit_status is
> set. It looks like the initialization of exit_status = -1 is the only point
> where the value is modified.
Looking closer at the sshd log:

debug1: client_input_channel_req: channel 0 rtype exit-signal reply 0

The code for this is in session_exit_message() and looks like:

        if (WIFEXITED(status)) {
                channel_request_start(s->chanid, "exit-status", 0);
                packet_put_int(WEXITSTATUS(status));
                packet_send();
        } else if (WIFSIGNALED(status)) {
                channel_request_start(s->chanid, "exit-signal", 0);

so your printf is probably dying with a signal rather than exiting.
Which signal?  dunno, but my guess would be SIGPIPE.  Try adding
something like this to the top of session_exit_message():

        debug3("%s: status: %d", __func__, status);
> I'm trying to figure out how the while can exit
> without exit_status being modified. Can you shed some light on that?
if the server never sends an "exit-status" packet (as opposed to an
"exit-signal" packet, which it does send) then the exit-status code in
client_input_channel_req() will never get called and exit_status will
remain -1 since that's what it's initialized to.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.