OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Jan (janHUNDERT6.DE)
Date: Fri Apr 06 2001 - 16:08:09 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    System affected:
    ---------------
    BinTec X4000 Router

    All firmware versions [as far as I know, only verified with latest
    release 5.1.6 Patch 10]

    Machines with activated additional VPN software license are *NOT*
    affected, neither are machines which filter 1723/tcp.

    Description:
    -----------

    As mentioned before, under the given circumstances the X4000 will lock
    up after sending a SYN portscan to it. Further examination of the
    phenomenon at BinTec has shown that sending a SYN flagged TCP packet to
    port 1723 (pptp) will cause the machine to behave in the described way.

    The pptp daemon should be activated only when the software license key
    is entered and it can process incoming packets adequately.
    However, it isnt. When the 'dormant' pptpd receives a SYN packet and
    cannot process it, the daemon claims 100% CPU usage and the machine
    locks up. This, of course, happens when a SYN portscan against the
    machine is issued and port 1723 gets hit - you can also easily check it
    with 'telnet my.machines.ip 1723' or your favourite packet injector.

    Solution:
    --------

    There are two solutions: One of them is less pricey than the other ;o))
    If you wanted to buy the VPN software anyway, just go ahead and enter
    the key.

    If not, you should include a rule which drops 1723/tcp directed at all
    interfaces of your router (as you should do anyway if you don't use
    it).

    Vendor response:
    ---------------

    Some might remember a little bitter notion with my first mailing.
    However, the day after I posted to Bugtraq the development director
    contacted me. He was very eager to help and asked for my config file
    and a stack trace, which I send them as quick as possible. He reassured
    me that the problem was taken seriously, but mentioned that they could
    not reproduce the phenomenon, so they would take a look at my config and
    see what might have caused it. All this was yesterday.

    Today, the leading developer (I assume) for the X4000's firmware called
    me and was able to present the above solution. He had tried to
    reproduce the DoS on a machine with VPN license first and only after a
    long night got the idea that the pptp daemon might be the culprit (I
    _did_ pity him).

    Comment:
    -------

    I hope you don't mind a personal comment. The sheer fact that I did not
    get any response after first informing support staff of the issue
    really upset me quite a bit. I really expected some reaction within
    less than almost three weeks. Going public changed the response level
    pretty quickly ;o) To be fair I have to state that all the staff I
    talked to during the last few days were seeming absolutely competent
    and very eager to help. Everyone involved stressed how sorry they were
    about the delay and how unusual this was.

    From my personal experience I could only say this is probably true,
    since we've been using other BinTec products for years and they
    generally performed very well, especially compared with products of
    another, erm, well-known vendor.

    As for my statement about the recently introduced money back warranty,
    I could only say that I now do believe this was launched under the
    assumption of a totally stable platform. They surely didn't know the
    vulnerabilty.

    No, I was not bribed to say this ;o))

    --
    Radio HUNDERT,6 Medien GmbH Berlin
    - EDV -
    j.muentherradio.hundert6.de