thr3ads.net - openssh unix dev - sshd audit not happy with ssh1 and scp [Sep 2006]

If this information is useful, please help other people find it:
Share via:

John Baldwin

2006-Sep-14 20:41 UTC

sshd audit not happy with ssh1 and scp

I think I've found a bug with sshd handling audit events for commands (like 
scp) over ssh1 connections.  Specifically, after updating to a recent FreeBSD 
6.x with audit support, I'm getting log messages like these when using scp 
over ssh1:

Sep 12 14:13:16 <auth.info> bm55 sshd[12335]: Accepted rsa for xxx from 
A.B.C.D port 2981
Sep 12 14:13:16 <auth.crit> bm55 sshd[12335]: fatal: monitor_read:
unpermitted
request 57
Sep 12 14:13:16 <console.info> bm55 kernel: Sep 12 14:13:16
<auth.crit> bm55
sshd[12335]: fatal: monitor_read: unpermitted request 57
Sep 12 14:13:16 <auth.crit> bm55 sshd[12337]: fatal: mm_request_send:
write:
Broken pipe
Sep 12 14:13:16 <console.info> bm55 kernel: Sep 12 14:13:16
<auth.crit> bm55
sshd[12337]: fatal: mm_request_send: write: Broken pipe

I tracked these down to the audit event handling for ssh1.  Changing ssh1 to 
use MON_PERMIT instead of MON_ONCE (ssh2 uses MON_PERMIT) for
REQ_AUDIT_COMMAND fixes it (well, shuts up the warnings):

==== //depot/yahoo/ybsd_6/src/crypto/openssh/monitor.c#4 (text+ko) ===
@@ -272,7 +272,7 @@
     {MONITOR_REQ_TERM, 0, mm_answer_term},
 #ifdef SSH_AUDIT_EVENTS
     {MONITOR_REQ_AUDIT_EVENT, MON_PERMIT, mm_answer_audit_event},
-    {MONITOR_REQ_AUDIT_COMMAND, MON_ONCE, mm_answer_audit_command},
+    {MONITOR_REQ_AUDIT_COMMAND, MON_PERMIT, mm_answer_audit_command},
 #endif
     {0, 0, NULL}
 };

I notice that early on it tries to enable MONITOR_REQ_AUDIT_COMMAND in
mm_answer_pwnamallow().  However, this doesn't actually work as it tries
to enable it in the monitor_dispatch table (which doesn't even have a
REQ_AUDIT_COMMAND in either version 1.5 or 2.0) when it needs to be enabled
in the monitor_postauth table instead.   So, you can either make it
MON_PERMIT like above or you can fix it to not do the monitor_permit() on
the passed in table, but do it on the appropriate postauth table instead.

I'm using the above patch for now, but if you fix openssh I'll go with
the
vendor's fix once it makes it into FreeBSD of course.  I don't know if
the
better fix is the patch above to get ssh1 in sync with ssh2 (in which case th 
monitor_permit() in mm_answer_pwnameallow() should probably be removed), or 
to fix mm_answer_pwnameallow() to perform the monitor_permit() on the correct 
dispatch table.

-- 
John Baldwin

John Baldwin

2006-Sep-14 20:41 UTC

head link

sshd audit not happy with ssh1 and scp

I think I've found a bug with sshd handling audit events for commands (like 
scp) over ssh1 connections.  Specifically, after updating to a recent FreeBSD 
6.x with audit support, I'm getting log messages like these when using scp 
over ssh1:

Sep 12 14:13:16 <auth.info> bm55 sshd[12335]: Accepted rsa for xxx from 
A.B.C.D port 2981
Sep 12 14:13:16 <auth.crit> bm55 sshd[12335]: fatal: monitor_read:
unpermitted
request 57
Sep 12 14:13:16 <console.info> bm55 kernel: Sep 12 14:13:16
<auth.crit> bm55
sshd[12335]: fatal: monitor_read: unpermitted request 57
Sep 12 14:13:16 <auth.crit> bm55 sshd[12337]: fatal: mm_request_send:
write:
Broken pipe
Sep 12 14:13:16 <console.info> bm55 kernel: Sep 12 14:13:16
<auth.crit> bm55
sshd[12337]: fatal: mm_request_send: write: Broken pipe

I tracked these down to the audit event handling for ssh1.  Changing ssh1 to 
use MON_PERMIT instead of MON_ONCE (ssh2 uses MON_PERMIT) for
REQ_AUDIT_COMMAND fixes it (well, shuts up the warnings):

==== //depot/yahoo/ybsd_6/src/crypto/openssh/monitor.c#4 (text+ko) ===
@@ -272,7 +272,7 @@
     {MONITOR_REQ_TERM, 0, mm_answer_term},
 #ifdef SSH_AUDIT_EVENTS
     {MONITOR_REQ_AUDIT_EVENT, MON_PERMIT, mm_answer_audit_event},
-    {MONITOR_REQ_AUDIT_COMMAND, MON_ONCE, mm_answer_audit_command},
+    {MONITOR_REQ_AUDIT_COMMAND, MON_PERMIT, mm_answer_audit_command},
 #endif
     {0, 0, NULL}
 };

I notice that early on it tries to enable MONITOR_REQ_AUDIT_COMMAND in
mm_answer_pwnamallow().  However, this doesn't actually work as it tries
to enable it in the monitor_dispatch table (which doesn't even have a
REQ_AUDIT_COMMAND in either version 1.5 or 2.0) when it needs to be enabled
in the monitor_postauth table instead.   So, you can either make it
MON_PERMIT like above or you can fix it to not do the monitor_permit() on
the passed in table, but do it on the appropriate postauth table instead.

I'm using the above patch for now, but if you fix openssh I'll go with
the
vendor's fix once it makes it into FreeBSD of course.  I don't know if
the
better fix is the patch above to get ssh1 in sync with ssh2 (in which case th 
monitor_permit() in mm_answer_pwnameallow() should probably be removed), or 
to fix mm_answer_pwnameallow() to perform the monitor_permit() on the correct 
dispatch table.

-- 
John Baldwin
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Darren Tucker

2006-Sep-16 09:23 UTC

head link

sshd audit not happy with ssh1 and scp

On Thu, Sep 14, 2006 at 04:41:20PM -0400, John Baldwin
wrote:> I think I've found a bug with sshd handling audit events for commands
(like
> scp) over ssh1 connections.  Specifically, after updating to a recent
FreeBSD
> 6.x with audit support, I'm getting log messages like these when using
scp
> over ssh1:
> 
> Sep 12 14:13:16 <auth.info> bm55 sshd[12335]: Accepted rsa for xxx
from
> A.B.C.D port 2981
> Sep 12 14:13:16 <auth.crit> bm55 sshd[12335]: fatal: monitor_read:
unpermitted
Thanks for the report.  FreeBSD is using audit support now?  Is it the
debug driver, or are you using OpenBSM or something?

[...]> -    {MONITOR_REQ_AUDIT_COMMAND, MON_ONCE, mm_answer_audit_command},
> +    {MONITOR_REQ_AUDIT_COMMAND, MON_PERMIT, mm_answer_audit_command},
Since SSH protocol 1 can only support a single command per session, the
intent was to only allow the monitor call once, although it probably
doesn't matter much.
> I notice that early on it tries to enable MONITOR_REQ_AUDIT_COMMAND in
> mm_answer_pwnamallow().  However, this doesn't actually work as it
tries
> to enable it in the monitor_dispatch table (which doesn't even have a
> REQ_AUDIT_COMMAND in either version 1.5 or 2.0) when it needs to be enabled
> in the monitor_postauth table instead.
You're right.  I think that should be probably be removed.

Does the following patch also resolve the problem for you?

