You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brian Behlendorf <br...@hyperreal.org> on 1998/05/11 23:04:23 UTC

1.3b7

I want us to release a 1.3b7 soon.  From the STATUS file:

> FINAL RELEASE SHOWSTOPPERS:
>
>    * Someone other than Dean has to do a security/correctness review on
>      psprintf(), bprintf(), and ap_snprintf().  In particular these routines
>      do lots of fun pointer manipulations and such and possibly have
overflow
>      errors.  The respective flush_funcs also need to be exercised.
>       o Jim's looked over the ap_snprintf() stuff (the changes that Dean
>         did to make thread-safe) and they look fine.

My wife, Laura LaGassa, worked at AT&T on their C compilers for a few years
right out of college.  She had a look at the various printf functions this
weekend, and based on three hours of walking through the code (which she's
never looked closely at before) and drawing diagrams of buffers and the
like didn't find anything obviously wrong with the code (including
ap_vformatter and the flush functions), though she did miss the fix just
posted by Martin.  

Since we don't have a firm way of determining when to close this issue, I
would like to move it off the showstopper status but still leave it as an
open issue.  Anyone opposed to this?

> WIN32 1.3 FINAL RELEASE SHOWSTOPPERS:
>
>     * SECURITY: check if the magic con/aux/nul/etc names do anything
>         really bad

Discussion on this died down; when we last left it, I wondered aloud
whether the device-checking patch which was applied last week solved this
problem.  This problem continues to exist in theory only - so far no one's
demonstrated a  concrete example of where the current code has problems.  I
would like to demote this to an open issue, to be reinstated when someone
demonstrates a problem.  Anyone opposed?

>    * SECURITY: numerous uses of strcpy and strcat have potential
>        for buffer overflow, someone should rewrite or verify
>        they're safe

Ben did some protection around the strcpy and strcat uses in util_win32.c.
There are some other unprotected places in that code, and in readdir.c, but
those uses appear to be covered by proper memory allocation.  I move that
this be demoted to an open issue.  Again, let me know if you're opposed. 

If these three issues are handled as I suggest, then I would like us to
release 1.3b7 tomorrow evening as a Release Candidate for 1.3.0.

	Brian


--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
pure chewing satisfaction                                  brian@apache.org
                                                        brian@hyperreal.org

Re: 1.3b7

Posted by Ben Laurie <be...@algroup.co.uk>.
Brian Behlendorf wrote:
> > WIN32 1.3 FINAL RELEASE SHOWSTOPPERS:
> >
> >     * SECURITY: check if the magic con/aux/nul/etc names do anything
> >         really bad
> 
> Discussion on this died down; when we last left it, I wondered aloud
> whether the device-checking patch which was applied last week solved this
> problem.

Ah, yes - I was halfway through testing that, when I suddenly had to
spend my time making the blasted thing work instead. By the time I had
finished I'd forgotten why I was doing it.

>  This problem continues to exist in theory only - so far no one's
> demonstrated a  concrete example of where the current code has problems.  I
> would like to demote this to an open issue, to be reinstated when someone
> demonstrates a problem.  Anyone opposed?
> 
> >    * SECURITY: numerous uses of strcpy and strcat have potential
> >        for buffer overflow, someone should rewrite or verify
> >        they're safe
> 
> Ben did some protection around the strcpy and strcat uses in util_win32.c.
> There are some other unprotected places in that code,

Where?

> and in readdir.c, but
> those uses appear to be covered by proper memory allocation.  I move that
> this be demoted to an open issue.  Again, let me know if you're opposed.

Cheers,

Ben.

-- 
Ben Laurie            |Phone: +44 (181) 735 0686|  Apache Group member
Freelance Consultant  |Fax:   +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd,     |Apache-SSL author    http://www.apache-ssl.org/
London, England.      |"Apache: TDG" http://www.ora.com/catalog/apache

Re: 1.3b7

Posted by Martin Kraemer <Ma...@mch.sni.de>.
On Mon, May 11, 1998 at 03:04:23PM -0700, Brian Behlendorf wrote:
> [My wife, Laura LaGassa,] didn't find anything obviously wrong with the code (including
> ap_vformatter and the flush functions), though she did miss the fix just
> posted by Martin.  

No, let's keep the attributions right: Dean found the bug, after I pestered
him long enough with my core dumps ;-)

BTW: no core dumps any more on my server!

> If these three issues are handled as I suggest, then I would like us to
> release 1.3b7 tomorrow evening as a Release Candidate for 1.3.0.

+1 (even though I agree thar another day of "settling" time wouldn't be wrong).

    Martin
-- 
| S I E M E N S |  <Ma...@mch.sni.de>  |      Siemens Nixdorf
| ------------- |   Voice: +49-89-636-46021     |  Informationssysteme AG
| N I X D O R F |   FAX:   +49-89-636-44994     |   81730 Munich, Germany
~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request

Re: 1.3b7

Posted by Dean Gaudet <dg...@arctic.org>.

On Mon, 11 May 1998, Brian Behlendorf wrote:

> > FINAL RELEASE SHOWSTOPPERS:
> >
> >    * Someone other than Dean has to do a security/correctness review on

Yup take that off now.

> > WIN32 1.3 FINAL RELEASE SHOWSTOPPERS:
> >
> >     * SECURITY: check if the magic con/aux/nul/etc names do anything
> >         really bad
> 
> Discussion on this died down; when we last left it, I wondered aloud
> whether the device-checking patch which was applied last week solved this
> problem.  This problem continues to exist in theory only - so far no one's
> demonstrated a  concrete example of where the current code has problems.  I
> would like to demote this to an open issue, to be reinstated when someone
> demonstrates a problem.  Anyone opposed?

I'm not opposed... and I'm the person who put that in the showstopper
list.  (Although you might want to see what happens if you try to use
"AuthFile aux"). 

Dean