On Jul 3, 4:26am, Andrew McNaughton (possibly) wrote:
> >Eh? If ssh/smtp/inetd bind to the port you won't be able to, no
> >matter how often you try.
> Unless the server is restarted for some reason. hence the rapid cron job
> which will eventually succeed if not detected first.
Quite; sorry I wasn't clearer, but I forgot that others might not
realize that. Notice, for instance, that named comes with a script for
such restarting - implying there's a frequent enough need for such
that it's likely to come up. (It's also the case that currently
sendmail and some other stuff gets started _after_ cron, but that can
be taken care of via rearranging the /etc/rc.* files.) Another example
is squid, which can be run as a http accelerator; it comes with a
RunAccel script that restarts squid whenever it crashes - and crashes
could be induced by an attacker.
> >And you won't be able to steal keys
> >by hijacking sshd.
> If the trojan gets to tell the other end what public key to use,
> then of course it can get at the data stream. This is equally true
> with routing/man-in-the-middle attacks. Without access to
> master.passwd though it can't do a very good job of masquerading as
> an authentication agent. It will fail to emulate any authentication
> unless that can be done by accepting any connection regardless. I
> don't know enough about the authentication systems ssh uses to know
> which if any are vulnerable here.
All it has to do to act as an authentication agent for password
sniffing purposes is use telnetd or login. One ssh mode is to
essentially act as an encrypted telnet, with normal password authentication.
Allen Smith firstname.lastname@example.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe security" in the body of the message