SNMP problems published by Schneier/Counterpane

2002-03-16 Thread Xeno Campanoli
Has anyone else heard of this SNMP problem?  Are we up to date with the
security fixes on stable, etc?

Here is a quick excerpt (CRYPTO-GRAM, March 15, 2002):


 SNMP Vulnerabilities



SNMP is the Simple Network Management Protocol, the most popular
protocol 
to manage network devices.  Hundreds, possibly thousands, of products
use 
it.  Last fall, a group of Finnish researchers discovered multiple 
vulnerabilities in SNMP.  By exploiting the vulnerabilities, an attacker 
could cause a denial-of-service attack, and in some cases take over
control 
of the system.

The vulnerabilities concerns SNMP's trap-handling and request-handling 
functions, and stem from problems in the reference code (probably) used 
inside the Abstract Syntax Notation (ASN.1) and Basic Encoding Rules 
(BER).  The SNMP vulnerabilities affect hundreds of different devices: 
operating systems, network equipment, software packages, even things
like 
digital cameras.  It's a BIG deal.

It's actually a bigger deal than has been reported.  ASN.1 is used
inside a 
lot of other applications, such as OpenSSL.  These vulnerabilities
aren't 
limited to SNMPv1; that's just the only thing that's been
well-publicized 
at this point.  (The recently reported problems in mod_ssl and Apache
are 
apparently related to this, too.)

The history of the vulnerability's discovery and publication is an 
interesting story, and illustrates the tension between bug secrecy and
full 
disclosure.  A research group from the Oulu University Secure
Programming 
Group in Oulu, Finland, first discovered this problem in October 2001,
and 
decided not to publish because it was such a large problem.  CERT took
on 
the task of coordinating the fix with the major software vendors, and
has 
said that the reason publication was delayed so long is that there were
so 
many vendors to contact.  CERT even had problems with vendors not taking 
the problem seriously, and had to spend considerable effort to get the 
right people to pay attention.  Lesson #1: If bugs are secret, many
vendors 
won't bother patching their systems.

The vulnerability was published on 12 February.  Supposedly, this was
two 
weeks earlier than planned, and because the story was leaking too 
much.  CERT felt that early publication was better than widespread 
rumors.  Some companies were caught off-guard.  Even though they had
months 
to patch their systems, they weren't ready and needed those two extra 
weeks.  Some companies didn't bother to start worrying about the problem 
until publication was imminent.  Lesson #2: It is only the threat of 
publication that makes many" vendors patch their systems.  (To be fair, 
many companies did a great job proactively patching their systems.  And
in 
many cases, the patches were not trivial.  Some vendors were swamped by
the 
sheer number of different products and releases they had to patch and 
test.  And I stress "test", because patching mature code carries a
strong 
probability of either not fixing the problem or of introducing new
problems.)

When CERT finally published and the Oulu Web site went live, there were
all 
sorts of reactions.  Some tried to capitalize on the announcement to
sell 
their products; others tried to minimize it.  Many vendors had no idea
if 
they were vulnerable or not  But because publication included
demonstration 
code -- the PROTOS tool -- vendors and security companies were able to
test 
networks and equipment.  Lesson #3: Publication must include enough 
information to reproduce the vulnerability; otherwise, there's no way
for 
anyone to determine how serious the threat is.  And Lesson #4: If there
is 
no way to independently verify the vulnerability, then organizations are 
forced to rely on information from potentially biased sources.

As of this writing, there have been no credible reports of this 
vulnerability being exploited in the wild.  Counterpane's monitoring has 
not detected any of our customers being attacked via this 
vulnerability.  This is not to say that no one has -- writing an attack 
tool is a straightforward programming task -- but no one has published
such 
a tool and put it in the hands of the script kiddies.  Lesson #5: 
Publication does not automatically mean the vulnerability will be
exploited.

So far we've been lucky.  But a tool could show up at any time, so
relying 
on that luck would not be smart.  And even though everyone has been
urged 
to patch their systems and products, some will not.  Even if it takes 
months before someone writes an attack tool, it will work against a 
surprisingly large subset of systems.  Lesson #6: Publication increases
the 
likelihood that a vulnerability will be exploited.

And there are a lot of systems for which patches will never be 
available.  Many router vendors have gone out of business in the last
few 
years, and not every mom-and-pop software company out there has the
money 
or clue to replace their hardware because their code has a problem. 
Lesson 
#7

