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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
