buffer overflow

[brong]

From: Mariusz Woloszyn
Bugzilla-Id: 3061
Version: 2.1.x
Owner: Ken Murchison

[brong]

From: Mariusz Woloszyn

Hi!

I have compiled cyrus-sasl and cyrus-imap with -fstack-protector-all. I have linked both against kerberos 5 libraries, all compiled with -stack-protector-all.

While testing kerberos authentication with GSSAPI i got following:

root@mobile:~# imtest -m GSSAPI mobile
S: * OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS LOGINDISABLED AUTH=GSSAPI AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=OTP SASL-IR] mobile Cyrus IMAP v2.3.12p2 server ready
C: C01 CAPABILITY
S: * CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS LOGINDISABLED AUTH=GSSAPI AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=OTP SASL-IR ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE CATENATE CONDSTORE SCAN IDLE URLAUTH
S: C01 OK Completed
C: A01 AUTHENTICATE GSSAPI Authentication failed. overflowed buffer
Security strength factor: 0

The kernel reported:
May 15 14:48:00 mobile kernel: imapd[20248]: segfault at c ip b7f8e07d sp bf9b4f70 error 4 in libsasl2.so.2.0.22[b7f7f000+16000]

And the gdb shows:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1213978944 (LWP 20253)]
0xb7f4607d in sasl_server_step () from /usr/lib/libsasl2.so.2
(gdb) backtrace
#0 0xb7f4607d in sasl_server_step () from /usr/lib/libsasl2.so.2
#1 0x08092b7a in saslserver ()
#2 0x0806264f in cmd_authenticate ()
#3 0x080654c5 in cmdloop ()
#4 0x08066c8b in service_main ()
#5 0x0804d542 in main ()
(gdb) x/10i 0xb7f4607d
0xb7f4607d <sasl_server_step+169>: mov 0xc(%eax),%esi
0xb7f46080 <sasl_server_step+172>: lea 0x860(%edi),%eax
0xb7f46086 <sasl_server_step+178>: mov %eax,0x18(%esp)
0xb7f4608a <sasl_server_step+182>: mov %ecx,0x14(%esp)
0xb7f4608e <sasl_server_step+186>: mov 0xffffffdc(%ebp),%eax
0xb7f46091 <sasl_server_step+189>: mov %eax,0x10(%esp)
0xb7f46095 <sasl_server_step+193>: mov %edx,0xc(%esp)
0xb7f46099 <sasl_server_step+197>: mov 0xffffffe0(%ebp),%edx
0xb7f4609c <sasl_server_step+200>: mov %edx,0x8(%esp)
0xb7f460a0 <sasl_server_step+204>: mov 0x1134(%edi),%eax
(gdb) info registers
eax 0x0 0
ecx 0xbfc6f2b0 -1077480784
edx 0x0 0
ebx 0xb7f4d224 -1208692188
esp 0xbfc6f220 0xbfc6f220
ebp 0xbfc6f268 0xbfc6f268
esi 0x0 0
edi 0x94e3628 156120616
eip 0xb7f4607d 0xb7f4607d <sasl_server_step+169>
eflags 0x10282 [ SF IF RF ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51

[brong]

From: Mariusz Woloszyn

(In reply to comment #0)
> Hi!
>
> I have compiled cyrus-sasl and cyrus-imap with -fstack-protector-all. I have
> linked both against kerberos 5 libraries, all compiled with
> -stack-protector-all.
>
> While testing kerberos authentication with GSSAPI i got following:
>
> root@mobile:~# imtest -m GSSAPI mobile
> S: * OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS LOGINDISABLED
> AUTH=GSSAPI AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=OTP SASL-IR] mobile Cyrus IMAP
> v2.3.12p2 server ready
> C: C01 CAPABILITY
> S: * CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS LOGINDISABLED AUTH=GSSAPI
> AUTH=CRAM-MD5 AUTH=DIGEST-MD5 AUTH=OTP SASL-IR ACL RIGHTS=kxte QUOTA
> MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN
> MULTIAPPEND BINARY SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES
> ANNOTATEMORE CATENATE CONDSTORE SCAN IDLE URLAUTH
> S: C01 OK Completed
> C: A01 AUTHENTICATE GSSAPI Authentication failed. overflowed buffer
> Security strength factor: 0
>
> The kernel reported:
> May 15 14:48:00 mobile kernel: imapd[20248]: segfault at c ip b7f8e07d sp
> bf9b4f70 error 4 in libsasl2.so.2.0.22[b7f7f000+16000]
>
> And the gdb shows:
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1213978944 (LWP 20253)]
> 0xb7f4607d in sasl_server_step () from /usr/lib/libsasl2.so.2
> (gdb) backtrace
> #0 0xb7f4607d in sasl_server_step () from /usr/lib/libsasl2.so.2
> #1 0x08092b7a in saslserver ()
> #2 0x0806264f in cmd_authenticate ()
> #3 0x080654c5 in cmdloop ()
> #4 0x08066c8b in service_main ()
> #5 0x0804d542 in main ()
> (gdb) x/10i 0xb7f4607d
> 0xb7f4607d <sasl_server_step+169>: mov 0xc(%eax),%esi
> 0xb7f46080 <sasl_server_step+172>: lea 0x860(%edi),%eax
> 0xb7f46086 <sasl_server_step+178>: mov %eax,0x18(%esp)
> 0xb7f4608a <sasl_server_step+182>: mov %ecx,0x14(%esp)
> 0xb7f4608e <sasl_server_step+186>: mov 0xffffffdc(%ebp),%eax
> 0xb7f46091 <sasl_server_step+189>: mov %eax,0x10(%esp)
> 0xb7f46095 <sasl_server_step+193>: mov %edx,0xc(%esp)
> 0xb7f46099 <sasl_server_step+197>: mov 0xffffffe0(%ebp),%edx
> 0xb7f4609c <sasl_server_step+200>: mov %edx,0x8(%esp)
> 0xb7f460a0 <sasl_server_step+204>: mov 0x1134(%edi),%eax
> (gdb) info registers
> eax 0x0 0
> ecx 0xbfc6f2b0 -1077480784
> edx 0x0 0
> ebx 0xb7f4d224 -1208692188
> esp 0xbfc6f220 0xbfc6f220
> ebp 0xbfc6f268 0xbfc6f268
> esi 0x0 0
> edi 0x94e3628 156120616
> eip 0xb7f4607d 0xb7f4607d <sasl_server_step+169>
> eflags 0x10282 [ SF IF RF ]
> cs 0x73 115
> ss 0x7b 123
> ds 0x7b 123
> es 0x7b 123
> fs 0x0 0
> gs 0x33 51
>

Is there any progress on this subject?

Best regards,

[brong]

From: Ken Murchison

Not yet

[brong]

From: Mariusz Woloszyn

Hi!

Is there any progress in this subject?
I have investigated it a bit and it seems to be exploitable as I get ip=0x44444444.

[brong]

From: Alexey Melnikov

It would be good to build 2.1.25 with debug information, so that C line numbers are visible in the stack trace. Otherwise this just doesn't provide enough information.

[brong]

From: Alexey Melnikov

Lowering priority of this because no information is available.