SNMP problems published by Schneier/Counterpane
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
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?
> > 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?
> > 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?
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
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?
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
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?
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?
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]