On Tue, 7 Sep 1999, Drew Smith wrote:
> Security is so incredibly crucial in this project - I can't express
> it. Am I missing something large or small here? If someone were to
Telnet and telnetd should be fairly easy to pare down to absolute minimum
functionality. If I had to support telnet, I'd sure want to run a really
minimal implementation of both the client and the server.
> I'm not looking for source to exploits, nor "This is how you hack
> it..." - if anyone knows of anything along these lines, I'm more looking
> for "Users can write or read to a file using the <something> function;
> disable it.".
Support only vt100, hard code the stuff, remove the environment variable
code, check for buffer overflows in DNS, telnet option negotiation, etc.
Instead of setting the shell, why not have a cut down version of sshd
that only launches the modified telnet client? Run them on different
ports for each internal host, then there's no parameter passing at all
going on.
There's no telling what's been implemented in telnet for any given OS,
it's much better to hack out large chunks of code than to take the
chance. If you can limit things so that nothing gets passed or
negotiated, then you're two steps ahead of the game. Trusting normal
daemons, shells, login processes, etc. seems rather like adding a lot of
unnecessary software to the mix. Staticly link everything, compile it
all with stackguard, etc.
You might want to try to find an older set of telnet/telnetd with fixed
terminal stuff to start on. I suppose some of it depends on what you
have to support display-wise.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
PSB#9280
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
