Daniel Carosone <[EMAIL PROTECTED]> writes:
>On Mon, Feb 04, 2008 at 02:48:08PM -0700, Martin James Cochran wrote:
>> Additionally, in order to conserve bandwidth you might want to make a
>> trade-off where some packets may be forged with small probability (in the
>> VOIP case, that means an attacker gets to select a fraction of a second of
>> sound, which is probably harmless)
>This is ok, if you consider the only threat to be against the final endpoint:
>a human listening to a short-term, disposable conversation. I can think of
>some counter-examples where these assumptions don't hold:
>- A data-driven exploit against an implementation vulnerability in your codec
>  of choice.  Always a possibility, but a risk you might rate differently (or
>  a patch you might deploy on a different schedule) for conversations with
>  known and trusted peers than you would for arbitrary peers, let alone
>  maliciously-inserted traffic. How many image decoding vulnerabilities have
>  we seen lately, again?
>Particularly for the first point, early validation for packet integrity in
>general can be a useful defensive tool against unknown potential
>implementation vulnerabilities.

This is an example of what psychologists call own-side bias ("everyone thinks
like us"), in this case the assumption that after a peer has authenticated
itself it'd never dream of sending a malformed packet and so we don't need to
do any checking after the handshake has completed.  Why would you trust data
coming from a remote system just because they've jumped through a few hoops
before sending it?  I can steal the remote system's credentials or hijack the
session and then send you anything I want, it's no safer to blindly accept the
data if there's a MAC attached or not.

More scarily, and specifically for the case of VoIP, the security of many SIP
devices is absolutely appalling (for German speakers there's a paper on this
at the DFN-Cert workshop in a few days,
https://www.dfn-cert.de/events/ws/2008/programm.html).  So the obvious attack
vector is to 0wn the peer's SIP device and ensure that it creates malformed
data packets well before the security layer ever takes effect.  As a result
your secured tunnel is pouring out carefully authenticated attack packets as
fast as it can send them.  The bad guys have been exploiting this for years,
spamming their malware out to "trusted" friends on contact lists, and it's
proven quite successful.

Hostile data inside a secure tunnel or wrapper is still hostile data.  As the
OP said, as long as you can deterministically detect attacks (which a 1-of-n
packet MAC will do) you're not giving up much security by not MAC'ing all


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to