Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. DBMail>
  3. dev
WARNING SECURITY FLAW IN IMAPSERVER
eelco at ic-s
Jul 25, 2003, 1:46 PM
Post #1 of 4 (909 views)
Permalink
Hi All,

A few hours ago i received an e-mail message from Timo Sirainen (i
attached the message) regarding a dangerous security bug in the dbmail
imap daemon.
Roel just fixed up 'quick-fix' patches (attached with this message) for
this security bug since quite a lot of people are running the imap
server in production.

Please keep in mind that this doesn't take care of the whole problem.
It fixes the possibility of inserting SQL during the authentication
proces. An authenticated user
can still inject SQL into normal imap commands.

Fixing of the remainders of these problems and other problems as noted
in Timo Sirainen's message will be checked and fixed next monday.

CVS also has an updates version.

Good luck!

Eelco

> From: Timo Sirainen <tss@iki.fi>
> Date: vri jul 25, 2003 18:34:06 Europe/Amsterdam
> To: bug@dbmail.org
> Subject: dbmail 1.1 sql injections
>
> Looks like you've done nothing to prevent them. For example in login
> user name and mailbox names. Maybe elsewhere, didn't look enough. For
> example:
>
> x login "cras'; update users set passwd = 'bar' where userid = 'cras';
> select user_idnr, passwd, encryption_type FROM users WHERE userid =
> 'cras" "bar"
> x OK LOGIN completed
>
> Other things you might want to fix:
>
> strncpy() calls in build_imap_search() doesn't leave space for
> trailing \0.
>
> Handling literals in build_args_array_ext() doesn't limit the literal
> size in any way. So user could just make the server allocate as much
> memory as it wants to. Also you don't check if fgetc() returns -1, so
> user can just given literal size of 2GB and disconnect, and server
> will fill the memory with -1. And you might want to look at the
> literal stuff in
> http://irccrew.org/~cras/security/advisories/imap-clients.txt,
> although your server currently isn't vulnerable to it because you're
> using signed integers for cnt/quotedSize.

Attached Files:

WARNING SECURITY FLAW IN IMAPSERVER [ In reply to ]
eelco at ic-s
Jul 25, 2003, 1:46 PM
Post #2 of 4 (872 views)
Permalink
Hi All,

A few hours ago i received an e-mail message from Timo Sirainen (i
attached the message) regarding a dangerous security bug in the dbmail
imap daemon.
Roel just fixed up 'quick-fix' patches (attached with this message) for
this security bug since quite a lot of people are running the imap
server in production.

Please keep in mind that this doesn't take care of the whole problem.
It fixes the possibility of inserting SQL during the authentication
proces. An authenticated user
can still inject SQL into normal imap commands.

Fixing of the remainders of these problems and other problems as noted
in Timo Sirainen's message will be checked and fixed next monday.

CVS also has an updates version.

Good luck!

Eelco

> From: Timo Sirainen <tss@iki.fi>
> Date: vri jul 25, 2003 18:34:06 Europe/Amsterdam
> To: bug@dbmail.org
> Subject: dbmail 1.1 sql injections
>
> Looks like you've done nothing to prevent them. For example in login
> user name and mailbox names. Maybe elsewhere, didn't look enough. For
> example:
>
> x login "cras'; update users set passwd = 'bar' where userid = 'cras';
> select user_idnr, passwd, encryption_type FROM users WHERE userid =
> 'cras" "bar"
> x OK LOGIN completed
>
> Other things you might want to fix:
>
> strncpy() calls in build_imap_search() doesn't leave space for
> trailing \0.
>
> Handling literals in build_args_array_ext() doesn't limit the literal
> size in any way. So user could just make the server allocate as much
> memory as it wants to. Also you don't check if fgetc() returns -1, so
> user can just given literal size of 2GB and disconnect, and server
> will fill the memory with -1. And you might want to look at the
> literal stuff in
> http://irccrew.org/~cras/security/advisories/imap-clients.txt,
> although your server currently isn't vulnerable to it because you're
> using signed integers for cnt/quotedSize.

Attached Files:

WARNING SECURITY FLAW IN IMAPSERVER [ In reply to ]
eelco at ic-s
Jul 25, 2003, 1:48 PM
Post #3 of 4 (881 views)
Permalink
Hi All,