Index: monitor.c
==================================================================RCS file:
/usr/local/src/security/openssh/cvs/openssh/monitor.c,v
retrieving revision 1.119
diff -u -p -r1.119 monitor.c
--- monitor.c	1 Sep 2006 05:48:19 -0000	1.119
+++ monitor.c	16 Sep 2006 09:15:53 -0000
@@ -286,7 +286,7 @@ struct mon_table mon_dispatch_postauth15
     {MONITOR_REQ_TERM, 0, mm_answer_term},
 #ifdef SSH_AUDIT_EVENTS
     {MONITOR_REQ_AUDIT_EVENT, MON_PERMIT, mm_answer_audit_event},
-    {MONITOR_REQ_AUDIT_COMMAND, MON_ONCE, mm_answer_audit_command},
+    {MONITOR_REQ_AUDIT_COMMAND, MON_PERMIT|MON_ONCE, mm_answer_audit_command},
 #endif
     {0, 0, NULL}
 };
@@ -660,9 +660,6 @@ mm_answer_pwnamallow(int sock, Buffer *m
 	if (options.use_pam)
 		monitor_permit(mon_dispatch, MONITOR_REQ_PAM_START, 1);
 #endif
-#ifdef SSH_AUDIT_EVENTS
-	monitor_permit(mon_dispatch, MONITOR_REQ_AUDIT_COMMAND, 1);
-#endif
 
 	return (0);
 }

-- 
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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

John Baldwin

2006-Sep-16 13:31 UTC

head link

sshd audit not happy with ssh1 and scp

On Saturday 16 September 2006 05:23, Darren Tucker
wrote:> On Thu, Sep 14, 2006 at 04:41:20PM -0400, John Baldwin wrote:
> > I think I've found a bug with sshd handling audit events for
commands (like
> > scp) over ssh1 connections.  Specifically, after updating to a recent
FreeBSD
> > 6.x with audit support, I'm getting log messages like these when
using scp
> > over ssh1:
> > 
> > Sep 12 14:13:16 <auth.info> bm55 sshd[12335]: Accepted rsa for
xxx from
> > A.B.C.D port 2981
> > Sep 12 14:13:16 <auth.crit> bm55 sshd[12335]: fatal:
monitor_read: unpermitted
> 
> Thanks for the report.  FreeBSD is using audit support now?  Is it the
> debug driver, or are you using OpenBSM or something?
OpenBSM.  It's now in FreeBSD 6.x and BSM_AUDIT is enabled by default.
> [...]
> > -    {MONITOR_REQ_AUDIT_COMMAND, MON_ONCE, mm_answer_audit_command},
> > +    {MONITOR_REQ_AUDIT_COMMAND, MON_PERMIT, mm_answer_audit_command},
> 
> Since SSH protocol 1 can only support a single command per session, the
> intent was to only allow the monitor call once, although it probably
> doesn't matter much.
Ok.
> > I notice that early on it tries to enable MONITOR_REQ_AUDIT_COMMAND in
> > mm_answer_pwnamallow().  However, this doesn't actually work as it
tries
> > to enable it in the monitor_dispatch table (which doesn't even
have a
> > REQ_AUDIT_COMMAND in either version 1.5 or 2.0) when it needs to be
enabled
> > in the monitor_postauth table instead.
> 
> You're right.  I think that should be probably be removed.
> 
> Does the following patch also resolve the problem for you?
Yes, the patch works great.  Thanks!  I assume you are going to commit
that to OpenSSH?  DES, can you import this as a vendor fix on the
vendor branch?
> Index: monitor.c
> ==================================================================> RCS
file: /usr/local/src/security/openssh/cvs/openssh/monitor.c,v
> retrieving revision 1.119
> diff -u -p -r1.119 monitor.c
> --- monitor.c	1 Sep 2006 05:48:19 -0000	1.119
> +++ monitor.c	16 Sep 2006 09:15:53 -0000
> @@ -286,7 +286,7 @@ struct mon_table mon_dispatch_postauth15
>      {MONITOR_REQ_TERM, 0, mm_answer_term},
>  #ifdef SSH_AUDIT_EVENTS
>      {MONITOR_REQ_AUDIT_EVENT, MON_PERMIT, mm_answer_audit_event},
> -    {MONITOR_REQ_AUDIT_COMMAND, MON_ONCE, mm_answer_audit_command},
> +    {MONITOR_REQ_AUDIT_COMMAND, MON_PERMIT|MON_ONCE,
mm_answer_audit_command},
>  #endif
>      {0, 0, NULL}
>  };
> @@ -660,9 +660,6 @@ mm_answer_pwnamallow(int sock, Buffer *m
>  	if (options.use_pam)
>  		monitor_permit(mon_dispatch, MONITOR_REQ_PAM_START, 1);
>  #endif
> -#ifdef SSH_AUDIT_EVENTS
> -	monitor_permit(mon_dispatch, MONITOR_REQ_AUDIT_COMMAND, 1);
> -#endif
>  
>  	return (0);
>  }
> 
-- 
John Baldwin
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Darren Tucker

