On Tue, 13 Jul 1999, Niall Smart wrote:
> "Brian F. Feldman" wrote:
>
> > On Mon, 12 Jul 1999, Sheldon Hearn wrote:
> > > On Sun, 11 Jul 1999 12:47:30 MST, Doug wrote:
> > >
> > > > Finally, Brian might want to search the bugtraq archives before
> > > > he commits anything. There have been quite a few identd related
> > > > discussions, and it would be points in our favor if we didn't come out
> > > > with anything that had known exploits.
> [snip]
> >
> > It's "out with the bad, in with the good." Pidentd code is pretty terrible.
>
> Agreed, nobody wants a monstrosity of an ident daemon in the base
> system.
>
> > The only security concerns with my code were wrt FAKEID, and those were
> > mostly fixed (mostly meaning that a symlink _may_ be opened, but it won't
> > be read.)
>
> Your code is still insecure, I can still obtain 16 characters of the
> first line of any file in the system just by symlinking to it. I
> don't see how you expect your checks to defeat that. What you should
> do is setgid && setuid to the user returned by net.inet.tcp.getcred
> immediately after doing the sysctl.
Actually, I need to seteuid and setegid, because a setuid/setgid gives the
user access to ident's process space. Anyway, I just forgot to upload the
latest version of the patch. I also nuked it on MY system :/ But I just
rewrote it (a bit better, too.) It's updated on freefall now.
>
> Or even better take out this FAKEID stuff.
I'd rather keep it in, non-default, and semi-supported.
>
> > If anyone wants to audit my code for security, I invite them to.
> > But frankly, I highly doubt anyone will find anything to exploit.
>
> Heh, famous last words.
Is this my last stand?
>
> > And, why would bugtraq advisories against other identds apply to my
> > ident_stream service? This is an entirely different code base.
>
> That doesn't matter, different programmers make the same mistakes
> and assumptions when solving the same problem (there is research
> into the effectiveness of N-way programming which shows this) and
> many attacks are against subtle implementation mistakes which you
> may also make.
Ahh, but I don't make assumptions on input. I know that anything can happen.
so prepare for the worst. Most mistakes are made by programmers when they
assume that all input is safe. *
>
> Regards,
>
> Niall
>
Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___
[EMAIL PROTECTED] _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve! _ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
* exploitable security holes
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
