OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Bugtraq archives for 2nd quarter (Apr-Jun) 1999: Re: ipop3d (x2) / pine (x2) / Linux kernel (x2) / Midnight

Re: ipop3d (x2) / pine (x2) / Linux kernel (x2) / Midnight

M.C.Mar (woloszynit.pl)
Fri, 9 Apr 1999 13:09:01 +0200 

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 MRCCAC.Washington.EDU)] 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.   emsiit.pl
      "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.