2006-Sep-17 02:02 UTC

head link

sshd audit not happy with ssh1 and scp

On Sat, Sep 16, 2006 at 09:31:37AM -0400, John Baldwin
wrote:> On Saturday 16 September 2006 05:23, Darren Tucker wrote:
> > Thanks for the report.  FreeBSD is using audit support now?  Is it the
> > debug driver, or are you using OpenBSM or something?
> 
> OpenBSM.  It's now in FreeBSD 6.x and BSM_AUDIT is enabled by default.
Cool.  Out of curiousity, did you have to modify the audit support in
sshd, or did it work out of the box?
> > You're right.  I think that should be probably be removed.
> > 
> > Does the following patch also resolve the problem for you?
> 
> Yes, the patch works great.  Thanks!  I assume you are going to commit
> that to OpenSSH?  DES, can you import this as a vendor fix on the
> vendor branch?
Yes, it has been committed and will be in 4.4p1.

Thanks again.

-- 
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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

John Baldwin

2006-Sep-17 02:45 UTC

head link

sshd audit not happy with ssh1 and scp

On Saturday 16 September 2006 22:02, Darren Tucker
wrote:> On Sat, Sep 16, 2006 at 09:31:37AM -0400, John Baldwin wrote:
> > On Saturday 16 September 2006 05:23, Darren Tucker wrote:
> > > Thanks for the report.  FreeBSD is using audit support now?  Is
it the
> > > debug driver, or are you using OpenBSM or something?
> > 
> > OpenBSM.  It's now in FreeBSD 6.x and BSM_AUDIT is enabled by
default.
> 
> Cool.  Out of curiousity, did you have to modify the audit support in
> sshd, or did it work out of the box?
I have no idea.  I just upgraded to newer FreeBSD 6.x and started
getting the error messages in my logs. :)   Probably a better person
to ask about anything OpenBSM related in FreeBSD is rwatson at FreeBSD.org
or csjp at FreeBSD.org.
 > > > You're right.  I think that should be probably be removed.
> > > 
> > > Does the following patch also resolve the problem for you?
> > 
> > Yes, the patch works great.  Thanks!  I assume you are going to commit
> > that to OpenSSH?  DES, can you import this as a vendor fix on the
> > vendor branch?
> 
> Yes, it has been committed and will be in 4.4p1.
> 
> Thanks again.
Thanks for the review and fix.

-- 
John Baldwin
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Dag-Erling [iso-8859-1] Smørgrav

2006-Sep-17 09:13 UTC

head link

sshd audit not happy with ssh1 and scp

Darren Tucker <dtucker at zip.com.au> writes:> Cool.  Out of curiousity, did you have to modify the audit support in
> sshd, or did it work out of the box?
It works right out of the box.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Possibly Parallel Threads

Search for more apparently analagous threads

openssh unix dev - Sep 2006 - sshd audit not happy with ssh1 and scp

sshd audit not happy with ssh1 and scp

sshd audit not happy with ssh1 and scp

sshd audit not happy with ssh1 and scp

sshd audit not happy with ssh1 and scp

sshd audit not happy with ssh1 and scp

sshd audit not happy with ssh1 and scp

sshd audit not happy with ssh1 and scp

Possibly Parallel Threads