brk() bug

brk() bug

[Matthew Galgoci]

Given the recent local root expoit in the Linux kernel, I would like to schedule a downtime
of two hours where I can boot sources.redhat.com from rescue media and check the machine over
by hand for potential compromise.

At that time, I would also like to update sources.redhat.com to the latest errata kernel, and
also check if any additional updates are required, and if there are any critical updates, apply
them.

I propose tomorrow evening (2003/12/03) at 7pm EDT lasting until 9pm EDT. If anyone has any 
objections please speak now or forever hold you peas. And if you do object, please propose an
alternative time, don't just complain.

Regards,

Matthew Galgoci

-- 
Matthew Galgoci
System Administrator
Red Hat, Inc
919.754.3700 x44155

Re: brk() bug

[law]

In message <Pine.LNX.4.44.0312021420080.1279-100000@lacrosse.corp.redhat.com>, 
Matthew Galgoci writes:
 >
 >Given the recent local root expoit in the Linux kernel, I would like to
 >schedule a downtime of two hours where I can boot sources.redhat.com from
 >rescue media and check the machine over by hand for potential compromise.
 >
 >At that time, I would also like to update sources.redhat.com to the latest er
 >rata kernel, and also check if any additional updates are required, and if
 > there are any critical updates, apply
 >them.
Sounds good to me.

jeff

Re: brk() bug

[Christopher Faylor]

On Tue, Dec 02, 2003 at 02:27:36PM -0500, Matthew Galgoci wrote:
>Given the recent local root expoit in the Linux kernel, I would like to
>schedule a downtime of two hours where I can boot sources.redhat.com
>from rescue media and check the machine over by hand for potential
>compromise.
>
>At that time, I would also like to update sources.redhat.com to the
>latest errata kernel,

I am rebuilding the latest kernel now.  I've been waiting to show up
since I heard about its availability.

>and also check if any additional updates are required, and if there are
>any critical updates, apply them.

HUH?  Why would there be critical updates required?  Are you assuming
the system is unmaintained?  That's odd.

cgf

Re: brk() bug

[Joseph S. Myers]

On Tue, 2 Dec 2003, Christopher Faylor wrote:

> >and also check if any additional updates are required, and if there are
> >any critical updates, apply them.
> 
> HUH?  Why would there be critical updates required?  Are you assuming
> the system is unmaintained?  That's odd.

There's been at least one instance where a (not quite so critical)  
security problem was pointed out with no response
<http://sources.redhat.com/ml/overseers/2003-q2/msg00243.html> and with a
subsequent reminder
<http://sources.redhat.com/ml/overseers/2003-q2/msg00259.html> and
identification of fixed version
<http://sources.redhat.com/ml/overseers/2003-q2/msg00260.html>, also with
no response.  This bug (anoncvs can create and delete tags) is still
present.  Updates can easily fall through the cracks.

-- 
Joseph S. Myers
jsm@polyomino.org.uk

Re: brk() bug

[Jason Molenda]

On Thu, Dec 04, 2003 at 12:05:47AM +0000, Joseph S. Myers wrote:

> no response.  This bug (anoncvs can create and delete tags) is still
> present.  Updates can easily fall through the cracks.


Our cvs server is a special case - we have a few local modifications
that take time to merge in, and no one has had the time to do that
merging.

I'm hard pressed to think of any other software we've modified on
the system to this extent.

Jason

Re: brk() bug

[Christopher Faylor]

On Wed, Dec 03, 2003 at 04:09:05PM -0800, Jason Molenda wrote:
>On Thu, Dec 04, 2003 at 12:05:47AM +0000, Joseph S. Myers wrote:
>>no response.  This bug (anoncvs can create and delete tags) is still
>>present.  Updates can easily fall through the cracks.
>
>Our cvs server is a special case - we have a few local modifications
>that take time to merge in, and no one has had the time to do that
>merging.
>
>I'm hard pressed to think of any other software we've modified on the
>system to this extent.

This is one reason why I've been moving away from customized software on
the system so that I can let RHN tell me when something needs to be
updated and update it quickly.  CVS is, as Jason knows, one major
problem.

Re: brk() bug

[Christopher Faylor]

On Wed, Dec 03, 2003 at 08:32:16PM -0700, law@redhat.com wrote:
>In message <20031203160905.A55970@molenda.com>, Jason Molenda writes:
>>On Thu, Dec 04, 2003 at 12:05:47AM +0000, Joseph S.  Myers wrote:
>>>no response.  This bug (anoncvs can create and delete tags) is still
>>>present.  Updates can easily fall through the cracks.
>>
>>
>>Our cvs server is a special case - we have a few local modifications
>>that take time to merge in, and no one has had the time to do that
>>merging.
>>
>>I'm hard pressed to think of any other software we've modified on the
>>system to this extent.
>
>The second largest subsystem that is customized would be the mail
>system.  But I've been pretty happy with the security of qmail :-)