SNMP problems published by Schneier/Counterpane

2002-03-16 Thread Xeno Campanoli

Has anyone else heard of this SNMP problem?  Are we up to date with the
security fixes on stable, etc?

Here is a quick excerpt (CRYPTO-GRAM, March 15, 2002):


 SNMP Vulnerabilities



SNMP is the Simple Network Management Protocol, the most popular
protocol 
to manage network devices.  Hundreds, possibly thousands, of products
use 
it.  Last fall, a group of Finnish researchers discovered multiple 
vulnerabilities in SNMP.  By exploiting the vulnerabilities, an attacker 
could cause a denial-of-service attack, and in some cases take over
control 
of the system.

The vulnerabilities concerns SNMP's trap-handling and request-handling 
functions, and stem from problems in the reference code (probably) used 
inside the Abstract Syntax Notation (ASN.1) and Basic Encoding Rules 
(BER).  The SNMP vulnerabilities affect hundreds of different devices: 
operating systems, network equipment, software packages, even things
like 
digital cameras.  It's a BIG deal.

It's actually a bigger deal than has been reported.  ASN.1 is used
inside a 
lot of other applications, such as OpenSSL.  These vulnerabilities
aren't 
limited to SNMPv1; that's just the only thing that's been
well-publicized 
at this point.  (The recently reported problems in mod_ssl and Apache
are 
apparently related to this, too.)

The history of the vulnerability's discovery and publication is an 
interesting story, and illustrates the tension between bug secrecy and
full 
disclosure.  A research group from the Oulu University Secure
Programming 
Group in Oulu, Finland, first discovered this problem in October 2001,
and 
decided not to publish because it was such a large problem.  CERT took
on 
the task of coordinating the fix with the major software vendors, and
has 
said that the reason publication was delayed so long is that there were
so 
many vendors to contact.  CERT even had problems with vendors not taking 
the problem seriously, and had to spend considerable effort to get the 
right people to pay attention.  Lesson #1: If bugs are secret, many
vendors 
won't bother patching their systems.

The vulnerability was published on 12 February.  Supposedly, this was
two 
weeks earlier than planned, and because the story was leaking too 
much.  CERT felt that early publication was better than widespread 
rumors.  Some companies were caught off-guard.  Even though they had
months 
to patch their systems, they weren't ready and needed those two extra 
weeks.  Some companies didn't bother to start worrying about the problem 
until publication was imminent.  Lesson #2: It is only the threat of 
publication that makes many" vendors patch their systems.  (To be fair, 
many companies did a great job proactively patching their systems.  And
in 
many cases, the patches were not trivial.  Some vendors were swamped by
the 
sheer number of different products and releases they had to patch and 
test.  And I stress "test", because patching mature code carries a
strong 
probability of either not fixing the problem or of introducing new
problems.)

When CERT finally published and the Oulu Web site went live, there were
all 
sorts of reactions.  Some tried to capitalize on the announcement to
sell 
their products; others tried to minimize it.  Many vendors had no idea
if 
they were vulnerable or not  But because publication included
demonstration 
code -- the PROTOS tool -- vendors and security companies were able to
test 
networks and equipment.  Lesson #3: Publication must include enough 
information to reproduce the vulnerability; otherwise, there's no way
for 
anyone to determine how serious the threat is.  And Lesson #4: If there
is 
no way to independently verify the vulnerability, then organizations are 
forced to rely on information from potentially biased sources.

As of this writing, there have been no credible reports of this 
vulnerability being exploited in the wild.  Counterpane's monitoring has 
not detected any of our customers being attacked via this 
vulnerability.  This is not to say that no one has -- writing an attack 
tool is a straightforward programming task -- but no one has published
such 
a tool and put it in the hands of the script kiddies.  Lesson #5: 
Publication does not automatically mean the vulnerability will be
exploited.

So far we've been lucky.  But a tool could show up at any time, so
relying 
on that luck would not be smart.  And even though everyone has been
urged 
to patch their systems and products, some will not.  Even if it takes 
months before someone writes an attack tool, it will work against a 
surprisingly large subset of systems.  Lesson #6: Publication increases
the 
likelihood that a vulnerability will be exploited.

