[VOIPSEC] Actual Attacks

[Geoff Devine]

Brian Rosen writes:

> Maybe we can agree on the idea that end devices and proxy
> servers should be immune to attack.  

I'm sure many of us had the mathematics of computation course where we
got exposed to the halting problem.  You can mathematically prove that
you can't write a program that can tell you whether another computer
program will halt.  Similarly, it's impossible to write a computer
program that's immune from attack.  I wish it were possible to build an
end device or proxy server that is immune to attack.  Unfortunately, you
can't.

This is an engineering problem.  It's never going to be perfect.  You
have to decide when the solution is good enough to ship.  In my opinion,
different service providers will have very different metrics on what's
good enough with respect to security.  At one extreme, you have the 3GPP
Wireless and PacketCable people who mandated a paranoid and bomb-proof
architecture.  You'll note that cellular and cable operators have been
dealing with theft of service issues for decades so they're quite
sensitive to security requirements.  On the other extreme, you have
Vonage and Skype where there is little or no security.  I guess you
could put them in the "rapid service creation" camp.  I don't think
there's one right answer and it really depends on which class of service
provider you're talking about.

> When exploits are discovered, devices should be updated rapidly.  

This is not practical.  Let's consider a real-world example:

A top tier cable operator will have millions of MTAs out in the field in
a couple of years.  (An MTA is an MGCP-based VoIP endpoint embedded in a
cable modem).  The software image for the MTA is downloadable.  The
image for a particular vendor product is certified by CableLabs as part
of a structured testing program and the testing typically takes several
months.  The reason you do this is because if you happen to download an
image that turns millions of MTAs into doorstops, you have to do
millions of truck rolls to field swap these devices.  You spend $100 per
MTA so this is a several hundred million dollar oops.  Your customer
base is up in arms and switches to DirectTV, DSL, and ILEC wireline so
your stock price plummets.  The person at the cable operator who
authorized the quick fix software patch is living in a cardboard box,
pushing a shopping cart, and collecting cans.

A cable operator had exactly this scenario happen a couple of years ago
with proprietary digital set-top boxes.  It was a very costly mistake.

> Firewalls are likely to be deployed as a check against such
> hardening, and may provide some protection when devices are
> not updated.

In terms of network operations, it's far easier and less risky to
live-update firewalls and/or SBCs than endpoints.

> Such firewalls should not interfere with "normal" communications.

I guess it depends on what you mean by "normal".  If you look at a
typical telecom protocol designed to be run by untrusted endpoints like
ISDN, the philosophy is to be very exacting about the PDUs that you
allow to enter your network.  Every information element within the PDU
is checked in detail.  If anything is out of the ordinary, the message
is ignored or rejected.  In most implementations, 95% of the code
performs error checking and there are conformance tests to verify that
all the error checking is implemented.  This prevents the endpoint from
damaging the network.  From years of building comms gear, I've learned
that more often than not, the first time you interop with a new device
or network, somebody crashes or at least fails in some horrible way.
When you open up the possibility of a PC being able to send messages
into a network, you are vulnerable to an attack where completely valid
signaling messages crash some network element.  Once again, I think it's
up to the service provider to decide how tight their policy should be.
You have the IETF way where pretty much any message will get through the
firewall.  You have the ITU way where only messages that conform to a
known profile get through the firewall.  As a service provider, I'd like
to have knobs on my firewall and/or SBC where I can tighten down the
policy if I need to.

Geoff