double free in digest-md5

[Philipp Gesang]

Hi,

this is an issue I originally raised on the mutt-users list [0]
where it was suggested that I seek assistance here. The MUA
crashes when sending email over a digest-md5 authenticated
connection. This happens in a call to sasl_dispose() that
indirectly frees some handle that had been freed earlier while
authenticating.

Backtraces:

--8<-- free 1 ----------------------------------------------->8--

#0  free_rc4 (text=text at entry=0x21d3460) at digestmd5.c:1227
#1  0x00007f1fa8416b92 in make_client_response (text=text at entry=0x21d3460, 
    params=params at entry=0x21d3200, oparams=oparams at entry=0x21d18f0) at digestmd5.c:3613
#2  0x00007f1fa8417039 in digestmd5_client_mech_step2 (oparams=<optimized out>, 
    clientoutlen=<optimized out>, clientout=<optimized out>, prompt_need=<optimized out>, 
    serverinlen=<optimized out>, serverin=<optimized out>, params=0x21d3200, 
    ctext=<optimized out>) at digestmd5.c:4364
#3  digestmd5_client_mech_step (conn_context=<optimized out>, params=0x21d3200, 
    serverin=<optimized out>, serverinlen=<optimized out>, prompt_need=<optimized out>, 
    clientout=<optimized out>, clientoutlen=<optimized out>, oparams=<optimized out>)
    at digestmd5.c:4558
#4  0x00007f1fa7e6a471 in sasl_client_step (conn=0x21d1080, serverin=<optimized out>, 
    serverinlen=<optimized out>, prompt_need=prompt_need at entry=0x7fffc8656330, 
    clientout=clientout at entry=0x7fffc8656340, clientoutlen=clientoutlen at entry=0x7fffc865631c)
    at client.c:922
#5  0x0000000000492c05 in smtp_auth_sasl (conn=conn at entry=0x210f810, mechlist=<optimized out>)
    at smtp.c:635
#6  0x000000000049339d in smtp_auth (conn=0x210f810) at smtp.c:549
#7  smtp_open (conn=0x210f810) at smtp.c:503
#8  mutt_smtp_send (from=0x210ce70, to=0x210c890, cc=0x0, bcc=0x0, 
    msgfile=msgfile at entry=0x7fffc8657570 "/tmp/mutt-drift-2428-105237-294724449650828126", 
    eightbit=1) at smtp.c:311
#9  0x0000000000464a45 in send_message (msg=<optimized out>, msg=<optimized out>) at send.c:1030
#10 ci_send_message (flags=<optimized out>, flags at entry=0, msg=<optimized out>, msg at entry=0x0, 
    tempfile=tempfile at entry=0x0, ctx=0x1f44270, cur=<optimized out>, cur at entry=0x0) at send.c:1936
#11 0x000000000042201e in mutt_index_menu () at curs_main.c:2161
#12 0x0000000000409253 in main (argc=1, argv=0x7fffc865abe8, environ=<optimized out>)
    at main.c:1274

--8<-- free 2 ----------------------------------------------->8--

#0  free_rc4 (text=0x21d3460) at digestmd5.c:1227
#1  0x00007f1fa8413420 in digestmd5_common_mech_dispose (conn_context=0x21d3460, utils=0x21d32d0)
    at digestmd5.c:1610
#2  0x00007f1fa7e696f8 in client_dispose (pconn=0x21d1080) at client.c:337
#3  0x00007f1fa7e6c414 in sasl_dispose (pconn=0x21693a0) at common.c:849
#4  0x00000000004987c0 in mutt_sasl_conn_close (conn=0x210f810) at mutt_sasl.c:496
#5  0x00000000004952a3 in mutt_socket_close (conn=conn at entry=0x210f810) at mutt_socket.c:85
#6  0x000000000049395a in mutt_smtp_send (from=<optimized out>, to=0x210c890, cc=0x0, bcc=0x0, 
    msgfile=msgfile at entry=0x7fffc8657570 "/tmp/mutt-drift-2428-105237-294724449650828126", 
    eightbit=<optimized out>) at smtp.c:357
#7  0x0000000000464a45 in send_message (msg=<optimized out>, msg=<optimized out>) at send.c:1030
#8  ci_send_message (flags=<optimized out>, flags at entry=0, msg=<optimized out>, msg at entry=0x0, 
    tempfile=tempfile at entry=0x0, ctx=0x1f44270, cur=<optimized out>, cur at entry=0x0) at send.c:1936
#9  0x000000000042201e in mutt_index_menu () at curs_main.c:2161
#10 0x0000000000409253 in main (argc=1, argv=0x7fffc865abe8, environ=<optimized out>)
    at main.c:1274

--8<--------------------------------------------------------->8--

AFAICT mutt’s smtp client code follows the steps layed out in
sample/client.c. Is there a precaution to be taken by the caller
of sasl_client_step() and sasl_dispose() to guard against
accidentally triggering free_rc4() twice?

I’ve tested both 2.1.26 and 2.1.27, the issue is present in both.
FWIW the client authenticates against a postfix built against
cyrus-sasl 2.1.23. Let me know if you need more information.

Thanks,
Philipp

[0] http://lists.mutt.org/pipermail/mutt-users/Week-of-Mon-20190415/000824.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/attachments/20190416/931c3a1d/attachment.sig>