<[EMAIL PROTECTED]> <[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on 
Tue, Mar 19, 2002 at 11:19:01PM -0600

On Tue, Mar 19, 2002 at 11:19:01PM -0600, Randall Gellens wrote:
> At 6:04 PM -0600 3/19/02, Randall Gellens wrote:
> >  This appears to be an edge condition; it does not occur with 2148 
> > characters, for example.  (Which explains why my buffer-overrun 
> > test utility didn't see any problem.)  When the input buffer fills 
> > up with junk and no CRLF in sight, Qpopper goes attempts to read 
> > and discard network input until either it stops or it sees a CRLF. 
> > Unfortunately, if the buffer is exactly full (an even multiple of 
> > 2048), it does a read with length=0, which of course returns with a 
> > 0 result.  The code then loops, asking for and receiving zero 
> > bytes. I'm working on a fix.
> 
> The cause isn't as simple as that, sorry (which I realized as soon as 
> I sent the message).  It doesn't loop for me on some systems (such as 
> OpenBSD 2.9) with inputs that aren't an even multiple of 2048.  It 
> also doesn't loop for me at all (with any size input) on some systems 
> (such as Darwin/MacOS X).

  I assume you've been given details on the exploit, right?

  I don't remember all the details, but I think there is a subtle
difference in how *BSD-derived Unixes handle reads on file handles
after EOF is reached, vs. how SysV-flavored Unixes do it, and that may
be triggering the bug (or maximizing its impact, at least) on some
systems.  Note that because this is an undefined situation in that it's
an invalid action by the caller, its behavior is probably unspecified
by POSIX and similar standards and hence different systems are free to
behave differently.

  However, I think it's pretty certain that the "break;" for length <=
0 in that inner loop in getline() is breaking to the wrong place,
because it looks to me like it is not guaranteed to exit the routine if
the read returns 0 bytes *or* returns a -1 for error.

  -- Clifton

-- 
    Clifton Royston  --  LavaNet Systems Architect --  [EMAIL PROTECTED]
"What do we need to make our world come alive?  
   What does it take to make us sing?
 While we're waiting for the next one to arrive..." - Sisters of Mercy

Reply via email to