Re: DoS/exploit affecting ipop3d??? [Revised with new info]

[Mikael Fors <mf () MORADATORER SE>]

Earlier this week I posted about this problem with ipop3d, and I have further information now. It seems that the remote 
sites seemed to be able to connect, but even with mail in the queues to be fetched with pop3, no communication occured. 
(I'm also aware of the Microsoft pop3 client bugs, so it was nothing new in that...)

Feb 12 07:50:22 ns ipop3d[19162]: Command stream end of file while reading line user=??? host=[192.168.130.154]
Feb 12 07:50:40 ns ipop3d[19164]: pop3 service init from 192.168.130.100
Feb 12 07:50:59 ns ipop3d[19161]: Login user=jan67p8 host=[192.168.8.163] nmsgs=0/0
Feb 12 07:50:59 ns ipop3d[19161]: Logout user=jan67p8 host=[192.168.8.163] nmsgs=0 ndele=0
Feb 12 07:52:00 ns ipop3d[19164]: Login user=per68p8 host=[192.168.8.165] nmsgs=0/0
Feb 12 07:52:00 ns ipop3d[19164]: Logout user=per68p8 host=[192.168.8.165] nmsgs=0 ndele=0
Feb 12 07:52:27 ns ipop3d[19168]: pop3 service init from 192.168.130.100
Feb 12 07:52:44 ns ipop3d[19169]: pop3 service init from 192.168.130.100
Feb 12 07:53:31 ns ipop3d[19167]: pop3 service init from nnn.nn.nnn.nnn

Anyway, there's a ipop3d race occuring when this happens. After a while, i had about 40 active ipop3d active, and 
seemingly running, with no answer from any of them. I actually believe it's a bug, and not something exploited or 
something. Did a quick check with MD5 checksumming of executables on the readonly mountimages from jaz, but found no 
evidence whatsoever of tampering (checked for filesystem tampering too, nothing. Nada. Niente.). Checked timestamps of 
possible compromized files, but nothing. Unless the <not so probable> hacker must have been very experienced, I simply 
have to conclude this is a combination of errors, causing the trouble. (Remember, tripwire reported no anomalies 
whatsoever in the system. Could be a faulty disk, since I got a lot of e2fsck errors on reboot, or a bad memory 
module... (or the solar spots affecting australian ants way of building, because the lightbulbs started emitting gamma 
radiation when turned on at a specific timegap causing intervention with the nearest black hole available....)

Revised the running spare system and went to xinetd, just in case anyway, and refreshed the ipchains structure to avoid 
possible loopholes. Since the pop3 comms run clear text, all mailbox pop3 users don't have shell access, and no signs 
of logins except authorized users through console or ssh.

Anyway, going to rebuild the main system from scratch, and strip it of everything not needed for the purpose of the box 
(mail+squid+ip-masq+ssh2), and see what happens. Right now, the spare running same config except from xinetd-way, works 
like a charm, just like the other box did for several months before the pop3 race...

Or, there's been a very cunning person inside the system, who have hidden the tracks so carefully that he's a true 
master...

Yours (but with two new grey hairs)

Mikael Fors
Networked Systems Professional
Mora Datorer AB