Re: In-band signalling (was: Re: NuralStorm Webmail Multiple Vulnerabilities)

[Dan Kaminsky <dan () doxpara com>]

Out of band signaling can be made to work in small networks. In larger  
networks and systems, the problem is -- what makes you think you have  
simply two planes?  We call them n-tier, not 2-tier after all.

And nobody tunnels like telephony guys. If they ain't encapsulating,  
they ain't living.

So the game, as I see it, isn't to demand out of band operations. The  
game is to engineer systems that can strongly maintain separation  
between contexts, in band. Theoretically, nested TLV protocols would  
do this, but I think we've had enough malloc-external-length-memcpy- 
internal-length bugs to show, practically, it doesn't work.

I'm having some good experiences with protocols that move around  
Base64-encoded blocks. The key is to not encrypt the block, because  
man, you're never finding the key during debug.  Even then, it's being  
an interesting challenge to make standard tools unpack for debugging.   
No debug, no deploy.


On Jul 17, 2010, at 2:41 PM, Pavel Kankovsky <peak () argo troja mff cuni cz 
> wrote:

> On Thu, 15 Jul 2010 Valdis.Kletnieks () vt edu wrote:
>
> > > (*) In-band signalling in telephone networks.
> > Feel free to elucidate a *feasible* way to have deployed out-of-band
> > signaling on the installed copper-pair base back then.
>
> I won't pretent I am an expert on PSTN technology. Nevertheless
> frequency-division multiplexing was already in use in 1950s so I do  
> not
> find the idea of literal out-of-band signalling (i.e. to make the  
> bandwith
> of trunk link channels slightly wider than what is allowed to come  
> from
> local loops and use that extra bandwidth for signalling) completely
> implausible.
>
> > Also, compare the *actual* costs and losses due to phreakers snagging
> > free service due to in-band signaling to the eventual cost of  
> > upgrading
> > every single central office to something that supported out-of-band.
>
> This smells like a red herring. They had to upgrade all of them to  
> support
> direct distance dialing in the first place and there have been more
> upgrades not related to the eventual widespread deployment of SS7 in
> 1990s.
>
> > Maybe those bell-heads weren't so dumb...
>
> That was not my point.
>
> It might have paid off to accept the risk of abuse when hardware was
> crude and expensive and when knowledge and gear needed to exploit the
> vulnerability was not easily available. Although I suspect it was more
> a case of being lucky enough to get away with a lack of foresight than
> a deliberate risk management decision.
>
> But it is 2010 now. Everything I mentioned earlier has changed years  
> ago.
> Hardware is incredibly more powerful and much cheaper. Every kiddie  
> has
> got a PC and high-speed Internet connection. All knowledge is one  
> Google
> search away (okay, I am a little bit exaggerating here). Yet the old  
> 2600
> Hz whistle lives on in apostrophes and less-than signs because we  
> still
> have not learned to keep control data and user data segregated.
>
> -- 
> Pavel Kankovsky aka Peak                          / Jeremiah  
> 9:21        \
> "For death is come up into our MS Windows(tm)..." \ 21st century  
> edition /
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/