** Description changed:

  [ Impact ]
  
-  * An explanation of the effects of the bug on users and
+ The gssapi-keyex authentication mechanism has been inadvertently broken
+ in openssh. It comes from a distro patch[1], and while the patch still
+ applied, it was no longer correct.
  
-  * justification for backporting the fix to the stable release.
+ Without the fix, sshd will fail to start if gssapi-keyex is listed in
+ the AuthenticationMethods of the server, and if not, sshd will still
+ start, but gssapi-keyex will not be available.
  
-  * In addition, it is helpful, but not required, to include an
-    explanation of how the upload fixes this bug.
  
  [ Test Plan ]
  
-  * detailed instructions how to reproduce the bug
+ This update adds a new autopkgtest to the package, which tests both
+ gssapi-with-mic ("normal" gssapi, which is not affected by this bug),
+ and gssapi-keyex, which, before this update, does not work.
  
-  * these should allow someone who is not familiar with the affected
-    package to reproduce the bug and verify that the updated package fixes
-    the problem.
+ The test plan is to run the new ssh-gssapi autopkgtest and verify it
+ succeeds.
  
-  * if other testing is appropriate to perform before landing this update,
-    this should also be described here.
  
  [ Where problems could occur ]
  
-  * Think about what the upload changes in the software. Imagine the change is
-    wrong or breaks something else: how would this show up?
+ ssh is a critical piece of infrastructure, and problems with it could
+ have catastrophic consequences. The service itself has a test command
+ before it starts up to verify the syntax of the config file, but that
+ test is not applied on shutdown, so a restart with an invalid config
+ file could still leave sshd dead.
  
-  * It is assumed that any SRU candidate patch is well-tested before
-    upload and has a low overall risk of regression, but it's important
-    to make the effort to think about what ''could'' happen in the
-    event of a regression.
+ The patch adds a change to an authentication structure, but that change
+ is already present in the upstream code, and we are just updating it in
+ the new gssapi-keyex code (introduced by the distro[1] patch, already
+ present). Therefore, mistakes here should manifest themselves just in
+ the gssapi-keyex code, which wasn't working anyway. Effectively, though,
+ we are enabling a new authentication mechanism in sshd, one that was not
+ supposed to have been removed, but was broken by mistake.
  
-  * This must '''never''' be "None" or "Low", or entirely an argument as to why
-    your upload is low risk.
- 
-  * This both shows the SRU team that the risks have been considered,
-    and provides guidance to testers in regression-testing the SRU.
  
  [ Other Info ]
-  
-  * Anything else you think is useful to include
-  * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
-  * and address these questions in advance
  
+ The fact no-one noticed this problem for more than two years could be
+ telling that there are not many users of this authentication mechanism
+ out there. The same applies to debian: it has also been broken for a
+ while there. Maybe we should drop it for future ubuntu releases, since
+ upstream refuses to take it in.
  
  [ Original Description ]
  
- 
- The Authmethod struct now have 4 entries but the initialization of the 
method_gsskeyex in the debian/patches/gssapi.patch only have 3 entries.
+ The Authmethod struct now have 4 entries but the initialization of the
+ method_gsskeyex in the debian/patches/gssapi.patch only have 3 entries.
  
  The struct was changed in upstream commit 
