[Bug 1088136] [NEW] AUTH cannot handle a request with an initial-response over 2048 bytes (GSSAPI-related)

[urusha]

Public bug reported:

smtp_cmd_buffer_size is currently 2048 bytes.  2048 bytes is not sufficient for
clients that send an AUTH with an initial-response for GSSAPI when Windows
Kerberos tickets are used that contain a PAC -- as of Windows 2003, the maximum
ticket size is 12000 bytes.

MUAs that use AUTH GSSAPI without an initial-response are not impacted by the
2048 limit, since the remainder of the SASL session is handled by auth_get_data
in Exim, which uses big_buffer and has sufficient space to process large
Kerberos tickets.

Thunderbird will always send an AUTH GSSAPI with an initial-response, which
makes it subject to the 2048 byte limit.  A large Kerberos ticket will easily
surpass 2048 bytes when base64-encoded, causing the AUTH to fail.

RFC 4954 recommends 12288 bytes as a line limit to handle AUTH.  For a base64
encoded max-size Windows Kerberos ticket, at least 16000 bytes are needed.

This bug is fixed upstream (4.77). It would be nice to backport it to
precise.

[Impact]
smtp_cmd_buffer_size is currently 2048 bytes.  2048 bytes is not sufficient for
clients that send an AUTH with an initial-response for GSSAPI when Windows
Kerberos tickets are used that contain a PAC. For a base64
encoded max-size Windows Kerberos ticket, at least 16000 bytes are needed.

[Test Case]
1. Configure exim4 to use GSSAPI auth.
2. Configure thunderbird to use GSSAPI smtp auth on windows xp/vista/7/2003/2008.
3. Auth will always fail.

[Regression Potential]
The fix for this bug is one-line-patch applied to upstream (4.77) more than year ago, so it already has got sufficient testing.

** Affects: exim
     Importance: Unknown
         Status: Unknown

** Affects: exim4 (Ubuntu)
     Importance: Undecided
         Status: New

** Package changed: heimdal (Ubuntu) => exim4 (Ubuntu)

** Description changed:

  smtp_cmd_buffer_size is currently 2048 bytes.  2048 bytes is not sufficient for
  clients that send an AUTH with an initial-response for GSSAPI when Windows
  Kerberos tickets are used that contain a PAC -- as of Windows 2003, the maximum
  ticket size is 12000 bytes.
  
  MUAs that use AUTH GSSAPI without an initial-response are not impacted by the
  2048 limit, since the remainder of the SASL session is handled by auth_get_data
  in Exim, which uses big_buffer and has sufficient space to process large
  Kerberos tickets.
  
  Thunderbird will always send an AUTH GSSAPI with an initial-response, which
  makes it subject to the 2048 byte limit.  A large Kerberos ticket will easily
  surpass 2048 bytes when base64-encoded, causing the AUTH to fail.
  
  RFC 4954 recommends 12288 bytes as a line limit to handle AUTH.  For a base64
- encoded max-size Windows Kerberos ticket, at least 16000 bytes are needed. 
+ encoded max-size Windows Kerberos ticket, at least 16000 bytes are needed.
  
- This bug is fixed upstream (4.77).
+ This bug is fixed upstream (4.77). It would be nice to backport it to
+ precise.
  
  [Impact]
  smtp_cmd_buffer_size is currently 2048 bytes.  2048 bytes is not sufficient for
  clients that send an AUTH with an initial-response for GSSAPI when Windows
  Kerberos tickets are used that contain a PAC. For a base64
  encoded max-size Windows Kerberos ticket, at least 16000 bytes are needed.
  
  [Test Case]
  1. Configure exim4 to use GSSAPI auth.
  2. Configure thunderbird to use GSSAPI smtp auth on windows xp/vista/7/2003/2008.
  3. Auth will always fail.
  
  [Regression Potential]
  The fix for this bug is one-line-patch applied to upstream (4.77) more than year ago, so it already has got sufficient testing.

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to exim4 in Ubuntu.
https://bugs.launchpad.net/bugs/1088136

Title:
  AUTH cannot handle a request with an initial-response over 2048 bytes
  (GSSAPI-related)

To manage notifications about this bug go to:
https://bugs.launchpad.net/exim/+bug/1088136/+subscriptions