In message <3.0.5.32.20021120170905.00856e30@pop.xs4all.nl>, Rogier Krieger wri
tes:
>Hello everyone,
>
>Reading the SA, I wonder whether the problem mentioned in the
>advisory can cause the regular NetBSD ftpd to dump core.

I don't think so.  The problem that is fixed is a threat to firewalls, 
nothosts.
>
>Twice now, the security report informed me of ftpd.core files in the
>system's root directory. My connection logs tell me that, in both
>cases, the remote connection comes from a source unknown to me
>(somewhere in France). None of my registered users - I don't allow
>anonymous access - seem to be responsible for these connections, they
>seem to be probes or port scans. In my message logs, I cannot find
>any odd information regarding ftpd connections or troubles
>experienced by the system as a whole. Only the connections and times
>on the core dumps coincide; that's all I have for data. I hope it's
>not too thin for 'evidence'.

That's very bad...  *Nothing* should make the server dump core; if it 
can, I'd worry that there's a buffer overflow or some such, and that 
someone is trying to exploit it.
>
>Trying to debug the core dumps, gdb tells me they are not in a format
>my gdb recognises. Gdb itself is prepared for 'i386--netbsdelf' on my
>system. When using less to dig through the core dump, I find far too
>much information I that makes me nervous. The file seems to contain
>the contents of the master password database, among others. This
>could of course be regular behaviour for a server running on port 21,
>but it makes me hesitant to send out any core dumps to the list.

The master password database isn't unreasonble -- if people are logging 
in with real passwords, those need to be checked.  The presence in the 
core dump of such data suggests that the prober is at the least trying 
to log in, and possibly succeeding.

My guess is that there's a real security problem here, and that someone 
should pay a lot of attention to those core dumps.  (Unless, of course, 
they're caused by bad memory or some such...)


		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com ("Firewalls" book)