A few hours ago i received an e-mail message from Timo Sirainen (i
attached the message) regarding a dangerous security bug in the dbmail
imap daemon.
Roel just fixed up 'quick-fix' patches (attached with this message) for
this security bug since quite a lot of people are running the imap
server in production.

Please keep in mind that this doesn't take care of the whole problem.
It fixes the possibility of inserting SQL during the authentication
proces. An authenticated user
can still inject SQL into normal imap commands.

Fixing of the remainders of these problems and other problems as noted
in Timo Sirainen's message will be checked and fixed next monday.

CVS also has an updates version.

Good luck!

Eelco

> From: Timo Sirainen <tss@iki.fi>
> Date: vri jul 25, 2003 18:34:06 Europe/Amsterdam
> To: bug@dbmail.org
> Subject: dbmail 1.1 sql injections
>
> Looks like you've done nothing to prevent them. For example in login
> user name and mailbox names. Maybe elsewhere, didn't look enough. For
> example:
>
> x login "cras'; update users set passwd = 'bar' where userid = 'cras';
> select user_idnr, passwd, encryption_type FROM users WHERE userid =
> 'cras" "bar"
> x OK LOGIN completed
>
> Other things you might want to fix:
>
> strncpy() calls in build_imap_search() doesn't leave space for
> trailing \0.
>
> Handling literals in build_args_array_ext() doesn't limit the literal
> size in any way. So user could just make the server allocate as much
> memory as it wants to. Also you don't check if fgetc() returns -1, so
> user can just given literal size of 2GB and disconnect, and server
> will fill the memory with -1. And you might want to look at the
> literal stuff in
> http://irccrew.org/~cras/security/advisories/imap-clients.txt,
> although your server currently isn't vulnerable to it because you're
> using signed integers for cnt/quotedSize.

Attached Files:

Re: WARNING SECURITY FLAW IN IMAPSERVER [ In reply to ]
aaron at engr
Jul 25, 2003, 2:36 PM
Post #4 of 4 (879 views)
Permalink
Yeah, Timo's a good guy and has done a lot of security auditing in
competing mailservers. He writes Dovecot, a security-minded IMAP server
that uses standard mbox, IIRC. Timo gave me a bunch of help on libSieve,
too, in fact! Those CMU guys really enjoyed K&R string handling :-P

Aaron


On Fri, 25 Jul 2003, Eelco van Beek - IC&S wrote:

> Hi All,
>
> A few hours ago i received an e-mail message from Timo Sirainen (i
> attached the message) regarding a dangerous security bug in the dbmail
> imap daemon.
> Roel just fixed up 'quick-fix' patches (attached with this message) for
> this security bug since quite a lot of people are running the imap
> server in production.
>
> Please keep in mind that this doesn't take care of the whole problem.
> It fixes the possibility of inserting SQL during the authentication
> proces. An authenticated user
> can still inject SQL into normal imap commands.
>
> Fixing of the remainders of these problems and other problems as noted
> in Timo Sirainen's message will be checked and fixed next monday.
>
> CVS also has an updates version.
>
> Good luck!
>
> Eelco
>
> > From: Timo Sirainen <tss@iki.fi>
> > Date: vri jul 25, 2003 18:34:06 Europe/Amsterdam
> > To: bug@dbmail.org
> > Subject: dbmail 1.1 sql injections
> >
> > Looks like you've done nothing to prevent them. For example in login
> > user name and mailbox names. Maybe elsewhere, didn't look enough. For
> > example:
> >
> > x login "cras'; update users set passwd = 'bar' where userid = 'cras';
> > select user_idnr, passwd, encryption_type FROM users WHERE userid =
> > 'cras" "bar"
> > x OK LOGIN completed
> >
> > Other things you might want to fix:
> >
> > strncpy() calls in build_imap_search() doesn't leave space for
> > trailing \0.
> >
> > Handling literals in build_args_array_ext() doesn't limit the literal
> > size in any way. So user could just make the server allocate as much
> > memory as it wants to. Also you don't check if fgetc() returns -1, so
> > user can just given literal size of 2GB and disconnect, and server
> > will fill the memory with -1. And you might want to look at the
> > literal stuff in
> > http://irccrew.org/~cras/security/advisories/imap-clients.txt,
> > although your server currently isn't vulnerable to it because you're
> > using signed integers for cnt/quotedSize.
>
>
>
>
>
>

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal