[DGD] Changing connect() (network package)

[bart at wotf.org]

On Sat, 29 Dec 2007 23:22:57 +0100, Felix A. Croes wrote
> bart at wotf.org wrote:
> 
> > > Not really.  You can let it log on to a special port that is only opened
> > > on localhost and has its own connection protocol. 
> >
> > Making it obscure doesn't make it secure. Requiring a localhost connection
> > isn't too helpful in a world where shared hosting is rather common for muds.
> > limiting connections to localhost isn't a good enough security measure for
> > database servers either.
> 
> A localhost connection ensures that attacks have to be local -- a rather
> important qualification in a threat analysis.

It reduces the threat, yes.

> 
> It also has nothing whatsoever to do with "security through 
> obscurity". :-)

Oh, the 'own connection protocol' was quite an security through obscurity
argument.

> 
> > > Authentication could
> > > be done using a one-time password (especially since there is no 
> > > person, but a program on the other side) if you are especially 
> > > concerned about security.
> >
> > One way or another, the external daemon will have to get that password and use
> > it to authenticate at some point.
> 
> But as a one-time password, it cannot be re-used in an attack.

No, but if it gets caught before use, it is still vulnerable, and as an added
bonus can be used to deny service to the connection daemon.

> 
> >[...]
> > If you put a 3rd party in the middle, as is the case with an external
> > connection daemon, you create a staging point for man in the middle attacks.
> 
> Then again, if you were to integrate this vulnerable external connection
> daemon with DGD, DGD itself becomes a staging ground for attacks!  Another
> score against the networking package.

If DGD is the target of the attack, then it helps that I don't have yet
another thing to watch, and can concentrate my attention on one thing.

See, I know you don't like outgoing connections, and I agree with the basic
permise that having guest coders being able to make arbitrary outgoing
connections is just a really bad idea.

That said, you know as well as I do why I pointed at hname.

DGD initiates outgoing traffic and has done so for quite some time, this in
order to do hostname lookups.

It serves a purpose, a good one really, and it doesn't allow arbitrary
outgoing connections.

So, the issue is really not initiating outgoing traffic, DGD does that today.
The issue is preventing random guest coders from abusing this.

Securing outgoing connections on the lib level at least to the point of not
allowing random guest coders access to them is no more difficult then
protecting file efuns such that those random guest coders can't just write to
your system files.

That said, I can understand why you don't like them, but I can't see any
argument as to why an external connection service is a good solution for this
since it only adds more potential security problems and does not solve a
single one.

> 
> Only local connections, not external ones?  Is this something particular
> to Windows hosts?  In a Unix environment, only the super-user can snoop
> connections (local or otherwise), in which case all bets are off.

I don't use Windows so I wouldn't know. External connections are just as
vulnerable to snooping, if not more so.

If someone has root on your host all bets are off indeed.

If someone is a normal user and can still connect to your local port and act
as your connection daemon, all bets are off as well.

Bart.
--
Created with Open WebMail at http://www.bartsplace.net/
Read my weblog at http://soapbox.bartsplace.net/