openssh bugs - May 2013 - [Bug 2107] New: seccomp sandbox breaks GSSAPI

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

            Bug ID: 2107
           Summary: seccomp sandbox breaks GSSAPI
    Classification: Unclassified
           Product: Portable OpenSSH
           Version: 6.2p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: Kerberos support
          Assignee: unassigned-bugs at mindrot.org
          Reporter: cjwatson at debian.org

Created attachment 2273
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2273&action=edit
Handle ssh_gssapi_supported_oids in monitor for seccomp sandbox
compatibility

One of my test installations happens to have "GSSAPIAuthentication
yes", and this breaks with the seccomp sandbox.  Initially I assumed
this was specific to Simon Wilkinson's GSSAPI key exchange patch (which
I apply in Debian), but on further investigation I found that that just
causes the failure to happen earlier.  Specifically, the regression
test included in the patch I'm attaching to this bug fails if applied
in isolation.

The syscalls that are denied are, on Linux/i386, futex and stat64. 
These are used by gss_indicate_mechs, called by
ssh_gssapi_supported_oids.  futex probably doesn't matter much, but I'm
not happy about opening up stat and friends, so I think it makes more
sense to add a monitor protocol command for this function so that the
sandboxed network child doesn't have to call it directly.  Would you
consider something like the attached patch, implementing this?

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

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |djm at mindrot.org
           Assignee|unassigned-bugs at mindrot.org |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
Created attachment 2406
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2406&action=edit
Cache supported oids before privilege separation

Instead of calling out to the monitor, could we do it before the
privsep child is forked? ssh_gssapi_supported_oids() doesn't seem to
need any context to work.

This patch tries to do this, but I have no way to test it (and really
no clue at all when it comes to GSSAPI/Kerberos).

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |2188

--- Comment #2 from Damien Miller <djm at mindrot.org> ---
Put this on the list for openssh-6.6; assuming we can find someone to
test the 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=2107

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |georg at steffers.org

--- Comment #3 from Damien Miller <djm at mindrot.org> ---
*** Bug 2204 has been marked as a duplicate of this bug. ***

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

--- Comment #4 from Georg Hopp <georg at steffers.org> ---
Hi,

I can confirm that for me the patch fixes the issue.
After I applied the patch against 6.4p1 I changed back to

UsePrivilegeSeparation sandbox

and restarted sshd. I was able to log into that system
with my TGT without any problem.

I am ready for more testing if needed.

best regards
   Georg Hopp

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

--- Comment #5 from Damien Miller <djm at mindrot.org> ---
The patch you applied was the "Cache supported oids before privilege
separation" one, right?

(I just want to make sure before committing)

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

--- Comment #6 from Georg Hopp <georg at steffers.org> ---
Yes, that's correct.

https://bugzilla.mindrot.org/attachment.cgi?id=2406

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

--- Comment #7 from Georg Hopp <georg at steffers.org> ---
But don't commit it right now...

A moment ago I realized a problem that might relate to this or not.

I am now able to ssh into the machines without a TGT and without a
correct password. This might also be related to pam but I am not sure
about this now.

Anyway a su fails as expected.


The auth log of a su with a wrong password:

Feb 26 10:55:52 host su[9725]: pam_unix(su:auth): authentication
failure; logname=ghopp uid=2001 euid=0 tty=/dev/pts/17 ruser=test
rhost=  user=ghopp
Feb 26 10:55:52 host su[9725]: pam_sss(su:auth): system info:
[Preauthentication failed]
Feb 26 10:55:52 host su[9725]: pam_sss(su:auth): authentication
failure; logname=ghopp uid=2001 euid=0 tty=/dev/pts/17 ruser=test
rhost= user=ghopp
Feb 26 10:55:52 host su[9725]: pam_sss(su:auth): received for user
ghopp: 17 (Failure setting user credentials)
Feb 26 10:55:54 host su[9725]: pam_authenticate: Permission denied
Feb 26 10:55:54 host su[9725]: FAILED su for ghopp by test
Feb 26 10:55:54 host su[9725]: - /dev/pts/17 test:ghopp


The auth log of a su with the correct password:

