bug in pppd - dos attack possible - PPP

This is a discussion on bug in pppd - dos attack possible - PPP ; I found a bug in pppd 2.4.2 This bug can be used for a dos attack steeling all memory and cputime under certain circumstances. I have reported this bug and the possible solution to the addresses mentioned in the README ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: bug in pppd - dos attack possible

  1. bug in pppd - dos attack possible


    I found a bug in pppd 2.4.2 This bug can be used for a dos attack
    steeling all memory and cputime under certain circumstances.

    I have reported this bug and the possible solution to the addresses
    mentioned in the README within pppd's source.
    I have tried to inform the developers via http://www.samba.org/ppp/
    Selecting bug reports on that page results in an fatal error:
    ##############
    The system encountered a fatal error cannot open config file
    /etc/jitterbug/ppp-bugs : No such file or directory
    The last error code was: No such file or directory
    uid/gid=33/33
    ###############

    I have sent this report a week ago and have not yet received any reaction.
    Can anyone tell me, where to direct this information to, so that the
    problem may be solved?

    Norbert Wegener

  2. Re: bug in pppd - dos attack possible

    Norbert Wegener writes:
    > I have sent this report a week ago and have not yet received any reaction.
    > Can anyone tell me, where to direct this information to, so that the
    > problem may be solved?


    Actually, instead of sending it to one of the usual lists (either
    ppp-bugs@samba.org or linux-ppp@vger.kernel.org), it seems you sent it
    directly to me at my home email address.

    I simply haven't had time to evaluate it and (as far as I can tell)
    none of the other maintainers have seen it.

    You suggested that it affects the Solaris version, too, but I doubt
    this. The bug report seems to depend on problems in (perhaps) the
    radius plugin, but no such thing exists yet on Solaris.

    Nothing in the bug report actually suggests anything at all about an
    exploit. It appears to show a case where IPCP negotiation can
    apparently fail to converge. I don't see how that leads to memory
    leaks or any sort of viable DoS attack. Note that PPP negotiation is
    between peers and cannot be exploited by anyone who isn't a party to
    the connection. It can't be attacked from the outside.

    The suggested fix doesn't appear to make sense. It suggests bumping
    up f->nakloops for each CONFREJ sent. How does that fix anything?
    f->nakloops is used to switch from CONFNAK to CONFREJ in the case
    where the peer is stubborn (see fsm_rconfreq's reject_if_disagree
    logic). It implements the "Max-Failure" logic from RFC 1661. In this
    case, we're already sending CONFREJ, so increasing f->nakloops does
    nothing.

    A better fix would count the number of consecutive Configure-Reject
    messages sent and shut down the FSM once we hit that limit. In
    addition to that, some investigation of why IPCP on the other side is
    clearly violating RFC 1661 (it's apparently continuing to include an
    option that the peer has rejected) and also why it hasn't terminated
    due to the ipcp-max-configure logic is necessary.

    (If it is actually leaking memory, then it'd be good to know exactly
    what is leaking memory. I don't see a complete evaluation of the
    problem here, and I suspect that the problem might be in one of the
    plugins used.)

    In short, there's a lot of missing information here, and it'll
    probably take quite a while for someone to do that work.

    --
    James Carlson, IP Systems Group
    Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

  3. Re: bug in pppd - dos attack possible

    James Carlson wrote:
    > Norbert Wegener writes:
    >
    >>I have sent this report a week ago and have not yet received any reaction.
    >>Can anyone tell me, where to direct this information to, so that the
    >>problem may be solved?

    >
    >
    > Actually, instead of sending it to one of the usual lists (either
    > ppp-bugs@samba.org or linux-ppp@vger.kernel.org), it seems you sent it
    > directly to me at my home email address.

    Sorry, when the reports went wrong, but from the README:

    If you find bugs in this package, please report them to the maintainer
    for the port for the operating system you are using:

    Linux Paul Mackerras
    Solaris James Carlson



    > You suggested that it affects the Solaris version, too, but I doubt
    > this. The bug report seems to depend on problems in (perhaps) the
    > radius plugin, but no such thing exists yet on Solaris.

    Yes,I use linux, but as the problem seems to be in fsm.c, also Solaris
    might have been affected. As I wrote in the problem report:

    This bug is exploitable at least in the following environment:
    pppd + radiusplugin + freeradius, where freeradius delivers ipaddresses
    to clients.

    When there is no radius plugin for Solaris, this system is not affected.
    >
    > Nothing in the bug report actually suggests anything at all about an
    > exploit. It appears to show a case where IPCP negotiation can
    > apparently fail to converge. I don't see how that leads to memory
    > leaks or any sort of viable DoS attack.

    This situation will always appear, when the radius (via plugin) is not
    able to deliver an ipaddress to pppd.
    As I wrote in the bug report:

    As this happens after authentication, this bug is only exploitable by
    authorized users. Nevertheless they are able to start parallel sessions
    of ppp and by this they are able to stop the server from doing his job.

    Starting parallel sessions of pppd on the client site can easily be
    done. Each ppp on the client starts a new pppd on the server, and each
    pppd instance on the server will do endless negotiation of IPCP.
    Each instance of pppd needs memory and cpu. At least in my terminology
    and understanding this will end up in a possible dos attack.


    Note that PPP negotiation is
    > between peers and cannot be exploited by anyone who isn't a party to
    > the connection. It can't be attacked from the outside.

    You are right. As I quoted from the bug report from above:
    As this happens after authentication, this bug is only exploitable by
    authorized users.
    >
    > The suggested fix doesn't appear to make sense.

    I am no professional programmer. Nevertheless this was the only possible
    fix for ME, as in my situation none of the options
    ipcp-max-configure, ipcp-max-failure, ipcp-max-terminate, ipcp-restar
    showed any effect. Maybe this were the wrong options I used?
    It suggests bumping
    > up f->nakloops for each CONFREJ sent. How does that fix anything?
    > f->nakloops is used to switch from CONFNAK to CONFREJ in the case
    > where the peer is stubborn (see fsm_rconfreq's reject_if_disagree
    > logic). It implements the "Max-Failure" logic from RFC 1661. In this
    > case, we're already sending CONFREJ, so increasing f->nakloops does
    > nothing.


    >
    > A better fix would count the number of consecutive Configure-Reject
    > messages sent and shut down the FSM once we hit that limit.

    As you have much more knowlegde than I have from the code, your solution
    is the correct one. Nevertheless there is a problem.
    In
    > addition to that, some investigation of why IPCP on the other side is
    > clearly violating RFC 1661 (it's apparently continuing to include an
    > option that the peer has rejected) and also why it hasn't terminated
    > due to the ipcp-max-configure logic is necessary.
    >
    > (If it is actually leaking memory, then it'd be good to know exactly
    > what is leaking memory. I don't see a complete evaluation of the
    > problem here, and I suspect that the problem might be in one of the
    > plugins used.)

    Maybe you are right, as this problem only occurs in conjunction with the
    plugins. Nevertheless, the suggested source change in fsm.c did the job
    for me.
    >
    > In short, there's a lot of missing information here, and it'll
    > probably take quite a while for someone to do that work.


    >


  4. Re: bug in pppd - dos attack possible

    Norbert Wegener writes:
    > Sorry, when the reports went wrong, but from the README:


    Yes, those do need to be updated.

    > Starting parallel sessions of pppd on the client site can easily be
    > done. Each ppp on the client starts a new pppd on the server, and
    > each pppd instance on the server will do endless negotiation of IPCP.
    > Each instance of pppd needs memory and cpu. At least in my terminology
    > and understanding this will end up in a possible dos attack.


    This sounds like a misunderstanding of some sort. Having IPCP caught
    in a negotiation loop in talking to one peer does not result in any
    extra instances of pppd. I can see how a plugin might mishandle this
    case (and that's something to fix in the plugin, not pppd itself), but
    not how there's an exploitable problem here.

    Are you using some sort of tunnel, such as PPTP, L2TP, or PPPoE? If
    so, then the problem I *think* you're talking about may be an issue
    with the underlying mechanism that starts pppd, and not a problem in
    pppd itself. There's no way that any instance of pppd could "know"
    about the other instances, if there are any, let alone create new
    instances or decide to avoid creating such extra instances.

    If the potential for a "leak" or "exploit" depends on creating
    parallel instances of pppd by some mechanism, then I'd have to say
    that this isn't an exploit against pppd.

    > > The suggested fix doesn't appear to make sense.

    > I am no professional programmer. Nevertheless this was the only
    > possible fix for ME, as in my situation none of the options
    > ipcp-max-configure, ipcp-max-failure, ipcp-max-terminate, ipcp-restar
    > showed any effect. Maybe this were the wrong options I used?


    In that case, all we have is an unconfirmed report of some sort of
    problem, but lacking many important details. We'll do our best to try
    to sort it out by replicating the problem, but as it stands, it'll
    take a fair amount of effort for someone to root-cause this for you.

    It's free software.

    > > (If it is actually leaking memory, then it'd be good to know exactly
    > > what is leaking memory. I don't see a complete evaluation of the
    > > problem here, and I suspect that the problem might be in one of the
    > > plugins used.)

    > Maybe you are right, as this problem only occurs in conjunction with
    > the plugins. Nevertheless, the suggested source change in fsm.c did
    > the job for me.


    We don't just apply patches to the source from arbitrary contributors.
    It's crucially important that someone look at the problem, find out
    what the root causes are, and propose a fix that makes sense in the
    current design.

    Applying patches that aren't fully understood often leads to creating
    new bugs in the short term, and always leads to corruption of the code
    base over time. It's not supportable.

    If you're willing to do the work, then that's great; we'd appreciate
    the contribution. Otherwise, you'll have to wait until someone else
    has the time to do a more complete analysis of the problem, and create
    a solid fix.

    --
    James Carlson, IP Systems Group
    Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

  5. Re: bug in pppd - dos attack possible


    >>Starting parallel sessions of pppd on the client site can easily be
    >>done. Each ppp on the client starts a new pppd on the server, and
    >>each pppd instance on the server will do endless negotiation of IPCP.
    >>Each instance of pppd needs memory and cpu. At least in my terminology
    >>and understanding this will end up in a possible dos attack.

    >
    >
    > This sounds like a misunderstanding of some sort. Having IPCP caught
    > in a negotiation loop in talking to one peer does not result in any
    > extra instances of pppd. I can see how a plugin might mishandle this
    > case (and that's something to fix in the plugin, not pppd itself), but
    > not how there's an exploitable problem here.
    >
    > Are you using some sort of tunnel, such as PPTP, L2TP, or PPPoE? If
    > so, then the problem I *think* you're talking about may be an issue
    > with the underlying mechanism that starts pppd, and not a problem in
    > pppd itself.

    I use l2tp.
    There's no way that any instance of pppd could "know"
    > about the other instances, if there are any, let alone create new
    > instances or decide to avoid creating such extra instances.

    I never said something like this. A client can restart his ppp arbitrary
    often, which results in the same number of ppp daemons on the server side.
    >
    > If the potential for a "leak" or "exploit" depends on creating
    > parallel instances of pppd by some mechanism, then I'd have to say
    > that this isn't an exploit against pppd.

    It depends on that mechanism, but I think it depends on the point of
    view, whether or not this is an exploit against pppd or not.
    Fact is, that ipcp negotiation in this special case never end and pppd's
    parallel sessions might end up in using all the server's resources.
    >
    >
    >>>The suggested fix doesn't appear to make sense.

    >>
    >>I am no professional programmer. Nevertheless this was the only
    >>possible fix for ME, as in my situation none of the options
    >> ipcp-max-configure, ipcp-max-failure, ipcp-max-terminate, ipcp-restar
    >>showed any effect. Maybe this were the wrong options I used?

    >
    >
    > In that case, all we have is an unconfirmed report of some sort of
    > problem, but lacking many important details.

    I am willing to give any needed information. Which information is needed?
    We'll do our best to try
    > to sort it out by replicating the problem, but as it stands, it'll
    > take a fair amount of effort for someone to root-cause this for you.
    >
    > It's free software.

    I know, and I am willing to help to solve that problem, as far as my
    skills allow.
    >
    >
    >


  6. Re: bug in pppd - dos attack possible

    Norbert Wegener writes:


    ]>>Starting parallel sessions of pppd on the client site can easily be
    ]>>done. Each ppp on the client starts a new pppd on the server, and
    ]>>each pppd instance on the server will do endless negotiation of IPCP.
    ]>>Each instance of pppd needs memory and cpu. At least in my terminology
    ]>>and understanding this will end up in a possible dos attack.
    ]>
    ]>
    ]> This sounds like a misunderstanding of some sort. Having IPCP caught
    ]> in a negotiation loop in talking to one peer does not result in any
    ]> extra instances of pppd. I can see how a plugin might mishandle this
    ]> case (and that's something to fix in the plugin, not pppd itself), but
    ]> not how there's an exploitable problem here.
    ]>
    ]> Are you using some sort of tunnel, such as PPTP, L2TP, or PPPoE? If
    ]> so, then the problem I *think* you're talking about may be an issue
    ]> with the underlying mechanism that starts pppd, and not a problem in
    ]> pppd itself.
    ]I use l2tp.
    ]There's no way that any instance of pppd could "know"
    ]> about the other instances, if there are any, let alone create new
    ]> instances or decide to avoid creating such extra instances.
    ]I never said something like this. A client can restart his ppp arbitrary
    ] often, which results in the same number of ppp daemons on the server side.

    But the attacked system would know who the attacker was. Sounds far more
    dangerous to the attacker than the attacked.

    The could far more easily log on 10,000 times and start up some memory
    hogging program on each login. Once you let someone onto your system there
    are manymany ways they can DOS you. But the attack seems silly since the
    attacker is then known, and punishable (by having all priviledges yanked
    for example)



  7. Re: bug in pppd - dos attack possible

    Bill Unruh wrote:
    > Norbert Wegener writes:
    >
    >
    > ]>>Starting parallel sessions of pppd on the client site can easily be
    > ]>>done. Each ppp on the client starts a new pppd on the server, and
    > ]>>each pppd instance on the server will do endless negotiation of IPCP.
    > ]>>Each instance of pppd needs memory and cpu. At least in my terminology
    > ]>>and understanding this will end up in a possible dos attack.
    > ]>
    > ]>
    > ]> This sounds like a misunderstanding of some sort. Having IPCP caught
    > ]> in a negotiation loop in talking to one peer does not result in any
    > ]> extra instances of pppd. I can see how a plugin might mishandle this
    > ]> case (and that's something to fix in the plugin, not pppd itself), but
    > ]> not how there's an exploitable problem here.
    > ]>
    > ]> Are you using some sort of tunnel, such as PPTP, L2TP, or PPPoE? If
    > ]> so, then the problem I *think* you're talking about may be an issue
    > ]> with the underlying mechanism that starts pppd, and not a problem in
    > ]> pppd itself.
    > ]I use l2tp.
    > ]There's no way that any instance of pppd could "know"
    > ]> about the other instances, if there are any, let alone create new
    > ]> instances or decide to avoid creating such extra instances.
    > ]I never said something like this. A client can restart his ppp arbitrary
    > ] often, which results in the same number of ppp daemons on the server side.
    >
    > But the attacked system would know who the attacker was. Sounds far more
    > dangerous to the attacker than the attacked.
    >
    > The could far more easily log on 10,000 times and start up some memory
    > hogging program on each login. Once you let someone onto your system there
    > are manymany ways they can DOS you. But the attack seems silly since the
    > attacker is then known, and punishable (by having all priviledges yanked
    > for example)

    Agreed, but it is not neccessarily an evil attacker alone, who can
    damage such a system. When the ippool is empty, *every* regular user of
    that system would start a pppd which does endless negotiation of ipcp.
    >
    >


+ Reply to Thread