>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.
>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.
>I still agree with you for other reasons though, if an attacker
>creates a new service people might use it even though it isn't a
>legitimate service setup my the sysadmin.
>
>Whats wrong with a /dev/socket/tcp/XYZ acl type scheme? If the
>process has permission to read /dev/socket/tcp/83 then they can
>bind to port 83, you could make it a procfs type filesystem so all
>the ACL information was in memory for speed. Then you've got to
>save/restore state though.
>
>Niall
I don't know enough about TCP/IP details to know if this makes sense, but
perhaps you could use these as more than just flags and allow programmers
to bind to the socket by just opening the appropriate device file. ie
#!/usr/local/bin/perl
open (SMTP, "</dev/socket/tcp/25");
I'm not sure if that could work with sockets. I'd be interested if someone
more knowledgeable could comment on this.
Andrew
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The effort to understand the universe is . Andrew McNaughton
one of the very few things that lifts . ++64 4 389 6891
human life above the level of farce, . . andrew@squiz.co.nz
and gives it some of the grace . http://www.squiz.co.nz
of tragedy - Steven Weinberg . http://www.newsroom.co.nz
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe security" in the body of the message