[Dovecot] BUG: mishandling of username if it's a keyword?
Dec 14 14:33:03 test2 dovecot: auth: Debug: auth client connected (pid=24143) Dec 14 14:33:14 test2 dovecot: auth: Debug: client in: AUTH#0111#011PLAIN#011service=pop3#011secured#011session=D6dl6dDQdAAAAAAAAAAAAAAAAAAAAAAB#011lip=::1#011rip=::1#011lport=110#011rport=38004#011resp=<hidden> Dec 14 14:33:14 test2 dovecot: auth: Debug: static(home,::1,<D6dl6dDQdAAAAAAAAAAAAAAAAAAAAAAB>): lookup Dec 14 14:33:14 test2 dovecot: auth: Debug: client passdb out: OK#0111#011user=home Dec 14 14:33:14 test2 dovecot: auth: Debug: master in: REQUEST#0112033451009#01124143#0111#011243997dcca92c2dc1d1e401c78b4ea4f Dec 14 14:33:14 test2 dovecot: auth: Debug: master userdb out: USER#0112033451009#011uid=503#011gid=503#011home=/nfs/maildir/vmail/home#011mail_location=maildir:~/Maildir Dec 14 14:33:14 test2 dovecot: pop3-login: Login: user=<home>, method=PLAIN, rip=::1, lip=::1, mpid=24145, secured, session=<D6dl6dDQdAAAAAAAAAAAAAAAAAAAAAAB> Dec 14 14:33:14 test2 dovecot: pop3: Debug: Added userdb setting: mail_location=maildir:~/Maildir Dec 14 14:33:14 test2 dovecot: pop3(uid=503): Error: user uid=503: Couldn't drop privileges: User is missing UID (see mail_uid setting) Dec 14 14:33:14 test2 dovecot: pop3(uid=503): Error: Internal error occurred. Refer to server log for more information.
compared to:
Dec 14 14:37:25 test2 dovecot: pop3-login: Login: user=<home2>, method=PLAIN, rip=::1, lip=::1, mpid=24190, secured, session=<5Zdb+NDQdQAAAAAAAAAAAAAAAAAAAAAB> Dec 14 14:37:25 test2 dovecot: pop3: Debug: Added userdb setting: mail_location=maildir:~/Maildir Dec 14 14:37:25 test2 dovecot: pop3(home2): Debug: Effective uid=503, gid=503, home=/nfs/maildir/vmail/home2
userdb { args = uid=vmail gid=vmail home=/nfs/maildir/vmail/%u mail_location=maildir:~/Maildir driver = static }
This was tested on a static passdb/userdb on a test server as well as production. version 2.1.10. When I have time, I'll dig into it myself after an upgrade to 2.1.12.
Jack
Additional info by switching the home= and uid= settings in the config.
userdb { args = home=/nfs/maildir/vmail/%u uid=vmail gid=vmail mail_location=maildir:~/Maildir driver = static }
We got the effective id, but then home was unset and the user became the home setting. lol
Dec 14 15:56:20 test2 dovecot: auth: Debug: master userdb out: USER#0112586836993#011home=/nfs/maildir/vmail/home#011uid=503#011gid=503#011mail_location=maildir:~/Maildir Dec 14 15:56:20 test2 dovecot: pop3-login: Login: user=<home>, method=PLAIN, rip=::1, lip=::1, mpid=24686, secured, session=<jN2ZEtLQegAAAAAAAAAAAAAAAAAAAAAB> Dec 14 15:56:20 test2 dovecot: pop3: Debug: Added userdb setting: mail_location=maildir:~/Maildir Dec 14 15:56:20 test2 dovecot: pop3(home=/nfs/maildir/vmail/home): Debug: Effective uid=503, gid=503, home= Dec 14 15:56:20 test2 dovecot: pop3(home=/nfs/maildir/vmail/home): Debug: Namespace inbox: type=private, prefix=, sep=., inbox=yes, hidden=no, list=yes, subscriptions=yes location=maildir:~/Maildir Dec 14 15:56:20 test2 dovecot: pop3(home=/nfs/maildir/vmail/home): Error: user home=/nfs/maildir/vmail/home: Initialization failed: Namespace '': Home directory not set for user. Can't expand ~/ for mail root dir in: ~/Maildir Dec 14 15:56:20 test2 dovecot: pop3(home=/nfs/maildir/vmail/home): Error: Invalid user settings. Refer to server log for more information.
Jack
Dec 14 14:33:14 test2 dovecot: auth: Debug: master userdb out: USER#0112033451009#011uid=503#011gid=503#011home=/nfs/maildir/vmail/home#011mail_location=maildir:~/Maildir Dec 14 14:37:25 test2 dovecot: auth: Debug: master userdb out: USER#011477757441#011home2#011uid=503#011gid=503#011home=/nfs/maildir/vmail/home2#011mail_location=maildir:~/Maildir Dec 14 15:44:23 test2 dovecot: auth: Debug: master userdb out: USER#0113466592257#011uid=503#011gid=503#011home=/nfs/maildir/vmail/home#011mail_location=maildir:~/Maildir
Looking at the proper home2 account, it appears that the username "home" is being left out. This is definitely an issue with auth userdb.
This was on 2.1.12. I upgraded.
Jack
On 12/14/2012 10:00 AM, Jack Bates wrote:
Additional info by switching the home= and uid= settings in the config.
userdb { args = home=/nfs/maildir/vmail/%u uid=vmail gid=vmail mail_location=maildir:~/Maildir driver = static }
We got the effective id, but then home was unset and the user became the home setting. lol
Yes, it's a bug. Most importantly: I don't think this is a security hole, except maybe in some very specific installations. It only affects usernames that are the same as one of the "extra fields" in userdb. Such user needs to log in with a valid username and password before this happens. What happens is that when userdb sets the extra field, it thinks it's replacing an existing field and removes the username. So the username gets replaced by the next field. This often does mean that the user can log in using a wrong username (e.g. user is "uid=1000"), but there's really no way to set that to any specific username. So users can't read each others' mails. But because the username is different from expected, it could cause some confusion.
I was also a bit worried that it still could allow users to create such accounts for some webmail providers, but pretty much all of them use user@domain style account names, and those aren't affected. So practically no possibility of this affecting anyone where admin doesn't explicitly create such account.
I'll get this fixed when I have a bit of time. The fix isn't as easy as I'd like and it affects a large part of the authentication..
On 14.12.2012, at 18.04, Jack Bates wrote:
Dec 14 14:33:14 test2 dovecot: auth: Debug: master userdb out: USER#0112033451009#011uid=503#011gid=503#011home=/nfs/maildir/vmail/home#011mail_location=maildir:~/Maildir Dec 14 14:37:25 test2 dovecot: auth: Debug: master userdb out: USER#011477757441#011home2#011uid=503#011gid=503#011home=/nfs/maildir/vmail/home2#011mail_location=maildir:~/Maildir Dec 14 15:44:23 test2 dovecot: auth: Debug: master userdb out: USER#0113466592257#011uid=503#011gid=503#011home=/nfs/maildir/vmail/home#011mail_location=maildir:~/Maildir
Looking at the proper home2 account, it appears that the username "home" is being left out. This is definitely an issue with auth userdb.
This was on 2.1.12. I upgraded.
Jack
On 12/14/2012 10:00 AM, Jack Bates wrote:
Additional info by switching the home= and uid= settings in the config.
userdb { args = home=/nfs/maildir/vmail/%u uid=vmail gid=vmail mail_location=maildir:~/Maildir driver = static }
We got the effective id, but then home was unset and the user became the home setting. lol
It looks as if some things make extra passes. I'm still tracing it, but could we modify userdb_template_export to skip the user part?
It's interesting as I noticed that user=%u in a static config still ends up having an issue, which implies it was processed twice (once to home, and again to mess up).
My problem is that I am moving an existing userbase and my user "home" isn't going to be happy to change. lol
I'll keep looking. I know it has to be treated carefully given that USER can be changed and it will effect all userdb types. Currently I'm testing with both ldap w/ prefetch and static userdb.
Jack
On 12/14/2012 12:29 PM, Timo Sirainen wrote:
Yes, it's a bug. Most importantly: I don't think this is a security hole, except maybe in some very specific installations. It only affects usernames that are the same as one of the "extra fields" in userdb. Such user needs to log in with a valid username and password before this happens. What happens is that when userdb sets the extra field, it thinks it's replacing an existing field and removes the username. So the username gets replaced by the next field. This often does mean that the user can log in using a wrong username (e.g. user is "uid=1000"), but there's really no way to set that to any specific username. So users can't read each others' mails. But because the username is different from expected, it could cause some confusion.
I was also a bit worried that it still could allow users to create such accounts for some webmail providers, but pretty much all of them use user@domain style account names, and those aren't affected. So practically no possibility of this affecting anyone where admin doesn't explicitly create such account.
I'll get this fixed when I have a bit of time. The fix isn't as easy as I'd like and it affects a large part of the authentication..
On 14.12.2012, at 18.04, Jack Bates wrote:
Dec 14 14:33:14 test2 dovecot: auth: Debug: master userdb out: USER#0112033451009#011uid=503#011gid=503#011home=/nfs/maildir/vmail/home#011mail_location=maildir:~/Maildir Dec 14 14:37:25 test2 dovecot: auth: Debug: master userdb out: USER#011477757441#011home2#011uid=503#011gid=503#011home=/nfs/maildir/vmail/home2#011mail_location=maildir:~/Maildir Dec 14 15:44:23 test2 dovecot: auth: Debug: master userdb out: USER#0113466592257#011uid=503#011gid=503#011home=/nfs/maildir/vmail/home#011mail_location=maildir:~/Maildir
Looking at the proper home2 account, it appears that the username "home" is being left out. This is definitely an issue with auth userdb.
This was on 2.1.12. I upgraded.
Jack
On 12/14/2012 10:00 AM, Jack Bates wrote:
Additional info by switching the home= and uid= settings in the config.
userdb { args = home=/nfs/maildir/vmail/%u uid=vmail gid=vmail mail_location=maildir:~/Maildir driver = static }
We got the effective id, but then home was unset and the user became the home setting. lol
If you just want to quickly work around it, I think you could give "userdb" parameter to auth_stream_reply_init() which is TRUE for the userdb_reply and FALSE the passdb reply. Then in auth_stream_reply_remove() and _find() and _exists() skip the first parameter if userdb=TRUE. Hmm. That's probably what I'll do for v2.1, and a bit larger cleanup for v2.2.
On 14.12.2012, at 20.37, Jack Bates wrote:
It looks as if some things make extra passes. I'm still tracing it, but could we modify userdb_template_export to skip the user part?
It's interesting as I noticed that user=%u in a static config still ends up having an issue, which implies it was processed twice (once to home, and again to mess up).
My problem is that I am moving an existing userbase and my user "home" isn't going to be happy to change. lol
I'll keep looking. I know it has to be treated carefully given that USER can be changed and it will effect all userdb types. Currently I'm testing with both ldap w/ prefetch and static userdb.
Jack
On 12/14/2012 12:29 PM, Timo Sirainen wrote:
Yes, it's a bug. Most importantly: I don't think this is a security hole, except maybe in some very specific installations. It only affects usernames that are the same as one of the "extra fields" in userdb. Such user needs to log in with a valid username and password before this happens. What happens is that when userdb sets the extra field, it thinks it's replacing an existing field and removes the username. So the username gets replaced by the next field. This often does mean that the user can log in using a wrong username (e.g. user is "uid=1000"), but there's really no way to set that to any specific username. So users can't read each others' mails. But because the username is different from expected, it could cause some confusion.
I was also a bit worried that it still could allow users to create such accounts for some webmail providers, but pretty much all of them use user@domain style account names, and those aren't affected. So practically no possibility of this affecting anyone where admin doesn't explicitly create such account.
I'll get this fixed when I have a bit of time. The fix isn't as easy as I'd like and it affects a large part of the authentication..
On 14.12.2012, at 18.04, Jack Bates wrote:
Dec 14 14:33:14 test2 dovecot: auth: Debug: master userdb out: USER#0112033451009#011uid=503#011gid=503#011home=/nfs/maildir/vmail/home#011mail_location=maildir:~/Maildir Dec 14 14:37:25 test2 dovecot: auth: Debug: master userdb out: USER#011477757441#011home2#011uid=503#011gid=503#011home=/nfs/maildir/vmail/home2#011mail_location=maildir:~/Maildir Dec 14 15:44:23 test2 dovecot: auth: Debug: master userdb out: USER#0113466592257#011uid=503#011gid=503#011home=/nfs/maildir/vmail/home#011mail_location=maildir:~/Maildir
Looking at the proper home2 account, it appears that the username "home" is being left out. This is definitely an issue with auth userdb.
This was on 2.1.12. I upgraded.
Jack
On 12/14/2012 10:00 AM, Jack Bates wrote:
Additional info by switching the home= and uid= settings in the config.
userdb { args = home=/nfs/maildir/vmail/%u uid=vmail gid=vmail mail_location=maildir:~/Maildir driver = static }
We got the effective id, but then home was unset and the user became the home setting. lol
participants (2)
-
Jack Bates
-
Timo Sirainen