The following security advisory is sent to the securiteam mailing list, and can
be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
PPPd DoS
------------------------------------------------------------------------
SUMMARY
<http://www.samba.org/ppp/features.html> ppp is "an implementation of
(PPP) Point-to-Point Protocol for Unix systems".
Improper verification of header fields allows an attacker cause the pppd
server access memory it isn't allowed to, which in turn causes the server
to crash. There is no possibility of code execution, as there is no data
being copied, just a pointer dereferenced.
DETAILS
Vulnerable Systems:
* ppp Version 2.4.1
The actual vulnerable code appears in the file /pppd/cbcp.c, line 334. A
brief walk through of how it is reached: Starting in the /pppd directory,
in main.c we have the function get_input(), which is called when there is
data ready on the network. It reads in the packet at line 932, at most
1500 + PPP header sized bytes into a static packet buffer called
inpacket_buf.
Depending on the protocol, a handler is picked out of an array of handlers
by matching the protocol field of the PPP header. We are interested in
when the protocol is CBCP, Callback Control Protocol. A snip from that
function is shown here:
/* process an incomming packet */
static void
cbcp_input(unit, inpacket, pktlen)
int unit;
u_char *inpacket;
int pktlen;
{
u_char *inp;
u_char code, id;
u_short len;
cbcp_state *us = &cbcp[unit];
inp = inpacket;
if (pktlen < CBCP_MINLEN) {
error("CBCP packet is too small");
return;
}
GETCHAR(code, inp);
GETCHAR(id, inp);
GETSHORT(len, inp);
#if 0
if (len > pktlen) {
error("CBCP packet: invalid length");
return;
}
#endif
1] len -= CBCP_MINLEN/*4*/; /* HOLE */
switch(code) {
case CBCP_REQ:
us->us_id = id;
2] cbcp_recvreq(us, inp, len);
break;
1) len has not been validated yet, if it is < 4, the subtraction will wrap
around to a large 2 byte unsigned number.
2) len is passed to the request processing function, which now thinks that
packet is longer than it really is.
We then move onto the cbcp_recvreq() function to process the request, this
function is in /pppd/cbcp.c :
/* received CBCP request */
static void
cbcp_recvreq(us, pckt, pcktlen)
cbcp_state *us;
char *pckt;
int pcktlen;
{
u_char type, opt_len, delay, addr_type;
char address[256];
int len = pcktlen;
address[0] = 0;
1] while (len) {
dbglog("length: %d", len);
GETCHAR(type, pckt);
2] GETCHAR(opt_len, pckt);
if (opt_len > 2)
GETCHAR(delay, pckt);
us->us_allowed |= (1 << type);
switch(type) {
case CB_CONF_NO:
dbglog("no callback allowed");
break;
case CB_CONF_USER:
dbglog("user callback allowed");
if (opt_len > 4) {
GETCHAR(addr_type, pckt);
memcpy(address, pckt, opt_len - 4);
address[opt_len - 4] = 0;
if (address[0])
dbglog("address: %s", address);
}
break;
case CB_CONF_ADMIN:
dbglog("user admin defined allowed");
break;
case CB_CONF_LIST:
break;
}
3] len -= opt_len; /* HOLE */
}
cbcp_resp(us);
}
1) The loop continues processing the packet as long as len is != 0. Each
iteration the packet pointer is moved forward in the GET_ macros.
2) The option length is retrieved from the packet, and is not validated in
any way.
3) The option length is subtracted from the len variable, which controls
the loop. There are a number of ways to exploit this calculation.
Actually, _any_ malformed packet will screw up that loop. It relies on
the opt_len values in the packet all summing to len, if they don't, the
loop won't stop, unless by pure luck of encountering the right value
somewhere in the .data section (the packet buffer is global). Net result,
is that eventually in the GET_ macros, the packet pointer will be advanced
to far, and hit unmapped memory and crash the server.
ADDITIONAL INFORMATION
The information has been provided by <mailto:infamous41md@hotpop.com>
sean.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to:
list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to:
list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any
kind.
In no event shall we be liable for any damages whatsoever including direct,
indirect, incidental, consequential, loss of business profits or special
damages.