And there are a lot of systems for which patches will never be 
available.  Many router vendors have gone out of business in the last
few 
years, and not every mom-and-pop software company out there has the
money 
or clue to replace their hardware because their code has a problem. 
Lesson 
#

Re: Say, wheres 2.2.20?

2002-03-07 Thread Xeno Campanoli
> > I'll keep that in mind.  If it is really that difficult for it to go
> > through the process to become formalized as stable, then is that
> > difficulty all wasted effort?
> 
> Debian's release/revision (from stable to stable) process is much slower
> than the kernel's.  That's a known fact.
> 
> If you want to wait... that's up to you.  If you want more recent stuff
> (including kernels packaged by debian) you should use testing.
> 
> I wouldn't use stable for much more than a server you never look at, but if
> you need to use it for new purposes, you'll probably need woody/testing.

Thank you Mike.  I'll keep that in mind for now.  Thank you for the
feedback.

-- 
http://www.eskimo.com/~xeno
[EMAIL PROTECTED]
Physically I'm at:  5101 N. 45th St., Tacoma, WA, 98407-3717, U.S.A.



Re: Say, wheres 2.2.20?

2002-03-07 Thread Xeno Campanoli

> > I'll keep that in mind.  If it is really that difficult for it to go
> > through the process to become formalized as stable, then is that
> > difficulty all wasted effort?
> 
> Debian's release/revision (from stable to stable) process is much slower
> than the kernel's.  That's a known fact.
> 
> If you want to wait... that's up to you.  If you want more recent stuff
> (including kernels packaged by debian) you should use testing.
> 
> I wouldn't use stable for much more than a server you never look at, but if
> you need to use it for new purposes, you'll probably need woody/testing.

Thank you Mike.  I'll keep that in mind for now.  Thank you for the
feedback.

-- 
http://www.eskimo.com/~xeno
[EMAIL PROTECTED]
Physically I'm at:  5101 N. 45th St., Tacoma, WA, 98407-3717, U.S.A.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: Say, wheres 2.2.20?

2002-03-07 Thread Xeno Campanoli
Mike Fedyk wrote:
> 
> On Thu, Mar 07, 2002 at 01:11:34PM +0800, Mo Zhen Guang wrote:
> > as always, security update may be troublesome with testing distribution.
> > stable is much easier
> > Mo
> >
> 
> Version: 2.2.20-2
> Provides: kernel-image
> Depends: fileutils (>= 4.0)
> 
> What version of fileutils is in potato?
> 
> All that the package supplies is the kernel.  It will be as stable as any
> other kernel package wheather it is in stable or not (it's the official
> 2.2.20) so what's your prob?  Maybe you should check before you assume that
> just because it's in testing that it's not stable.

I'll keep that in mind.  If it is really that difficult for it to go
through the process to become formalized as stable, then is that
difficulty all wasted effort?

-- 
http://www.eskimo.com/~xeno
[EMAIL PROTECTED]
Physically I'm at:  5101 N. 45th St., Tacoma, WA, 98407-3717, U.S.A.



Re: default security

2002-03-07 Thread Xeno Campanoli
Javier Fernández-Sanguino Peña wrote:
> 
> On Tue, Jan 15, 2002 at 01:51:32PM +0100, martin f krafft wrote:
> >
> > > Debian could provide, with only some effort from package
> > > maintainers versions of daemons chrooted to given environments. This
> > > however, might break Policy (IMHO).
> >
> > how would it break policy?
> 
> (sorry, catching up with posts)
> 
> Policy would be broken because a chroot installation would need
> all the libraries, configuration files, etc... that the service needed
> to be placed in a given fixed location
> (for example /usr/lib/named/etc, /usr/lib/named/var/{log,run})
> This defeats the FHS

He's referring to the Debian Filesystem Hierarchy Standard, which I keep
having to re-look-up, so here's the link if anyone else wants to, as
found on Google:

http://www.pathname.com/fhs/

> and also one of Debian's primary assumptions
> (all configuration files in /etc for example) on which the policy is
> based.
> This also makes it more difficult for package maintainance,
> how do I propagate changes from dynamic libraries to chrooted services?
> Of course, if the service is able to chroot itself (example is bind's
> -t flag or proftp's anonymous chrooted environment) this is less of an
> issue since you can run it properly and
> just need config, log, data and pid files in the chrooted environment.
> 
> Regards
> 
> Javi
> 
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

-- 
http://www.eskimo.com/~xeno
[EMAIL PROTECTED]
Physically I'm at:  5101 N. 45th St., Tacoma, WA, 98407-3717, U.S.A.



Re: Say, wheres 2.2.20?

2002-03-07 Thread Xeno Campanoli

Mike Fedyk wrote:
> 
> On Thu, Mar 07, 2002 at 01:11:34PM +0800, Mo Zhen Guang wrote:
> > as always, security update may be troublesome with testing distribution.
> > stable is much easier
> > Mo
> >
> 
> Version: 2.2.20-2
> Provides: kernel-image
> Depends: fileutils (>= 4.0)
> 
> What version of fileutils is in potato?
> 
> All that the package supplies is the kernel.  It will be as stable as any
> other kernel package wheather it is in stable or not (it's the official
> 2.2.20) so what's your prob?  Maybe you should check before you assume that
> just because it's in testing that it's not stable.

I'll keep that in mind.  If it is really that difficult for it to go
through the process to become formalized as stable, then is that
difficulty all wasted effort?

-- 
http://www.eskimo.com/~xeno
[EMAIL PROTECTED]
Physically I'm at:  5101 N. 45th St., Tacoma, WA, 98407-3717, U.S.A.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: default security

2002-03-07 Thread Xeno Campanoli

Javier Fernández-Sanguino Peña wrote:
> 
> On Tue, Jan 15, 2002 at 01:51:32PM +0100, martin f krafft wrote:
> >
> > > Debian could provide, with only some effort from package
> > > maintainers versions of daemons chrooted to given environments. This
> > > however, might break Policy (IMHO).
> >
> > how would it break policy?
> 
> (sorry, catching up with posts)
> 
> Policy would be broken because a chroot installation would need
> all the libraries, configuration files, etc... that the service needed
> to be placed in a given fixed location
> (for example /usr/lib/named/etc, /usr/lib/named/var/{log,run})
> This defeats the FHS

He's referring to the Debian Filesystem Hierarchy Standard, which I keep
having to re-look-up, so here's the link if anyone else wants to, as
found on Google:

http://www.pathname.com/fhs/

> and also one of Debian's primary assumptions
> (all configuration files in /etc for example) on which the policy is
> based.
> This also makes it more difficult for package maintainance,
> how do I propagate changes from dynamic libraries to chrooted services?
> Of course, if the service is able to chroot itself (example is bind's
> -t flag or proftp's anonymous chrooted environment) this is less of an
> issue since you can run it properly and
> just need config, log, data and pid files in the chrooted environment.
> 
> Regards
> 
> Javi
> 
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

-- 
http://www.eskimo.com/~xeno
[EMAIL PROTECTED]
Physically I'm at:  5101 N. 45th St., Tacoma, WA, 98407-3717, U.S.A.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Say, wheres 2.2.20?

2002-03-06 Thread Xeno Campanoli
Say, stable doesn't seem to have 2.2.20 available to it yet, and yet
that's supposed to be the most stable 2.2.* kernel out according to (I
think it was the HOWTO on E-Infomax I read it, but they're down right
now) a howto I was reading. Whats' the deal?  It's been around for some
time now, and yet still not on stable...?

Sorry to be such a whiner.  I wish I was up to speed enough to be the
one installing it, but I'm not yet.

-- 
http://www.eskimo.com/~xeno
[EMAIL PROTECTED]
Physically I'm at:  5101 N. 45th St., Tacoma, WA, 98407-3717, U.S.A.



Say, wheres 2.2.20?

2002-03-06 Thread Xeno Campanoli

Say, stable doesn't seem to have 2.2.20 available to it yet, and yet
that's supposed to be the most stable 2.2.* kernel out according to (I
think it was the HOWTO on E-Infomax I read it, but they're down right
now) a howto I was reading. Whats' the deal?  It's been around for some
time now, and yet still not on stable...?

Sorry to be such a whiner.  I wish I was up to speed enough to be the
one installing it, but I'm not yet.

-- 
http://www.eskimo.com/~xeno
[EMAIL PROTECTED]
Physically I'm at:  5101 N. 45th St., Tacoma, WA, 98407-3717, U.S.A.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]