Feb 26 10:57:13 host su[9729]: pam_unix(su:auth): authentication
failure; logname=ghopp uid=2001 euid=0 tty=/dev/pts/17 ruser=test
rhost=  user=ghopp
Feb 26 10:57:14 host su[9729]: pam_sss(su:auth): authentication
success; logname=ghopp uid=2001 euid=0 tty=/dev/pts/17 ruser=test
rhost= user=ghopp
Feb 26 10:57:14 host su[9729]: Successful su for ghopp by test
Feb 26 10:57:14 host su[9729]: + /dev/pts/17 test:ghopp
Feb 26 10:57:14 host su[9729]: pam_unix(su:session): session opened for
user ghopp by ghopp(uid=2001)


and the auth log of an ssh without a TGT and with a wrong password:

Feb 26 10:58:05 host sshd[9736]: SSH: Server;Ltype: Version;Remote:
2001:4ba0:ffff:138:1::1000-42676;Protocol: 2.0;Client:
OpenSSH_6.4p1-hpn14v2
Feb 26 10:58:06 host sshd[9736]: SSH: Server;Ltype: Kex;Remote:
2001:4ba0:ffff:138:1::1000-42676;Enc: aes128-ctr;MAC:
hmac-md5-etm at openssh.com;Comp: none [preauth]
Feb 26 10:58:06 host sshd[9736]: SSH: Server;Ltype: Authname;Remote:
2001:4ba0:ffff:138:1::1000-42676;Name: ghopp [preauth]
Feb 26 10:58:08 host sshd[9738]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruserrhost=2001:4ba0:ffff:138:1::1000 
user=ghopp
Feb 26 10:58:09 host sshd[9738]: pam_sss(sshd:auth): system info:
[Preauthentication failed]
Feb 26 10:58:09 host sshd[9738]: pam_sss(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruserrhost=2001:4ba0:ffff:138:1::1000
user=ghopp
Feb 26 10:58:09 host sshd[9738]: pam_sss(sshd:auth): received for user
ghopp: 17 (Failure setting user credentials)
Feb 26 10:58:09 host sshd[9736]: Accepted keyboard-interactive/pam for
ghopp from 2001:4ba0:ffff:138:1::1000 port 42676 ssh2
Feb 26 10:58:09 host sshd[9736]: pam_unix(sshd:session): session opened
for user ghopp by (uid=0)
Feb 26 10:58:09 host sshd[9740]: SSH: Server;Ltype: Kex;Remote:
2001:4ba0:ffff:138:1::1000-42676;Enc: aes128-ctr;MAC:
hmac-md5-etm at openssh.com;Comp: none


After that I am on the machine.

For me it looks like ssh accepts any password now.
As no TGT is involved into this I guess that this can also be
reproduced in a non kerberized environment.

regards
   Georg

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

--- Comment #8 from Georg Hopp <georg at steffers.org> ---
OK,

the problem was in my pam configuration. I made all password checking
modules sufficient and let the final pam_deny optional. After I changed
it to required everything works as expected.

Sorry about the confusion. I am always a little confused when
configuring pam.

So again, the patch fixed the issue for me and does not open a security
hole for me.

best regards
   Georg

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #9 from Damien Miller <djm at mindrot.org> ---
Patch applied; this will be in openssh-6.6

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #10 from Damien Miller <djm at mindrot.org> ---
Close all bugs left open from 6.6 and 6.7 releases.

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

Jakub Jelen <jjelen at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jjelen at redhat.com

--- Comment #11 from Jakub Jelen <jjelen at redhat.com> ---
It looks like I am late for the party, but this unfortunately does not
address the issue completely. For some reasons, the configuration can
look like this:

GSSAPIAuthentication no
Match User root
  GSSAPIAuthentication yes

and in this case, the caching mechanisms will not be triggered, the
separated child will try to load the data later and fail:

Program received signal SIGSYS, Bad system call.
[Switching to Thread 0x7f67e97f88c0 (LWP 9647)]
0x00007f67e4c3de39 in pthread_once () from /lib64/libpthread.so.0
(gdb) bt
#0  0x00007f67e4c3de39 in pthread_once () from /lib64/libpthread.so.0
#1  0x00007f67e3379b68 in krb5int_pthread_loaded () from
/lib64/libkrb5support.so.0
#2  0x00007f67e337a0f1 in k5_once () from /lib64/libkrb5support.so.0
#3  0x00007f67e74021e7 in gssint_mechglue_initialize_library () from
/lib64/libgssapi_krb5.so.2
#4  0x00007f67e74022b5 in gss_indicate_mechs () from
/lib64/libgssapi_krb5.so.2
#5  0x00005594c41f2e4f in ssh_gssapi_supported_oids (
    oidset=oidset at entry=0x5594c4490088 <supported_oids>) at
