headers
Simon J. Gerraty | 1 Jan 2005 08:07

Re: Preventative security features?

>Brett Lymn <blymn <at> baesystems.com.au> wrote:

>> I just see too many problems and very few advantages to slicing up a
>> big disk into itty bitty parts.

I mostly agree with that, for my netbsd boxes I have /+swap+var and one 
other mount point that gets the rest of the storage - but _isn't_ /usr.
I want to be able to upgrade the OS without hosing my local stuff.

But the low end models of a  particular brand of router which I'm 
familiar with run chrooted into an ISO fs image, which gives 99+% of 
the system as an immutable read-only fs.  Specific files in /etc are 
symlinks to volatile or non-volatile storage so that the system can 
still be configured/customized, but beyond that...

My point is, that you can make a dedicated box pretty tight, but it isn't
as comfy to live with as a generic workstation.

Of course, with so much money being made these days by criminals 
"owning" other peoples systems, the days of vendors shipping boxes that are
wide open by default should be just about over...

--sjg
Permalink | Reply | 0 comments |
headers
Bill Studenmund | 6 Jan 2005 03:03
Picon

Re: Preventative security features?

Sorry for the blast from the past. I'm cleaning out old mail...

On Sat, Nov 13, 2004 at 07:55:32AM -0800, Jason Thorpe wrote:
> 
> On Nov 13, 2004, at 1:23 AM, Dmitri Nikulin wrote:
> 
> >Maybe just not enough, then :)
> >Is this fed from the high-quality random source? nmap didn't give up 
> >all hope on it.
> 
> I seem to recall that there was a paper published that mathematically 
> analyzed the TCP ISS randomization of a few OSs, and that NetBSD's 
> method was given high praise.

I have that paper, and it also analyzed the OpenBSD method. The latter 
method added random numbers into the mix more often, with the thought that 
more random == better. The problem is that doing that mathematically 
weakened the randomness. More random == worse...

I mention this as the thread seemed to be about adding "security" features 
from other OSs. We should be careful that the changes actually enhance 
security.

Take care,

Bill
Permalink | Reply | 0 comments |
headers
Bill Studenmund | 6 Jan 2005 23:15
Picon

Re: Preventative security features?

Sorry for the blast from the past, I was clearing out old mail and found 
this..

On Sat, Nov 13, 2004 at 07:55:32AM -0800, Jason Thorpe wrote:
> 
> On Nov 13, 2004, at 1:23 AM, Dmitri Nikulin wrote:
> 
> >Maybe just not enough, then :)
> >Is this fed from the high-quality random source? nmap didn't give up 
> >all hope on it.
> 
> I seem to recall that there was a paper published that mathematically 
> analyzed the TCP ISS randomization of a few OSs, and that NetBSD's 
> method was given high praise.

I have that paper, and not only was NetBSD's method rated best, OpenBSD 
and FreeBSD's (taken from Open) actually was weakened.

If I remember right, the NetBSD method involves a linearly-increasing
constant, stepped for each new TCP connection, to which a random amount is 
added. OpenBSD changed it so that the random amount was added in each new 
connection, with the idea that more random is better.

The problem is the law of averages (or large numbers or whatever you like
to call it :-)). For _ANY_ random distribution, if you look at the
distribution of the average of a sample set (i.e. you add together N
samples of your random variable & divide by N. Then you repeat, and look
at the distribution of those answers), you will have a distribution with
less variation around its mean than had the original.  And as I recall,
the standard deviation is sqrt(N) smaller. So open 100 connections, and
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ted Unangst | 8 Jan 2005 04:06

Re: Preventative security features?

On Thu, 6 Jan 2005, Bill Studenmund wrote:

> > I seem to recall that there was a paper published that mathematically 
> > analyzed the TCP ISS randomization of a few OSs, and that NetBSD's 
> > method was given high praise.
> 
> I have that paper, and not only was NetBSD's method rated best, OpenBSD 
> and FreeBSD's (taken from Open) actually was weakened.

which paper are you talking about?  link appreciated, but author and title 
would get me started.

--

-- 
we want to stop reading magazines
stop watching tv
stop caring about hollywood
but we're addicted to the things we hate
Permalink | Reply | 0 comments |
headers
David H. Gutteridge | 9 Jan 2005 07:42
Picon
Favicon

Varied pkgsrc package names not always reflected in pkg-vulnerabilities file

Hello,

I thought I'd mention that the pkg-vulnerabilities file
doesn't always list all the names that pkgsrc packages
have existed under, and consequently misses providing
some notifications.

I've found two examples in my own case.  Version 0.7 of
Firebird (as it used to be called) went by the name
MozillaFirebird in pkgsrc.  Some relevant advisories
are missed because there's nothing under that name in
the pkg-vulnerabilities file.

