Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
Re: ipop3d (x2) / pine (x2)Oliver Xymoron (oxymoronWASTE.ORG)
Sun, 11 Apr 1999 11:00:09 -0500
- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Miguel de Icaza: "Re: ipop3d (x2) / pine (x2) / Linux kernel (x2) / Midnight"
- Previous message: GvS: "Re: ipop3d (x2) / pine (x2) / ..."
- In reply to: Mark Crispin: "Re: ipop3d (x2) / pine (x2) / Linux kernel (x2) / Midnight"
On Thu, 8 Apr 1999, Mark Crispin wrote: > Now, we'll talk about the 20% that is fact. Yes, it is possible to write > a negative process ID in the lock file. This requires that the attacker > have shell access; it can't be mounted remotely. It also requires that > the attacker have a program running at the time that the victim opens his > mail file. Attackers sometimes have shell access. Use your imagination. Attackers can sometimes conceal attempts to exploit races long enough for it to work. Use your imagination. I for one am not always running top. > Not only is the program running, but it has the lock file open and > locked. In other words, it's incredibly easy to catch; particularly > if you have lsof. Nor can there be any question of intent when it > comes to prosecution. Only an extremely stupid individual would try > it. Imagine this scenario. You have a thousand users. One of them is stupid enough to be duped out of their password. Odds? High. Attacker gets in, connecting from a machine that they've already 'owned.' Scenario two. You have a thousand users. One of them uses telnet/pop/imap/etc to connect from a machine through a route that's being snooped from another owned machine. Perhaps they've tunneled through a bunch of poorly maintained UNIX boxes in university dorms and are now on your LAN. Odds? High. Risk to attacker of shell experimentation in the early morning hours? Negligible. Exercise for the reader: invent a scenario whereby an attacker engineers their way into root access by having access to unpriviledged accounts. I can think of five off the top of my head and it's only 11am on a Sunday. In short, own your bugs. There are no trusted users, especially on a networked machine. Users have to be protected from other users. Period. That's the security model. If Pine lets an attacker make progress through a system, that's a security hole _in Pine_. Deal with it. The past few posts to Bugtraq I've seen from the Pine group have rather worried me. Consistently taking a posture of "we don't think it's a problem" or "it's not our problem" does little to inspire community confidence. Your code will have bugs or bad interactions with other programs. They will be found, especially since Pine is popular. Some of them will be posted publically, especially if you don't appear to take a proactive stance. Be gracious about it. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."