A security flaw is probably still present in Ascend's multilink PPP implementation over ISDN. Due to its fundamental nature, it's probably in other ISDN hardware as well. Ascend determines whether to bond a new incoming PPP connection with a previous connection based upon the 'endpoint identifier'. As I recall, they claimed that they had to do this because they had to decide whether to bond or not _before_ they received any other authentication information. Most ISDN routers use their Ethernet hardware address as their endpoint identifier. I'm not sure what modems and T/As use. However, since the endpoint identifier is specified by the other end, it is fundamentally insecure to rely upon it for a security decision, such as whether to bond to an existing PPP connection. The way we discovered this was during WebRamp beta testing, when the firmware had an interesting bug. It seems that every WebRamp sent the same endpoint identifier! Sure enough, if two WebRamps ever connected to the same Max or TNT, they'd get bonded to each other and both would fail to send any (futher) data reliably. Ascend insisted that the bug was in the WebRamp (it was sending an invalied endpoint ID). We responded that while there was a bug in the WebRamp, it was exploiting a security flaw in the Ascend. Anyone can, in principle, specify any endpoint identifier that they wish. Ascend simply got WebRamp to fix the flaw, and to my knowledge, this weakness still exists. Anyone who knows your endpoint identifier can bond to your PPP link. Anyone who you have ever connected to with your ISDN equipment knows your endpoint identifier, and you cannot easily change it. To an extent, the problem is fundamental. If you aren't using PAP or CHAP, but instead use a text 'sign on' form of authentication, but are bonding multiple connections, what means does the other end have to determine whether to bond to an existing connection when it receives a new one? But we had this problem even with PAP or CHAP enabled -- I'm not entirely sure why. DS
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:33:31 PDT