More recently, the same thing goes for Perl.  I have the
package perl-thread-5.8.4nb1 installed on a machine, and 
it doesn't get picked up by audit-packages because the
string doesn't match against "perl-5.8.[0-4]*".

Dave
Permalink | Reply | 1 comment |
headers
David H. Gutteridge | 9 Jan 2005 07:27
Picon
Favicon

pkg-vulnerabilities listing for Mozilla advisory missing Thunderbird reference

Hello,

Regarding the vulnerability listing referenced as
http://isec.pl/vulnerabilities/isec-0020-mozilla.txt
relating to handling of NNTP URLs in Mozilla < 1.7.3,
in my understanding this also affects Thunderbird
versions prior to 1.0.  Thunderbird is not listed
as vulnerable in the latest pkg-vulnerabilities file.

See Mozilla Bugzilla entry 264388, which lists the
Aviary (incl. Thunderbird) branch as affected.  I
can confirm that the referenced source file is included
in Thunderbird compiles, I checked a compile log I have.

Dave
Permalink | Reply | 2 comments |
headers
David H. Gutteridge | 10 Jan 2005 02:35
Picon
Favicon

Handling of security reports for bootstrapped pkgsrc tools on non-NetBSD OSes

Hello,

I've a question about reporting security
issues with pkgsrc tools that are installed
on non-NetBSD systems via the bootstrap package.
Since they're not actually recorded as packages
(except for digest), they can't be audited by
audit-packages.  Consequently, if an issue
arises, as one with tnftp has recently,
how is communication of this fact handled?
Perhaps this is the first time it's come up?

Dave
Permalink | Reply | 0 comments |
headers
John Klos | 10 Jan 2005 10:17

Re: Handling of security reports for bootstrapped pkgsrc tools on non-NetBSD OSes

> I've a question about reporting security issues with pkgsrc tools that 
> are installed on non-NetBSD systems via the bootstrap package. Since 
> they're not actually recorded as packages (except for digest), they 
> can't be audited by audit-packages.  Consequently, if an issue arises, 
> as one with tnftp has recently, how is communication of this fact 
> handled? Perhaps this is the first time it's come up?

Good point. But is there ever an instance where audit-packages is used on 
a system where pkgsrc tools are not? This seems to be a good candidate for 
a special case for audit-packages to check the version of pkg_tools so 
that insecurities can be reported (pkg_info -V, for instance). That'd just 
need to be added to audit-packages.

John Klos
Permalink | Reply | 0 comments |
headers
Adrian Portelli | 10 Jan 2005 10:50
Favicon

Re: Handling of security reports for bootstrapped pkgsrc tools on non-NetBSD OSes

As I see it there are a number of binaries that could be installed by 
the bootstrap process depending on which OS you are on:

pax, mtree, sed, libnbcompat, bmake, tnftp, digest and pkg_install
(am I missing any ?)

There could also be some other script/tools installed by bootstrap its self:

bmake, strip and bsd_install

Now for the first list it looks like the bootstrap process just dives 
into the relevant part of pkgsrc src and builds and installs the 
packages it needs.  So we should look to maybe adding some extra entries 
to the initial pkgdbdir that's created to cover these.  That way an 
audit-packages run will pick these up.

Now for the second list . . . an entry for bootstrap its self in pkgdbdir ?

adrian.

John Klos wrote:
>> I've a question about reporting security issues with pkgsrc tools that 
>> are installed on non-NetBSD systems via the bootstrap package. Since 
>> they're not actually recorded as packages (except for digest), they 
>> can't be audited by audit-packages.  Consequently, if an issue arises, 
>> as one with tnftp has recently, how is communication of this fact 
>> handled? Perhaps this is the first time it's come up?
> 
> 
> Good point. But is there ever an instance where audit-packages is used
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Carosone | 10 Jan 2005 11:22
Picon

Re: Handling of security reports for bootstrapped pkgsrc tools on non-NetBSD OSes

On Mon, Jan 10, 2005 at 09:50:28AM +0000, Adrian Portelli wrote:
> Now for the first list it looks like the bootstrap process just dives 
> into the relevant part of pkgsrc src and builds and installs the 
> packages it needs.  So we should look to maybe adding some extra entries 
> to the initial pkgdbdir that's created to cover these.  That way an 
> audit-packages run will pick these up.

I spoke to Grant a while back about exactly this: sythesising db
entries for these 'packages', to facilitate later upgrades. 

It's somewhere on the radar, not sure exactly where.

> Now for the second list . . . an entry for bootstrap its self in pkgdbdir ?

Would be good.

--
Dan.
Permalink | Reply | 0 comments |

Gmane