qmail isn't that customized.  It has some known well-maintained patches
but nothing home grown, like CVS.

cgf

Re: brk() bug

[law]

In message <20031203160905.A55970@molenda.com>, Jason Molenda writes:
 >On Thu, Dec 04, 2003 at 12:05:47AM +0000, Joseph S. Myers wrote:
 >
 >> no response.  This bug (anoncvs can create and delete tags) is still
 >> present.  Updates can easily fall through the cracks.
 >
 >
 >Our cvs server is a special case - we have a few local modifications
 >that take time to merge in, and no one has had the time to do that
 >merging.
 >
 >I'm hard pressed to think of any other software we've modified on
 >the system to this extent.
The second largest subsystem that is customized would be the mail system.
But I've been pretty happy with the security of qmail :-)

jeff

Re: brk() bug

[law]

In message <20031204010635.GA14702@redhat.com>, Christopher Faylor writes:
 >On Wed, Dec 03, 2003 at 04:09:05PM -0800, Jason Molenda wrote:
 >>On Thu, Dec 04, 2003 at 12:05:47AM +0000, Joseph S. Myers wrote:
 >>>no response.  This bug (anoncvs can create and delete tags) is still
 >>>present.  Updates can easily fall through the cracks.
 >>
 >>Our cvs server is a special case - we have a few local modifications
 >>that take time to merge in, and no one has had the time to do that
 >>merging.
 >>
 >>I'm hard pressed to think of any other software we've modified on the
 >>system to this extent.
 >
 >This is one reason why I've been moving away from customized software on
 >the system so that I can let RHN tell me when something needs to be
 >updated and update it quickly.  CVS is, as Jason knows, one major
 >problem.
Yup.  Can't argue with that general direction.  It was one of the things
I wanted to do way way way back when RHN first came on the scene.  But
I believe we were running a RHL 6.2 era box at that time...

Jeff

Re: brk() bug

[Matthew Galgoci]

On Wed, 3 Dec 2003 law@redhat.com wrote:

> In message <20031203160905.A55970@molenda.com>, Jason Molenda writes:
>  >On Thu, Dec 04, 2003 at 12:05:47AM +0000, Joseph S. Myers wrote:
>  >
>  >> no response.  This bug (anoncvs can create and delete tags) is still
>  >> present.  Updates can easily fall through the cracks.
>  >
>  >
>  >Our cvs server is a special case - we have a few local modifications
>  >that take time to merge in, and no one has had the time to do that
>  >merging.
>  >
>  >I'm hard pressed to think of any other software we've modified on
>  >the system to this extent.
> The second largest subsystem that is customized would be the mail system.
> But I've been pretty happy with the security of qmail :-)

qmail could certainly be packaged and tossed into fedora. I'm also a fan
of postfix and exim. postfix has been shipped for a while in rhl, exim is
about to be added to fedora (I think).`

Most fedora packages are just an rpm --rebuild away from whatever target
platform you want them to run on.

-- 
Matthew Galgoci
System Administrator
Red Hat, Inc
919.754.3700 x44155

Re: brk() bug

[Jonathan Larmour]

Jason Molenda wrote:
> On Thu, Dec 04, 2003 at 12:05:47AM +0000, Joseph S. Myers wrote:
> 
> 
>>no response.  This bug (anoncvs can create and delete tags) is still
>>present.  Updates can easily fall through the cracks.
> 
> 
> 
> Our cvs server is a special case - we have a few local modifications
> that take time to merge in, and no one has had the time to do that
> merging.

Each project can use this workaround though (based on my original guess), 
which is what is in place in the eCos repo:

CVSROOT/taginfo contains the line:
-=-=-=-
DEFAULT   $CVSROOT/CVSROOT/noanontag
-=-=-=-

CVSROOT/checkoutlist contains the line:
-=-=-=-
noanontag       Anoncvs will be able to tag the repository for cvs 1.11p1.
-=-=-=-

And the new script noanontag (mark it as executable when checking in) is:
-=-=-=-
#!/bin/sh

if [ x`id -un` = xanoncvs -o x`id -un` = xanonymous -o x`id -un` = xcvs ]; 
then
   echo Anonymous CVS users are not permitted to alter CVS tags.
   exit 1
fi

# EOF noanontag
-=-=-=-

Hope this helps,

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine