[VOIPSEC] Actual Attacks

[Brian Rosen]

Agree that we can never achieve perfection, but you can set your goal that
high and measure how far off you are.  Brings to mind a story from the
legendary quality guru W. Edwards Deming about setting zero defects as your
goal.  His example was "how many babies is a nurse allowed to drop?"  It
clearly happens, but the only acceptable specification is zero.

Updating devices rapidly is happening.  Look at what Microsoft is doing with
its products.  I have an interesting "Smart Phone" which gets automatic
"Over the Air" updates.  We have to get used to the fact that hackers are
getting good at exploiting bugs, and middlebox enforced fixes don't
adequately address end device shortcomings.  I don't see the end of
middleboxes, but they are not the answer.  End devices need to be designed
to be updated rapidly in the field.  There are reasonable techniques to
allow rollback of versions when poor QA results in the fix being worse than
the problem.

The speed at which updates are approved is proportional to the threat.  When
there is a large threat, people move fast.  When there is less of a threat,
they move slower.  I'll agree that there are differences among providers
when the threat is minor.  As with Microsoft, we're all learning to react
more quickly to substantial threats.  That includes the QA group.  If it
takes 30 days to run through tests, and you have an attack that is taking
subscribers down now, you have a BIG problem, and the answer is not to wait
30 days.  We have to make our QA systems react better to the threats we face
(or come up with ways to never have the kinds of bugs that are being
exploited).

I don't agree with your analysis of vulnerabilities in protocol design:
> 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.

That's simply untrue.  The specifications for each are about as exacting as
the other with respect to "legal" messages.  They have stylistic
differences, but in practice, the differences do not change the ability of a
firewall to detect a "good" from a "bad" PDU.  I don't see firewalls going
away, but I see them having less and less relevance to the actual threats.

Brian


> 
> -----Original Message-----
> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
> Behalf Of Geoff Devine
> Sent: Monday, February 28, 2005 6:41 PM
> To: Voipsec at voipsa.org
> Subject: RE: [VOIPSEC] Actual Attacks
> 
> 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
> 
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>