lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20030925060223.GA332@lt1.cleaton.net>
Date: Thu, 25 Sep 2003 07:02:24 +0100
From: Nick Cleaton <nick@...aton.net>
To: bugtraq@...urityfocus.com
Subject: Cfengine2 cfservd remote stack overflow

==============================================================================

Background
==========

Cfengine (www.cfengine.org) automates the configuration and maintenance of
large computer networks.  A common setup involves running the cfservd daemon
on TCP port 5308 on a central master server, with other hosts periodically
connecting to the master to check for configuration updates.

Vulnerability
=============

There is an exploitable stack overflow in the network I/O code used in the
cfservd daemon in Cfengine 2.x prior to version 2.0.8.  Arbitrary code
execution has been demonstrated on x86 FreeBSD and is believed to be possible
on all platforms.

Cfengine 1 is not vulnerable, but downgrading is not recommended as version 1
is nolonger supported by the author.

Cfengine 2 provides strong client authentication by redesigning a stricter
communications protocol. Responsibility for checking input buffers is
relocated in the new code and one important check was not carried over.

The vulnerability occurs after an ACL check on the source IP of the TCP
connection, so this flaw can only be exploited from hosts that are authorized
to connect to the cfservd daemon, or from systems able to spoof an authorized
IP or trick an authorized host into forwarding a connection.  

The vulnerability can be exploited without reading any data from the server,
so blind spoofing may be feasible against some platforms.

The cfservd daemon is multithreaded rather than forking, so the attacker only
gets a single chance to get the offset correct within a 4096 byte window, less
a few bytes for shellcode.  It may be possible to increase this window by
pre-populating other buffers before triggering the overflow.

The vulnerable network I/O code is used in several other places in Cfengine 2,
so similar problems may exist in other pre-2.0.8 Cfengine TCP servers and
clients.

Vulnerable Versions
===================

Vulnerable:
   cfengine-2.0.0
   cfengine-2.0.1
   cfengine-2.0.2
   cfengine-2.0.3
   cfengine-2.0.4
   cfengine-2.0.5
   cfengine-2.0.5b1
   cfengine-2.0.5pre
   cfengine-2.0.5pre2
   cfengine-2.0.6
   cfengine-2.0.7
   cfengine-2.0.7p1
   cfengine-2.0.7p2
   cfengine-2.0.7p3
   cfengine-2.1.0a6
   cfengine-2.1.0a8
   cfengine-2.1.0a9

Not Vulnerable:
   cfengine-1.6.5 and earlier
   cfengine-2.0.8
   cfengine-2.0.8p1

Detection
=========

A failed attempt to exploit this vulnerability is likely to cause cfservd to
exit with a segfault, which will show up in the logs.

A successful attempt to exploit may show up as cfservd not running or cfservd
recently restarted, if the attacker is not particularly sophisticated.

The log message "Bad transaction packet -- too long" indicates an attempt to
exploit a patched cfservd.

Fix
===

Upgrade to version 2.0.8p1 or later (recommended), or apply the attached patch
and rebuild cfengine.

The patch was made against 2.0.7p3, and may need to be adapted slightly for
some earlier versions of Cfengine 2.

Workaround
==========

Ensure that you have cfservd ACLs or firewall rules set up to allow
connections from trusted hosts only.

Details
=======

In BusyWithConnection() in cfservd.c, recvbuffer[] (a 4096 byte stack buffer)
is passed to ReceiveTransaction() in net.c.  ReceiveTransaction() then reads a
message length as a six digit decimal number from the TCP socket, and passes
the buffer and the length on to RecvSocketStream(), which attempts to read
that many bytes into the buffer.

If the length is greater than 4096, an overflow occurs and the return address
of BusyWithConnection() can be overwritten.

In tests on x86 FreeBSD, recvbuffer[] ends up within a few dozen bytes of the
top of the stack, so the attacker can only send a few dozen extra bytes or
cfservd will segfault before the attacker gets control.

==============================================================================

--
Nick Cleaton
nick@...aton.net

View attachment "net.c.patch" of type "text/plain" (1452 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