[bittorrent] BT, Nats, and hackers at the door...

Konstantin 'Kosta' Welke kosta at fillibach.de
Mon May 30 19:48:46 EDT 2005

On Mon, 30 May 2005 10:47:54 +0200, Bill Cox <bill at viasic.com> wrote:

> I'm just fooling around with ideas for helping make p2p traffic more
> secure.  For example, if a large respected company like Cisco comes out
> with a popular internet phone, and all I have to do is plug it in, it's
> likely to be hard to hack.

You would think so. When Cisco IP Phones came out, they were pretty
insecure. Cisco is fixing that more and more, but when they first
came out, and you played with them: Oh, port 80 is open, lets
connect, oh the phone crashed. :(
Something else was
(just a sidenote to show that security is something everyone can
mess up. lets not start a discussion about cisco voip, please!)

> Is it possible to get the same level of
> security with a Linux or Windows box that provides phone service, or do
> all those moms out there have to go out and buy dedicated hardware for
> each p2p service they want?

Depends. Of course if you hack something together in C, chances
are, theres a security flaw somewhere. But if you plan well, and
maybe use a more 'secure' language like Ada maybe, it might be
much more diffucult to find a hole. (Disclamer: I am neither a security
engineer nor do I have any Ada coding experience)

In both cases, an 'appliance' is not any safer than a software
running on a desktop. In contrary: On the appliance, some old version
of Linux or BSD could run, with old, unpatched security holes open.

> Here's one dumb idea... in the chip-design world, we have written
> programs that double-check that our chips do what we think they will do.
> There are LVS (layout vs. schematic) programs that make sure that the
> chip was implemented according to a schematic spec.

Yes, there are approaches to that, but you typically need a language
that helps you check your code. Try to do a formal proof of a
C program ;)
More info can be found at
and maybe
(but both articles are a bit short)

> Would it be possible to do the same thing for a p2p protocol?

Well, model checking (or theorem proving) over a protocol like
bittorrent wouldnt make much sense, in my opinion, because the
protocol is simple enough to know what it does, anyway. The
problem would be security flaws in the application, which are
hard to detect.

> Could Linux/Windows be
> enhanced so that I could specify the restrictions of a newly installed
> package?

There is some progress going on here, look for Mandatory Access Control.
The problem is that, as far as I know, theres really not many applications
that use that 'by default'. One problem propably is that there are many
different flavors of that which need to be standardized (my guess).

> It's possible that when IPv6 is well established, average mom will be
> buying a stateful router rather than a NAT, but I'm not so sure.
> Dynamic IPs and NATs are two more levels to help protect the end-user
> from hackers, and I'm concerned that ISPs will keep them in place even
> with IPv6.

The "security" of a NAT is nothing more that "dont let any new connections
in". Thats what a statefull firewall can do, too. (Also by default, if
its shipped that way). In a NAT, you can open ports with some effort,
for most of these so-called "desktop firewalls", this is much easier.

>> What's the vulnerability of open p2p ports?
> I think all open ports are potentially dangerous, not just p2p ports.
> However, the current trend is to close off all ports of home users (with
> NATs), and to make their IPs dynamic.  I'd like to see average mom able
> to receive direct p2p calls or e-mails from the internet without having
> to configure a router, pay her ISP more money, or take any additional
> risk.  Is it possible?

Depends :)
First, what is the danger of an open bittorrent port compared to
ssh or mail?

ssh could be compromized by "password guessing" (if passwords are
enabled). smtp (if open to the internet) is, if not protected
correctly, a big no-no. look for "smtp open relay". If protected
by smtp-auth or smtp-after-pop or something, you shift the
problem to password guessing, again.
bittorrent doesnt use any passwords or authentication, so theres
no problem here.

Then theres security holes like buffer overflows, etc. which are
mostly "coding errors". They could simply crash the application
or be used to gain access to the system. This is the "real danger"
for bittorrent. Here, we'd need a formal verification of the
bittorrent code to be sure. (which is a lot of effort... see above)
But then, The firewall that protects you could have a buffer overflow
vulvernability. Or your linksys router. Or your operating system
kernel. Or whatever.

Bottom line: you can replace your NAT with a statefull firewall.
If you're an os vendor, you can ship your system with an enabled
statefull nat by default (which is what they do these day), which
should be just as secure. If you open ports, in both the NAT and
the firewall case, the server which listens on that port may
have security issues.


More information about the BitTorrent mailing list