openssh unix dev - Oct 2003 - Fwd: Re: Bus Error with OpenSSH 3.7.1p2 on Solaris 8, SPARC 64-bit

The story of this problem, AFAIK, is that Solaris 8 YASSP and JASS and
vigilant/paranoid sysadmins have been known to set a restricitve umask in
/etc/default/login. OpenSSH compatibility for Solaris 8 has been spotty at times
for sparcv9 targets. This time, when a sparcv9 binary tries to sscanf(3C) the
numeric umask as a long octal and put it in a mode_t, SIGBUS happens.

What this looks like in real life is: You are running a 64 bit OpenSSH_3.7.1p2
sshd on Solaris 8, and you have enforced UMASK in /etc/default/login. You try to
log into this sshd, but after all the authentication and channel setup, just
before you get your shell/command executed *POOF*. The daemon is getting a
SIGBUS trying to handle the UMASK from /etc/default/login with sscanf(3C);

It just so happens that I'm using gcc-3.3.1, and I can't say this is
definitely an OS or libC or compiler issue. However, the 32 bit binary works,
and the 64 bit binary SIGBUSes. Here is a demo that will work whether you are
YASSP/JASS hardenened or whatever (because the umask is hard-coded instead of
read from /etc/default/login).

---cut---
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>

int main (){
 char var[4] = "777\0";
 mode_t mask;
 printf("Test case: UMASK=%s in /etc/default/login.\n",var);
 printf("Reading var for a regular octal value: \n");
 sscanf(var, "%5o", &mask);
 printf("\tUMASK=%o\n",mask);
 printf("Reading var for a long octal value: \n");
/*** expect a SIGBUS here ***/
 sscanf(var, "%5lo", &mask);
 printf("\tUMASK=%o\n",mask);
}
---cut---

This bug is in session.c. It is only exposed AKAIK on 64 bit binaries running on
hardened (default umask is set) Solaris boxes. I'm not sure why session.c
needs to sscanf a long octal. Can someone try this with Forte compilers? Can we
get by with sscanf(var, "%5o", &mask)? What is the *right* thing
to do here?

---
Jeremy

aphor at speakeasy.net wrote:
> This time, when a sparcv9 binary tries to sscanf(3C) the numeric umask
> as a long octal and put it in a mode_t, SIGBUS happens.
Yep, it's a bug.  Attached is the patch that went into the tree a while
back.

-- 
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.
-------------- next part --------------
Index: openssh_cvs/ChangeLog
diff -u openssh_cvs/ChangeLog:1.3052 openssh_cvs/ChangeLog:1.3053
--- openssh_cvs/ChangeLog:1.3052	Thu Oct  2 17:32:30 2003
+++ openssh_cvs/ChangeLog	Thu Oct  2 20:07:09 2003
@@ -31,6 +31,8 @@
  - (dtucker) [configure.ac] Don't set DISABLE_SHADOW when configuring
    --with-pam.  ok djm@
  - (dtucker) [ssh-gss.h] Prototype change missed in sync.
+ - (dtucker) [session.c] Fix bus errors on some 64-bit Solaris configurations.
+   Based on patches by Matthias Koeppe and Thomas Baden.  ok djm@
 
 20030930
  - (bal) Fix issues in openbsd-compat/realpath.c
@@ -1266,4 +1268,4 @@
  - Fix sshd BindAddress and -b options for systems using fake-getaddrinfo.
    Report from murple at murple.net, diagnosis from dtucker at zip.com.au
 
-$Id: ChangeLog,v 1.3052 2003/10/02 07:32:30 dtucker Exp $
+$Id: ChangeLog,v 1.3053 2003/10/02 10:07:09 dtucker Exp $
Index: openssh_cvs/session.c
diff -u openssh_cvs/session.c:1.256 openssh_cvs/session.c:1.257
--- openssh_cvs/session.c:1.256	Thu Oct  2 16:12:37 2003
+++ openssh_cvs/session.c	Thu Oct  2 20:07:09 2003
@@ -906,7 +906,7 @@
 {
 	char **tmpenv = NULL, *var;
 	u_int i, tmpenvsize = 0;
-	mode_t mask;
+	u_long mask;
 
 	/*
 	 * We don't want to copy the whole file to the child's environment,
@@ -927,7 +927,7 @@
 	
 	if ((var = child_get_env(tmpenv, "UMASK")) != NULL)
 		if (sscanf(var, "%5lo", &mask) == 1)
-			umask(mask);
+			umask((mode_t)mask);
 	
 	for (i = 0; tmpenv[i] != NULL; i++)
 		xfree(tmpenv[i]);

I do my compilations with the Forte C compiler on
Solaris 8 hardened with YASSP.

The best I can determine is that when compiling 64-bit
Sparcv9 code, a LONG is 64-bits.  On the other hand,
Mode_T appears to be a 32-bit value.  So when doing a
scanf of a long, the code was assuming that a mode_t
and a long are the same size.  The patch which Darren
sent steps around this issue by letting session.c read
a long, and then casts that to mode_t when the value
is referenced.

Cheers,
-Thomas

--- aphor at speakeasy.net wrote:
> The story of this problem, AFAIK, is that Solaris 8
> YASSP and JASS and vigilant/paranoid sysadmins have
> been known to set a restricitve umask in
> /etc/default/login. OpenSSH compatibility for
> Solaris 8 has been spotty at times for sparcv9
> targets. This time, when a sparcv9 binary tries to
> sscanf(3C) the numeric umask as a long octal and put
> it in a mode_t, SIGBUS happens.
> 
> What this looks like in real life is: You are
> running a 64 bit OpenSSH_3.7.1p2
> sshd on Solaris 8, and you have enforced UMASK in
> /etc/default/login. You try to log into this sshd,
> but after all the authentication and channel setup,
> just before you get your shell/command executed
> *POOF*. The daemon is getting a SIGBUS trying to
> handle the UMASK from /etc/default/login with
> sscanf(3C);
> 
> It just so happens that I'm using gcc-3.3.1, and I
> can't say this is definitely an OS or libC or
> compiler issue. However, the 32 bit binary works,
> and the 64 bit binary SIGBUSes. Here is a demo that
> will work whether you are YASSP/JASS hardenened or
> whatever (because the umask is hard-coded instead of
> read from /etc/default/login).
> 
> ---cut---
> #include <stdio.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> 
> int main (){
>  char var[4] = "777\0";
>  mode_t mask;
>  printf("Test case: UMASK=%s in
> /etc/default/login.\n",var);
>  printf("Reading var for a regular octal value:
> \n");
>  sscanf(var, "%5o", &mask);
>  printf("\tUMASK=%o\n",mask);
>  printf("Reading var for a long octal value: \n");
> /*** expect a SIGBUS here ***/
>  sscanf(var, "%5lo", &mask);
>  printf("\tUMASK=%o\n",mask);
> }
> ---cut---
> 
> This bug is in session.c. It is only exposed AKAIK
> on 64 bit binaries running on hardened (default
> umask is set) Solaris boxes. I'm not sure why
> session.c needs to sscanf a long octal. Can someone
> try this with Forte compilers? Can we get by with
> sscanf(var, "%5o", &mask)? What is the *right* thing
> to do here?
> 
> ---
> Jeremy
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com