Bug#471563: After the first 'id' command is issues Cyrus IMAPD always returns an error

[Dan White]

> Package: cyrus-imapd-2.2
> Version: 2.2.13-10
> Severity: important
> 
> I was testing the Zimbra Desktop IMAP client against my Cyrus server and
> found what I thought to be a bug in that client.  On further
> investigation I believe this is a bug in the Cyrus IMAPD component; the
> following is from the original bug:
> 
> ] nc rimspace.net 143
> * OK anu Cyrus IMAP4 v2.2.13-Debian-2.2.13-10 server ready
> a0 capability
> * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS NAMESPACE 
> UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT 
> THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE IDLE STARTTLS
> a0 OK Completed
> a1 id ("vendor" "Zimbra" "os" "Linux" "os-version" "12")
> * ID ("name" "Cyrus IMAPD" "version" "v2.2.13-Debian-2.2.13-10 2006/11/13 16:17:53" "vendor" "Project Cyrus" "support-url" "http://asg.web.cmu.edu/cyrus" "os" "Linux" "os-version" "2.6.18-ovz-028stab051.1" "environment" "Built w/ Cyrus SASL 2.1.22; Running w/Cyrus SASL 2.1.22; Built w/Sleepycat Software: Berkeley DB 4.2.52: (December  3, 2003); Running w/Sleepycat Software: Berkeley DB 4.2.52: (December  3, 2003); Built w/OpenSSL 0.9.8c 05 Sep 2006; Running w/ OpenSSL 0.9.8c 05 Sep 2006; CMU Sieve 2.2; TCP Wrappers; NET-SNMP; mmap = shared; lock = fcntl; nonblock = fcntl; idle = poll")
> a1 OK Completed
> a2 id ("vendor" "zimbra")
> a2 NO Only one Id allowed in non-authenticated state
> a3 logout
> * BYE LOGOUT received
> a3 OK Completed
> ] nc rimspace.net 143
> * OK anu Cyrus IMAP4 v2.2.13-Debian-2.2.13-10 server ready
> a4 id ("vendor" "zimbra")
> a4 NO Only one Id allowed in non-authenticated state
> a5 logout
> * BYE LOGOUT received
> a5 OK Completed
> 
> So, it looks like /any/ id command after the first returns the same state.
> 
> How about this...
> 
> ] nc rimspace.net 143
> * OK anu Cyrus IMAP4 v2.2.13-Debian-2.2.13-10 server ready
> a0 login daniel "XXXXXXXXXX"
> a0 OK User logged in
> a1 logout
> * BYE LOGOUT received
> a1 OK Completed
> ] nc rimspace.net 143
> * OK anu Cyrus IMAP4 v2.2.13-Debian-2.2.13-10 server ready
> a0 id ("vendor" "Zimbra")
> a0 NO Only one Id allowed in non-authenticated state
> a1 logout
> * BYE LOGOUT received
> a1 OK Completed
> 
> ...which makes it look like an upstream bug in Cyrus IMAP where any ID
> command will result in that error to any subsequent ID command or, at least, where
> that happens iff you don't authenticate correctly the first time.
> 
> While the Zimbra client should probably cope with the failure of the id
> command it is not reasonable, I think, that any user can cause ID
> commands to fail globally for all other users.

I confirmed that this happens with 2.2.13-17, and also with an undebianized
2.3.16.

The issue is that if subsequent connections come in to the same imapd
process and no other users have authenticated against that imapd process,
then subsequent ID commands will receive the 'NO Only one Id allowed in
non-authenticated state' error, until either a new imapd process is fired
up, or until an authentication happens.

The ID command is governed by RFC 2971, which states:

   7. Security Considerations
   ...
   Since this command includes arbitrary data and does not require the
   user to authenticate, server implementations are cautioned to guard
   against an attacker sending arbitrary garbage data in order to fill
   up the ID log.  In particular, if a server naively logs each ID
   command to disk without inspecting it, an attacker can simply fire up
   thousands of connections and send a few kilobytes of random data.
   Servers have to guard against this.  Methods include truncating
   abnormally large responses; collating responses by storing only a
   single copy, then keeping a counter of the number of times that
   response has been seen; keeping only particularly interesting parts
   of responses; and only logging responses of users who actually log
   in.


This 'functionality' may be Cyrus's way of circumventing a denial of
service attack by a string of unauthenticated users.

-- 
Dan White