dbb339f015c33d63484261d140c84ad875a9e548 as
  ===
  @@ -104,7 +104,8 @@ struct Authctxt {
  
   struct Authmethod {
          char    *name;
  -       int     (*userauth)(struct ssh *);
  +       char    *synonym;
  +       int     (*userauth)(struct ssh *, const char *);
          int     *enabled;
   };
  
  ===
  
  The incorrect code does
  ===
  +Authmethod method_gsskeyex = {
  +       "gssapi-keyex",
  +       userauth_gsskeyex,
  +       &options.gss_authentication
  +};
  ===
  but should have a NULL between the "gssapi-keyex" string and userauth_gsskeyex
  
  This is now (change from Focal) causing gssapi-keyex to be disabled.
  
  ===
  lsb_release -rd
  Description:  Ubuntu 22.04.3 LTS
  Release:      22.04
  
  ===
  apt-cache policy openssh-server
  openssh-server:
    Installed: 1:8.9p1-3ubuntu0.6
    Candidate: 1:8.9p1-3ubuntu0.6
    Version table:
   *** 1:8.9p1-3ubuntu0.6 500
          500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu 
jammy-updates/main amd64 Packages
          500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu 
jammy-security/main amd64 Packages
          100 /var/lib/dpkg/status
       1:8.9p1-3 500
          500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu jammy/main 
amd64 Packages
  
  ===

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/2053146

Title:
  openssh 8.9p1 for Jammy auth2-gss patch for gssapi-keyex method is
  slightly wrong

Status in openssh package in Ubuntu:
  In Progress
Status in openssh source package in Jammy:
  In Progress
Status in openssh source package in Mantic:
  In Progress
Status in openssh source package in Noble:
  In Progress

Bug description:
  [ Impact ]

  The gssapi-keyex authentication mechanism has been inadvertently
  broken in openssh. It comes from a distro patch[1], and while the
  patch still applied, it was no longer correct.

  Without the fix, sshd will fail to start if gssapi-keyex is listed in
  the AuthenticationMethods of the server, and if not, sshd will still
  start, but gssapi-keyex will not be available.

  
  [ Test Plan ]

  This update adds a new autopkgtest to the package, which tests both
  gssapi-with-mic ("normal" gssapi, which is not affected by this bug),
  and gssapi-keyex, which, before this update, does not work.

  The test plan is to run the new ssh-gssapi autopkgtest and verify it
  succeeds.

  
  [ Where problems could occur ]

  ssh is a critical piece of infrastructure, and problems with it could
  have catastrophic consequences. The service itself has a test command
  before it starts up to verify the syntax of the config file, but that
  test is not applied on shutdown, so a restart with an invalid config
  file could still leave sshd dead.

  The patch adds a change to an authentication structure, but that
  change is already present in the upstream code, and we are just
  updating it in the new gssapi-keyex code (introduced by the distro[1]
  patch, already present). Therefore, mistakes here should manifest
  themselves just in the gssapi-keyex code, which wasn't working anyway.
  Effectively, though, we are enabling a new authentication mechanism in
  sshd, one that was not supposed to have been removed, but was broken
  by mistake.

  
  [ Other Info ]

  The fact no-one noticed this problem for more than two years could be
  telling that there are not many users of this authentication mechanism
  out there. The same applies to debian: it has also been broken for a
  while there. Maybe we should drop it for future ubuntu releases, since
  upstream refuses to take it in.

  [ Original Description ]

  The Authmethod struct now have 4 entries but the initialization of the
  method_gsskeyex in the debian/patches/gssapi.patch only have 3
  entries.

  The struct was changed in upstream commit 
dbb339f015c33d63484261d140c84ad875a9e548 as
  ===
  @@ -104,7 +104,8 @@ struct Authctxt {

   struct Authmethod {
          char    *name;
  -       int     (*userauth)(struct ssh *);
  +       char    *synonym;
  +       int     (*userauth)(struct ssh *, const char *);
          int     *enabled;
   };

  ===

  The incorrect code does
  ===
  +Authmethod method_gsskeyex = {
  +       "gssapi-keyex",
  +       userauth_gsskeyex,
  +       &options.gss_authentication
  +};
  ===
  but should have a NULL between the "gssapi-keyex" string and userauth_gsskeyex

  This is now (change from Focal) causing gssapi-keyex to be disabled.

  ===
  lsb_release -rd
  Description:  Ubuntu 22.04.3 LTS
  Release:      22.04

  ===
  apt-cache policy openssh-server
  openssh-server:
    Installed: 1:8.9p1-3ubuntu0.6
    Candidate: 1:8.9p1-3ubuntu0.6
    Version table:
   *** 1:8.9p1-3ubuntu0.6 500
          500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu 
jammy-updates/main amd64 Packages
          500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu 
jammy-security/main amd64 Packages
          100 /var/lib/dpkg/status
       1:8.9p1-3 500
          500 http://faiserver.hpc2n.umu.se/mirrors/ubuntu/ubuntu jammy/main 
amd64 Packages

  ===

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2053146/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to