On Thu, 8 Apr 1999, Mark Crispin wrote: > We thought these claims required a response from us since they contain > misleading information and only about 20% fact. And by the way, we were > not contacted before this post was made to BUGTRAQ, as protocol states. > > The impact is only with the standard UNIX format. > > The buffer overflow claim, and in particular the alleged root compromise, is > bogus. The process is not root when mailboxes are open; nor can it get root > back. He is confused by the SVR4 semantics of UID; the caveat about the > real UID does not apply to root processes doing setuid(). > > The maximum exposure is that one byte of stack frame may be set to zero, > because of a "buf[x] = 0" for a stack buffer of length x. This may cause a > SEGV; more likely it will just clobber a variable that isn't used after that > point in the function anyway. It is not possible to write something else, nor > is it possible to write at any other location. > > In other words, this "buffer overflow" bug is just an ordinary bug. It > doesn't happen unless the software is abused, and even may be totally harmless > depending upon the code that your C compiler generates. It is *NOT* a > security bug in the normal sense. > ALL ABOVE IS TRUE ONLY FOR PINE, NOT FOR PINE COMPOONENTS (as ipop3d or imap, which is also vulnerable to semilocal buffer overflow that allows any user to read /etc/shadow). I tryed to explit pine, ipop3d [POP3 3.3(20) w/IMAP2 client (Comments to MRCat_private)] and imap [IMAP2bis Service 7.8(100)]. 1) I could not execute any code using pine although gdb shows I overwrited stack ret and ip register points to what I want. 2) I could read /etc/shadow exploiting ipop3d. 3) I could read /etc/shadow exploiting imap. > 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. > True. > 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. > It is true only for pine itself, and I think it shoud be fixed at all. -- ___________________________________________________________________________ M.C.Mar An NT server can be run by an idiot, and usually is. emsiat_private "If you can't make it good, make it LOOK good." - Bill Gates Moze to nie miejsce, ale tak np. programy M$ to swoiste pomniki glupoty.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:41:51 PDT