bugtraq - problem in voip environment

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: <1A6356B90C7D7247968185E75CB1D6980AA06C@POLYNET.kephren.polytechnique.fr>
Date: Sat, 11 Sep 2004 22:53:44 +0200
From: "Pasquiet Loic (M.)" <Loic.Pasquiet@...ytechnique.fr>
To: <bugtraq@...urityfocus.com>
Subject: problem in voip environment

1. Topic
Security issues have been identified that allows an attacker to
compromise ip phones.

2. Description

We are testing voip solutions and here's what we've found : 

take a layer 2 switch, here, an avaya cajun switch like P33xT or
P334T-ML (layer 2).

configure 2 ports like it's recommended in voip, like this :

a vlan id x on port 1 and a vlan-static-bindig id y for telephony (x is
the pvid is or native vlan or default vlan)
a vlan id x on port 2 and a vlan-static-bindig id y for telephony 
we are in mode access so ports are not 802.1q or in trunk mode ...
plug an ip phone on port 1 in 10.10.10.10/24
plug a PC on port 2 in 10.10.10.11/24 (the pc doesn't tag his frames)
(if you plug the PC behind another ip phone, the result is the same)

try to ping the ip phone ... it's ok. 
You can now easily flood all ip phones on the same switch or the entire
stack !

3. Affected products

Avaya Cajun P33xT , P33xT-ML and more ?

4.Solution

Actually in the product house for Avaya.

With other switch, we know that you can bypass this hole by activate a
'untagpvidonly' command on the ports 1 et 2
or something equivalent according to constructors ...

In trunk mode or in full 802.1q mode, we can do the 'same' thing by
simply tagging frames from your PC.
So, you are in telephony vlan ...

We are also interesting in deployment experience and the response about
fully tagging ports or not ...

thanks,
loic