gss-serv.c:179
#6  0x00005594c41f2f55 in ssh_gssapi_prepare_supported_oids () at
gss-serv.c:82
#7  ssh_gssapi_test_oid_supported (ms=0x7ffc60dc75f0,
member=0x7ffc60dc7600, present=0x7ffc60dc75ec)
    at gss-serv.c:89
#8  0x00005594c41f23d8 in userauth_gssapi (authctxt=0x5594c48fe500) at
auth2-gss.c:127
#9  0x00005594c41e0b1c in input_userauth_request (type=<optimized out>,
seq=<optimized out>, 
    ctxt=0x5594c48fe500) at auth2.c:295
#10 0x00005594c42227a9 in ssh_dispatch_run
(ssh=ssh at entry=0x5594c49008c0, mode=mode at entry=0, 
    done=done at entry=0x5594c48fe500, ctxt=ctxt at entry=0x5594c48fe500) at
dispatch.c:119
#11 0x00005594c42227f9 in ssh_dispatch_run_fatal (ssh=0x5594c49008c0,
mode=mode at entry=0, 
    done=done at entry=0x5594c48fe500, ctxt=ctxt at entry=0x5594c48fe500) at
dispatch.c:140
#12 0x00005594c41dfde9 in do_authentication2
(authctxt=authctxt at entry=0x5594c48fe500) at auth2.c:175
#13 0x00005594c41d1ee7 in main (ac=<optimized out>, av=<optimized
out>)
at sshd.c:2191

Collin, can you confirm you can reproduce the same issue?

I can not think about sensible way around this without initializing the
kerberos library and loading the OIDs unconditionally.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #3168|                            |ok?
              Flags|                            |

--- Comment #12 from Damien Miller <djm at mindrot.org> ---
Created attachment 3168
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3168&action=edit
cache OIDs unconditionally

I can't think of any reason we can't prime the cache unconditionally.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |2852


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=2852
[Bug 2852] Tracking bug for OpenSSH 7.8 release
-- 
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=2107

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |2852
         Depends on|2852                        |


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=2852
[Bug 2852] Tracking bug for OpenSSH 7.8 release
-- 
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=2107

Jakub Jelen <jjelen at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|FIXED                       |---
             Status|CLOSED                      |REOPENED

--- Comment #13 from Jakub Jelen <jjelen at redhat.com> ---
(In reply to Damien Miller from comment #12)
> Created attachment 3168 [details]
> cache OIDs unconditionally
> 
> I can't think of any reason we can't prime the cache
unconditionally.
That is probably the only way with the downside of having some overhead
for non-GSSAPI mechanisms or potentially larger attack surface, but if
you are fine with this change, I would be glad to have this addressed
in the next release.

I will reopen the bug to make sure it will not get lost.

Thank you.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at dtucker.net
   Attachment #3168|ok?                         |ok?(dtucker at dtucker.net)
              Flags|                            |

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

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #3168|ok?(dtucker at dtucker.net)    |ok+
              Flags|                            |

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|REOPENED                    |RESOLVED
             Blocks|                            |2893

--- Comment #14 from Damien Miller <djm at mindrot.org> ---
Fix committed and will be in openssh-7.9 release


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=2893
[Bug 2893] Tracking bug for 7.9 release
-- 
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=2107

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #15 from Damien Miller <djm at mindrot.org> ---
Close RESOLVED bugs with the release of openssh-8.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.