FW: remote root qmail-pop with vpopmail advisory and exploit with patch
Saw this on buqtraq, may be interesting for those running vpopmail/vchkpw Robert S. Wojciechowski Jr. [EMAIL PROTECTED] -Original Message- From: what's your style? [mailto:[EMAIL PROTECTED]] Sent: Saturday, January 22, 2000 7:05 PM To: [EMAIL PROTECTED] Subject: remote root qmail-pop with vpopmail advisory and exploit with patch w00w00 Security Advisory - http://www.w00w00.org/ Title: qmail-pop3d with vpopmail/vchkpw Platforms: Any Discovered: 7th January, 2000 Local: Yes. Remote: Yes. Author: K2 [EMAIL PROTECTED] Vendor Status: Notified. Last Updated: N/A 1. Overview qmail-pop3d may pass an overly long command argument to it's password authentication service. When vpopmail is used to authenticate user information a remote attacker may compromise the privilege level that vpopmail is running, naturally root. 2. Background It is Qmail's nonconformance to the pop3 specification that allows this bug to manifest itself. qmail-pop3d trust's that it's checkpassword mechanism will support the same undocumented "features" as it dose, it is this extra functionality that breaks vpopmail and RFC1939. From RFC1939 [Post Office Protocol - Version 3] Commands in the POP3 consist of a caseinsensitive keyword, possibly followed by one or more arguments. All commands are terminated by a CRLF pair. Keywords and arguments consist of printable ASCII characters. Keywords and arguments are each separated by a single SPACE character. Keywords are three or four characters long. Each argument may be up to 40 characters long. From BLURB3 (qmail-1.03) POP3 service (qmail-popup, qmail-pop3d): * RFC 1939 * UIDL support * TOP support * APOP hook * modular password checking (checkpassword, available separately) 3. Issue qmail-pop3d claims compliance to RFC1939, however this is not the case qmail breaks that compliance by allowing overly long argument lengths to be processed. qmail then passes control to a process without documenting this added bug/feature. 4. Impact A remote attacker may attain the privilege level of the authentication module. Sample exploit code can be found at http://www.ktwo.ca/security.html 5. Recommendation Impose the 40 character limitation specified by RFC1939 into qmail. Apply qmail-popup patch http://www.ktwo.ca/c/qmail-popup-patch 6. References RFC1939 qmail-1.03/BLURB3 K2 www.ktwo.ca / [EMAIL PROTECTED]
supervise/svscan/and qmail logging
Hello, I am using the daemontools 0.61, and supervise on qmail, qmail-popup, and qmail-smtpd. Right now, I just start a normal supervise process to watch over those. I wanted to do logging for the qmail-popup and qmail-smtpd daemons, and created an SVC/log dir, set the sticky bit, etc. My question is, do I have to start the two supervise processes (one for SVC, and one for SVC/log) with svscan, or can I do it manually? I want to be able to restart the services, take down supervise for that service, etc without having to wait 1 minute for svscan to bring it back up. How can I do this without breaking the pipe between the service and the logger? Seems like a pain! Robert S. Wojciechowski Jr. [EMAIL PROTECTED] PGP: 0xF2CA68F2 - http://www.wojo.com/pgpkeys/robertw.asc
RE: Supervise and qmail/tcpserver
Turns out that I needed to start tcpserver with exec. Then all went well. Robert S. Wojciechowski Jr. [EMAIL PROTECTED] PGP: 0xF2CA68F2 - http://www.wojo.com/pgpkeys/robertw.asc -Original Message- From: Dave Sill [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 07, 1999 9:12 AM To: [EMAIL PROTECTED] Subject: Re: Supervise and qmail/tcpserver "Robert Wojciechowski Jr." [EMAIL PROTECTED] wrote: # svc -dx /var/supervise/qmail/qmail-smtpd doesn't kill the tcpserver process, but supervise does die. Why? Don't know. Trace the supervise process with your OS's system call tracer to see where/why it's dying. -Dave
Supervise and qmail/tcpserver
I am having a problem with supervise and tcpserver with the qmail-smtpd and qmail-popup modules. I start supervise like so: /usr/local/bin/supervise /var/supervise/qmail/qmail-smtpd and /var/supervise/qmail/qmail-smtpd/run contains: #!/bin/sh QMAILDUID=`id -u qmaild` NOFILESGID=`id -g qmaild` /usr/local/bin/tcpserver \ -x/etc/tcprules.d/qmail-smtpd.cdb \ -u$QMAILDUID -g$NOFILESGID \ 0 smtp \ /var/qmail/bin/qmail-smtpd 21 Everything starts fine, but trying to kill it with: # svc -dx /var/supervise/qmail/qmail-smtpd doesn't kill the tcpserver process, but supervise does die. Why? Thanks in advance, Robert S. Wojciechowski Jr. [EMAIL PROTECTED] PGP: 0xF2CA68F2 - http://www.wojo.com/pgpkeys/robertw.asc
qmail-smtpd /w rblsmtpd causing load avg 9/9/9
Hello, I am using qmail from tcpserver, with the line: echo -n "(qmail-smtpd via tcpserver) " supervise /var/qmail/supervise/tcpserver-qmail-smtpd \ /usr/local/bin/tcpserver -c 10 -u $QMAILDUID -g $NOFILESGID \ -x /etc/tcprules.d/qmail-smtpd.cdb \ 0 smtp \ /usr/local/bin/rblsmtpd -rrbl.maps.vix.com \ /usr/local/bin/rblsmtpd -rdul.maps.vix.com \ /var/qmail/bin/qmail-smtpd 21 Everything seems fine, and the machine is humming along, until I notice a load average of 9/9/9! I was tracing it down, but ps, top, etc did not show ANYTHING using CPU time.. but what I did notice from 'ps ax' was: 24408 ? S0:00 /usr/local/bin/rblsmtpd -rrbl.maps.vix.com /usr/local/bin/r . (3 more) 24431 ? D0:00 /usr/local/bin/rblsmtpd -rdul.maps.vix.com /var/qmail/bin/q 24432 ? D0:00 /usr/local/bin/rblsmtpd -rdul.maps.vix.com /var/qmail/bin/q 24434 ? D0:00 /usr/local/bin/rblsmtpd -rrbl.maps.vix.com /usr/local/bin/r . (2 more) 24453 ? D0:00 /usr/local/bin/rblsmtpd -rrbl.maps.vix.com /usr/local/bin/r I killed these, and my load avg went back down. What caused this? Thanks, Robert
Qmail '|forward user-$DEFAULT' problem with ezmlm
Hello, I have my setup almost complete! Phew. Just a problem with forwarding. I have the following setup: - control/me mail.host.com - control/virtualdomains: domain.com:alias-domain - alias/.qmail-domain-user localuser - alias/.qmail-domain-user-default |forward localuser-$DEFAULT Ok, I setup ezmlm, and I receive an error on a send to [EMAIL PROTECTED]: [EMAIL PROTECTED]: ezmlm-manage: fatal: I do not accept messages at this address (#5.1.1) If I put "mail.host.com" into my ~localuser/list/inhost and it works. But I do not want to have each list, and each user to have to do this! Why is it being rewritten to [EMAIL PROTECTED] ? I want to keep it at [EMAIL PROTECTED] Any solutions? Robert S. Wojciechowski Jr. [EMAIL PROTECTED]
RE: Qmail '|forward user-$DEFAULT' problem with ezmlm
Is there any other way to handle this without using users/assign? (with standard .qmail files) Perhaps another forward program (a lower level one, if one exists). I wonder if that is even possible. Thank for the help so far. Robert S. Wojciechowski Jr. [EMAIL PROTECTED] -Original Message- From: Harald Hanche-Olsen [mailto:[EMAIL PROTECTED]] Sent: Friday, February 26, 1999 2:49 AM To: [EMAIL PROTECTED] Subject: Re: Qmail '|forward user-$DEFAULT' problem with ezmlm - "Robert Wojciechowski Jr." [EMAIL PROTECTED]: | - control/me | mail.host.com | | - control/virtualdomains: | domain.com:alias-domain | | - alias/.qmail-domain-user | localuser | | - alias/.qmail-domain-user-default | |forward localuser-$DEFAULT | | Ok, I setup ezmlm, and I receive an error on a send to | [EMAIL PROTECTED]: | | [EMAIL PROTECTED]: | ezmlm-manage: fatal: I do not accept messages at this address (#5.1.1) | | If I put "mail.host.com" into my ~localuser/list/inhost and it | works. But I do not want to have each list, and each user to have | to do this! | | Why is it being rewritten to [EMAIL PROTECTED] ? It's just how your virtualdomains setup works: By forwarding to the new domain. | I want to keep it at [EMAIL PROTECTED] | | Any solutions? You could employ the users/assign mechanism instead of files in ~alias. If you cause the following to be in users/assign: =domain-user:user:123:456:/home/user::: +domain-user-:user:123:456:/home/user:-:: (replace 123:456 by the user's uid:gid and /home/user by the user's real home dir) and remember to run qmail-newu, then the mail will be delivered directly. You will want to write a script that does this automatically, of course. - Harald
Bug? Alias problem.
I have my main mail server name in control/me, and no other files except virtualhosts and rcpthosts (removed defaultdomain, locals, plusdomain for my no default host setup). I have the following .qmail files in ~/alias: .qmail-domain-root // for domain.com .qmail-anotherdom-root // for anotherdom.com domain.com is the name of the mail server (mail.domain.com located in control/me) Ok, mail to [EMAIL PROTECTED] works as expected. But mail to [EMAIL PROTECTED] bounces! Why? I have it handled here I thought. It must have something to do with the fact that my control/me file says "mail.domain.com", and it messes up the .qmail-domain-root file. Robert S. Wojciechowski Jr. [EMAIL PROTECTED]
Virtual Domains Setup
Hello, I want to have the following setup: I have a server that I want to not to have any e-mail setup by default. I just want e-mail for the virtual domains. In other words, I don't want the users and accounts on my box to have e-mail by default, only if I allow them to via a virtual domain (all others will bounce). I have the setup almost up, by putting: - control/defaultdomain 127.0.0.1 - control/locals localhost 127.0.0.1 - control/me 127.0.0.1 Then I have all my domains in control/rcpthosts and control/virtualdomains. I had to make it 127.0.0.1 instead of localhost because qmail detects if there is no dot in an e-mail, and appends default domain (resulting in localhost.localhost). When I send mail to just "robertw", it appends 127.0.0.1, and mail processes. When I send mail to [EMAIL PROTECTED], it forwards it to [EMAIL PROTECTED] because of the qmail file. So all seems well there. The problem is when you look at the SMTP greeting, it says 127.0.0.1. I changed that with the control/smtpgreeting. But now when a bounce message is sent, it says it came from 127.0.0.1... which is not what I want. This happens elsewhere too. Anyways, I am even on the right path to getting this set up correctly? I want a dummy server, that is not really a host in and of itself. Thanks, Robert S. Wojciechowski Jr. [EMAIL PROTECTED]
Ezmlm with alias user on virtual domains?
Has anyone done this? I have a line such as: Mydomain.com:alias-mydomain In my virtualusers... then in the ~/alias directory, I have normal .qmail-mydomain* files. Now I want to setup ezmlm on that domain. Do I have to make a controlling user besides alias for ezmlm? What I need I suppose is a way to forward all mail to alias-mydomain to user-mydomain preserving the extension! So: alias-user -list-blah will be forwarded to user-list-blah. Is there a special forward type that will rewrite and forward for .qmail files? I need this because one person does not control a virtual domain here, and I want each user to be able to make their own lists. Robert S. Wojciechowski Jr. [EMAIL PROTECTED]
RE: Virtual Domains Setup
Ok, I have it working well now, just one quirk (dunno if it's a bug). I have my main mail server name in control/me, and no other files except virtualhosts and rcpthosts. I have the following .qmail files: .qmail-domain-root // for domain.com .qmail-anotherdom-root // for anotherdom.com domain.com is the name of the mail server (mail.domain.com located in control/me) Ok, mail to [EMAIL PROTECTED] works as expected. But mail to [EMAIL PROTECTED] bounces! Why? I have it handled here I thought. It must have something to do with the fact that my control/me file says "mail.domain.com". Thanks. Robert S. Wojciechowski Jr. [EMAIL PROTECTED] -Original Message- From: Stefan Paletta [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 23, 1999 3:15 PM To: Robert Wojciechowski Jr. Cc: [EMAIL PROTECTED] Subject: RE: Virtual Domains Setup Robert Wojciechowski Jr. wrote/schrieb/scribsit: - control/defaultdomain 127.0.0.1 - control/locals localhost 127.0.0.1 - control/me 127.0.0.1 Anyways, I am even on the right path to getting this set up correctly? I want a dummy server, that is not really a host in and of itself. The box _must_ have a hostname after all. Stick it into me, delete any other config files apart from virtualdomains and rcpthosts and you're set. Stefan
