Re: Snort: Mass Bug Closing
* Steve Kemp | (Essentially apt-get + apt-cache for snort rules. Clearly packaging a | single rule file within one package is a gross misuse of resources but | it might be sufficient if they were signed and hosted somewhere | sensible..) They could all be packaged into a single package (or a small number of them, if that makes sense) and just have the frontend enable/disable the rules. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: On packages depending on up-to-date data (was Re: Snort: Mass Bug Closing)
Quoting Javier Fernández-Sanguino Peña ([EMAIL PROTECTED]): [Short version: see the patch below.] (after a few days w/o answers from Snort's maintainer) Sander, any comments wrt to this patch? Please at least say wether you are going to forward this to Snort maintainers or use it in order to not break snort packages on upgrades. Thanks for that patch. I'm forwarding it to snort-devel. I hope they'll implement it. I wasn't planning on using it to patch debian released snorts, really. Sander. -- | Visitors always give pleasure: if not on arrival, then on the departure. | 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8 9BDB D463 7E41 08CE C94D pgpsxazqDS3d6.pgp Description: PGP signature
Re: On packages depending on up-to-date data (was Re: Snort: Mass Bug Closing)
On Tue, Aug 26, 2003 at 01:29:31AM +0200, Javier Fernández-Sanguino Peña wrote: [Short version: see the patch below.] (after a few days w/o answers from Snort's maintainer) Sander, any comments wrt to this patch? Please at least say wether you are going to forward this to Snort maintainers or use it in order to not break snort packages on upgrades. (grumble, grumble) Thanks. Javi pgpVMMl6QErYP.pgp Description: PGP signature
Re: Snort: Mass Bug Closing
On Wed, Aug 27, 2003 at 05:47:12AM +0200, Josip Rodin wrote: Well, _something_ threw dpkg off, because it doesn't always prompt erroneously. Trouble is, we are never able to locate the culprit... :( http://bugs.debian.org/108587 lists some situations where this can happen. -- - mdz
Re: Snort: Mass Bug Closing
On Wed, Aug 27, 2003 at 12:06:15AM -0400, Matt Zimmerman wrote: Well, _something_ threw dpkg off, because it doesn't always prompt erroneously. Trouble is, we are never able to locate the culprit... :( http://bugs.debian.org/108587 lists some situations where this can happen. Ah, so I guessed right, mv'ing the files into rules/ caused this to happen. -- 2. That which causes joy or happiness.
Re: Snort: Mass Bug Closing
On Mon, Aug 25, 2003 at 02:17:51AM +1000, Anthony Towns wrote: That's for Martin Schulze (Joey - Stable Release Manager) and/or the security team to decide; not ftpmaster. A quick scan of those bugs doesn't reveal anything which looks like a security vulnerability, so this would seem to be purely an SRM/proposed-updates issue. -- - mdz
Re: Snort: Mass Bug Closing
On Sun, Aug 24, 2003 at 03:57:45PM +0200, Sander Smeenk wrote: I'm about to close 95153, 133049, 158040, 16, 170580, 173331, 176223, 135603, 161659, 165107, 165135, 165351, 171190, 172529, 173663, 174506, 174508, 174509, 192401, 193544, 101725, 122689, 159575, 165126, 182280, and 189780 with a nice message telling that the bug was reported on a really old package-version and the bug is really old too, including a URL to an up to date version of the package, where most probably all these bugs are fixed. Did you check whether any of these bugs are fixed? I reported at least one of them, and it is definitely not fixed. You should not close bugs simply because they are old. Before you object to this rather 'rude' bughandling, please keep in mind that version 1.8.4 of snort, which is in stable, has 3 severe security exploits, and is completely outdated in catching crooks (rulefiles) and detection mechanisms. Not to speak of package stability ;) I think it is quite rude to knowingly distribute a package with severe security problems without fixing the bugs or even informing other developers. What are these bugs exactly? How long have you been aware of them? Or are you perhaps not aware of DSA-297? -- - mdz
Re: Snort: Mass Bug Closing
Quoting Matt Zimmerman ([EMAIL PROTECTED]): That's for Martin Schulze (Joey - Stable Release Manager) and/or the security team to decide; not ftpmaster. A quick scan of those bugs doesn't reveal anything which looks like a security vulnerability, so this would seem to be purely an SRM/proposed-updates issue. The package in stable was never replaced. An advisory was given out containing links to my stable packages. It never hit stable's security updates, so the package in stable still is vulnerable, if one installs it. The bugs were probably closed by uploading the fixed versions of the package to unstable. Sander. -- | How do you write zero in Roman numerals? | 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8 9BDB D463 7E41 08CE C94D
Re: Snort: Mass Bug Closing
Quoting Matt Zimmerman ([EMAIL PROTECTED]): I'm about to close 95153, 133049, 158040, 16, 170580, 173331, 176223, 135603, 161659, 165107, 165135, 165351, 171190, 172529, 173663, 174506, 174508, 174509, 192401, 193544, 101725, 122689, 159575, 165126, 182280, and 189780 with a nice message telling that the bug was reported on a Did you check whether any of these bugs are fixed? I reported at least one of them, and it is definitely not fixed. You should not close bugs simply because they are old. Yes. IMHO all these bugs are fixed in the new packages I provided for stable users on p.d.o/~ssmeenk/ Before you object to this rather 'rude' bughandling, please keep in mind that version 1.8.4 of snort, which is in stable, has 3 severe security exploits, and is completely outdated in catching crooks (rulefiles) and detection mechanisms. Not to speak of package stability ;) I think it is quite rude to knowingly distribute a package with severe security problems without fixing the bugs or even informing other developers. FFS don't act like i'm the bad guy here. I reported the advisories the minute i heard of them, and that was maybe a couple of hours after they have been released to the public. A nice mail went to the security team, and they told me what to do: fix the package in unstable, and try if i was capable of fixing the stable version without using new upstream source. I then told security team I was not capable of doing such a thing. Time passed and I got a request to create stable packages of new upstream source and provide them on p.d.o. So i did. But for as far as I know, those packages went in the advisory, and the stable archive stable security updates-apt-source where never updated with a fixed version of the package. What are these bugs exactly? If i recall correctly, it was two memory allocation faults in the RPC code, and one in the fragmented packet reassambly code. How long have you been aware of them? As long as the security team was. Or are you perhaps not aware of DSA-297? I knew it was released, but I probably looked over the fact that indeed the stable version of the snort-package /has/ been fixed. That was stupid of me. Sander. -- | Amnesia used to be my favorite word, but then I forgot it. | 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8 9BDB D463 7E41 08CE C94D
Re: Snort: Mass Bug Closing
On Mon, 25 Aug 2003 09:24:41 +0200, Magnus Ekdahl [EMAIL PROTECTED] wrote: For users without an internet connection Marc Haber maintains the clamav-data package which includes a static database. As well as the clamav-getfiles package to update it from a computer with internet access. And daily, untested packages are built automatically on gluck and are aptable from deb http://people.debian.org/~zugschlus/clamav-data/ / Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Re: Snort: Mass Bug Closing
On Mon, Aug 25, 2003 at 09:04:08AM -0600, Jamin W. Collins wrote: On Mon, Aug 25, 2003 at 10:19:55AM +0200, Sander Smeenk wrote: We've been over this in debian-security before. I fixed the 1.8.4 package once, it got rejected, and I tried to have 2.0.x installed in Stable, but ofcourse, you can't put a new upstream version in a released stable Debian. Actually that's not true, as an example I refer you to SSH. A stunning example of what a terrible idea it is to do this. That update was forced due to conditions created by upstream, and caused a great deal of problems, created a lot of work for the security team, and caused downtime on many user systems. -- - mdz
Re: Snort: Mass Bug Closing
On Mon, Aug 25, 2003 at 10:28:18AM +0200, Sander Smeenk wrote: Quoting Josip Rodin ([EMAIL PROTECTED]): Oh and it didn't even want to start properly -- and the init script wasn't even so kind to tell me, I had to learn from syslog that Aug 24 16:57:23 hostname snort: FATAL ERROR: Unable to open rules file: ../rules/bad-traffic.rules or /etc/snort/../rules/bad-traffic.rules All it took to make it work was to change RULE_PATH from ../rules to /etc/snort/rules, but it's still broken that it didn't detect this properly. I'm terribly sorry. I made the packages, and since i'm not running stable myself, i couldn't extensively test them. I'll fix this. And you wanted this to go into stable? -- - mdz
Re: Snort: Mass Bug Closing
On Sun, Aug 24, 2003 at 08:59:06AM -0600, Jamin W. Collins wrote: On Sun, Aug 24, 2003 at 03:57:45PM +0200, Sander Smeenk wrote: Before you object to this rather 'rude' bughandling, please keep in mind that version 1.8.4 of snort, which is in stable, has 3 severe security exploits, So, why hasn't a security update been released for it? It has? -- - mdz
Re: On packages depending on up-to-date data (was Re: Snort: Mass Bug Closing)
On Mon, Aug 25, 2003 at 12:11:07PM -0400, Noah L. Meyerhans wrote: No. New attacks represent security threats. Old attacks represent curiosities, at best (i.e. have you seen any Redhat 6.2 rpc.statd attacks lately?) An intrusion detection system that can not detect known intrusions is not useful. The snort in stable _can_ detect known intrusions. It cannot detect _all_ known intrusions, but if an IDS which cannot detect _all_ known intrusions is not useful, then no version of snort is useful. Once snort gets to the point where new rules are usually compatible with the old engine, I think this problem can be addressed by a process to update the rules. -- - mdz
Re: On packages depending on up-to-date data (was Re: Snort: Mass Bug Closing)
On Tue, Aug 26, 2003 at 12:24:11AM +0200, Sander Smeenk wrote: This problem only exists for snort packages that aren't going to be updated, like the ones that reach stable. The unstable package is up to date enough to have all correct rules, imho. The other thing is, snort.org's people quickly start to drop old rule formats when newer formats are used. Should I be the one that has to convert every rule back to the old format to have stable users of snort safe and sound? It'll take alot of time. And I believe it is not always scriptable. [...] Well. Snort just fails to start if it can't parse the rule files. And usually that is with every major upstream release. :( You might consider talking with upstream about stability. What about users who have written their own rules? These simply break when a new version comes out? Why does the format need to change so frequently? -- - mdz
Re: Snort: Mass Bug Closing
On Mon, Aug 25, 2003 at 10:29:30AM +0200, Sander Smeenk wrote: Quoting Jamin W. Collins ([EMAIL PROTECTED]): Before you object to this rather 'rude' bughandling, please keep in mind that version 1.8.4 of snort, which is in stable, has 3 severe security exploits, So, why hasn't a security update been released for it? There has been a DSA about Snort. That pointed to my previous backported packages. Neither me, nor the security team were able to backport the security fixes to 1.8.4, so this was the best approach, they thought. ??? snort (1.8.4beta1-3.1) stable-security; urgency=high * Non-maintainer upload by the Security Team * Applied upstream fix against integer overflow in the stream4 preprocessor code (VU#139129, CAN-2003-0209, Bugtraq 7178, spp_stream4.c) * Applied upstream fix against buffer overflow in the RPC preprocessor (VU#916785, CAN-2003-0033, Bugtraq 6963, spp_rpc_decode.c) -- Martin Schulze [EMAIL PROTECTED] Fri, 18 Apr 2003 06:13:43 +0200 -- - mdz
Re: Snort: Mass Bug Closing
On Tue, Aug 26, 2003 at 12:46:45AM +0200, Sander Smeenk wrote: Let's first start by telling that my backported packages never made it to security updates that every good stable user should have in their apt sources. The DSA just pointed users who actually read it to my p.d.o. site. Would you stop saying that? You apparently didn't even read this advisory, which was about your own package. -- - mdz
Re: Snort: Mass Bug Closing
On Tue, Aug 26, 2003 at 11:40:10AM +0200, Sander Smeenk wrote: Quoting Matt Zimmerman ([EMAIL PROTECTED]): What are these bugs exactly? If i recall correctly, it was two memory allocation faults in the RPC code, and one in the fragmented packet reassambly code. I assumed that you were talking about some new bugs, since these old bugs were fixed several months ago, and yet you still said that stable has these bugs. -- - mdz
Re: Snort: Mass Bug Closing
On Tue, Aug 26, 2003 at 11:07:00AM -0400, Matt Zimmerman wrote: On Mon, Aug 25, 2003 at 09:04:08AM -0600, Jamin W. Collins wrote: Actually that's not true, as an example I refer you to SSH. A stunning example of what a terrible idea it is to do this. Never said it was a good idea, just that it did and has happened. -- Jamin W. Collins Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo
Re: Snort: Mass Bug Closing
* Marc Haber ([EMAIL PROTECTED]) [030826 16:05]: On Mon, 25 Aug 2003 09:24:41 +0200, Magnus Ekdahl [EMAIL PROTECTED] wrote: For users without an internet connection Marc Haber maintains the clamav-data package which includes a static database. As well as the clamav-getfiles package to update it from a computer with internet access. And daily, untested packages are built automatically on gluck and are aptable from deb http://people.debian.org/~zugschlus/clamav-data/ / Add a debconf-question about adding this to sources.list? Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Snort: Mass Bug Closing
On Tue, 26 Aug 2003 16:10:36 +0200, Andreas Barth [EMAIL PROTECTED] wrote: * Marc Haber ([EMAIL PROTECTED]) [030826 16:05]: And daily, untested packages are built automatically on gluck and are aptable from deb http://people.debian.org/~zugschlus/clamav-data/ / Add a debconf-question about adding this to sources.list? NACK. That would be interfering with somebody else's conffiles, and if packages can that easily be apted, people should use freshclam. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Re: Snort: Mass Bug Closing
Andreas Barth wrote: * Marc Haber ([EMAIL PROTECTED]) [030826 16:05]: deb http://people.debian.org/~zugschlus/clamav-data/ / Add a debconf-question about adding this to sources.list? Maybe README.Debian is better. In addition one might add a reference to README.Debian to error messages complaining about missing / outdated data. IMHO, having random packages tinker with the apt sources is a very bad idea. Cheers T. pgpsrgqajmtf8.pgp Description: PGP signature
Re: Snort: Mass Bug Closing
On Mon, Aug 25, 2003 at 11:00:06AM -0500, Adam Heath wrote: I've upgraded to this version and it has required me to press y to replace modified conffiles in /etc/snort/rules/ about two dozen times, while I'm pretty sure I never touched any of them. That's an pretty impressive amount of annoyance you managed to cause there. I wish I knew what I could do about that. It's some sort of a corner case situation in which actually unchanged files appear changed and dpkg prompts for them. Did the packages ever modify the files? Did they move them around? You know, I don't think that's the case, really. Well, _something_ threw dpkg off, because it doesn't always prompt erroneously. Trouble is, we are never able to locate the culprit... :( -- 2. That which causes joy or happiness.
Re: Snort: Mass Bug Closing
On Monday 25 August 2003 04:02, Noah L. Meyerhans wrote: I can think off-hand of at least one other security related tool that needs frequent updating of a ruleset: nessus. It is an active probing clamav needs to update its virus definitons - it's exactly the same case again. -- vbi -- featured product: the GNU Compiler Collection - http://gcc.gnu.org pgpcVbJM1rTNV.pgp Description: signature
Re: Snort: Mass Bug Closing
Adrian von Bidder wrote: On Monday 25 August 2003 04:02, Noah L. Meyerhans wrote: I can think off-hand of at least one other security related tool that needs frequent updating of a ruleset: nessus. It is an active probing clamav needs to update its virus definitons - it's exactly the same case again. True, but for clamav its already implemented, although with some bugs left. The default database provider for clamav is the clamav-freshclam package. clamav-freshclam doesn't include a database. It automates downloading of one using the upstream updating program 'freshclam'. For users without an internet connection Marc Haber maintains the clamav-data package which includes a static database. As well as the clamav-getfiles package to update it from a computer with internet access. -- Magnus Ekdahl 0739-287181 [EMAIL PROTECTED] [EMAIL PROTECTED] public key available at http://oxtan.campus.luth.se/magnus.public ftp://ftp.se.debian.org/debian-non-US/pool/non-US/main/d/debian-keyring/ Key fingerprint = 18DE CB62 8A86 374E 824E 09ED 1987 4B18 1213 79F6
Re: Snort: Mass Bug Closing
Quoting Javier Fernández-Sanguino Peña ([EMAIL PROTECTED]): 'semi up to date'. Still a lot of people use the outdated and utterly broken 1.8.4 release and complain. Although these complaints are correct, Maybe because they are not aware of your backporting efforts. And they never will be, until they find one of the gazillion problems with 1.8.4 and report it. It's not the correct way, I agree. But i'm not going to fight release managers anymore to get snort 2.0.1 released in stable. Yes, these utterly broken release is in all Debian CDs and mirrors. Bugs are bugs, if they are not fixed then don't close them. BTW, they are not even tagged properly (i.e. 'stable') The problem is that the buglist i'm having on snort now, consists of mainly bugs filed on the stable package of snort, which has been long solved in the later releases of snort that didn't make it in the release of Debian. It's annoying now, to see what bugs really are bugs, and what are bugs filed against stable. Some submitters didn't even specify versionnumbers. Before you object to this rather 'rude' bughandling, please keep in mind that version 1.8.4 of snort Then you should work towards fixing them in stable or having ftp-masters agreeing with including a new (backported) version at proposed-updates. We've been over this in debian-security before. I fixed the 1.8.4 package once, it got rejected, and I tried to have 2.0.x installed in Stable, but ofcourse, you can't put a new upstream version in a released stable Debian. That's why i'm doing backports on p.d.o, and that's why i want the bugs closed if I can't fix them. It's for the users best interrest that I tell them to use the new version. It is for the best interest of the users that you provide a proper snort version in proposed-updates. THEN LET ME! ffs! I know the way i'm going now isn't the correct way, but the tight rules about updating stable prevent me from doing it any better. Staying with 1.8.4 in Stable is useless, it is out dated, which is bad for a security tool. Going with 2.0.1 is impossible, because it might (and probably will...) introduce new bugs to stable. This is a similar situation to #183524. We have to determine a way to remove packages completely out of stable (due to unfixable security bugs, for example) in a way that do not leave users exposed to these and their bugs. A pseudo-package. But then what. Have people not run snort while using stable? I'm sorry if i sound harsh, i don't mean to. That's because of the rest of the replies in this thread. don't take it personal okay ;) Sander. -- | Waarom zit je achter een computer terwijl je er eigenlijk voor zit? | 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8 9BDB D463 7E41 08CE C94D pgpOzmAH4oqeu.pgp Description: PGP signature
Re: Snort: Mass Bug Closing
Quoting Josip Rodin ([EMAIL PROTECTED]): [2] deb http:///people.debian.org/~ssmeenk/snort-stable-i386/ ./ ~ Typo. Oops. I've upgraded to this version and it has required me to press y to replace modified conffiles in /etc/snort/rules/ about two dozen times, while I'm pretty sure I never touched any of them. That's an pretty impressive amount of annoyance you managed to cause there. I wish I knew what I could do about that. -- | Why doesn't Tarzan have a beard? | 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8 9BDB D463 7E41 08CE C94D
Re: Snort: Mass Bug Closing
Quoting Josip Rodin ([EMAIL PROTECTED]): Oh and it didn't even want to start properly -- and the init script wasn't even so kind to tell me, I had to learn from syslog that Aug 24 16:57:23 hostname snort: FATAL ERROR: Unable to open rules file: ../rules/bad-traffic.rules or /etc/snort/../rules/bad-traffic.rules All it took to make it work was to change RULE_PATH from ../rules to /etc/snort/rules, but it's still broken that it didn't detect this properly. I'm terribly sorry. I made the packages, and since i'm not running stable myself, i couldn't extensively test them. I'll fix this. -- | To be intoxicated is to feel sophisticated but not be able to say it. | 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8 9BDB D463 7E41 08CE C94D
Re: Snort: Mass Bug Closing
On Mon, Aug 25, 2003 at 10:25:28AM +0200, Sander Smeenk wrote: I've upgraded to this version and it has required me to press y to replace modified conffiles in /etc/snort/rules/ about two dozen times, while I'm pretty sure I never touched any of them. That's an pretty impressive amount of annoyance you managed to cause there. I wish I knew what I could do about that. It's some sort of a corner case situation in which actually unchanged files appear changed and dpkg prompts for them. Did the packages ever modify the files? Did they move them around? -- 2. That which causes joy or happiness.
Re: Snort: Mass Bug Closing
Quoting Jamin W. Collins ([EMAIL PROTECTED]): Before you object to this rather 'rude' bughandling, please keep in mind that version 1.8.4 of snort, which is in stable, has 3 severe security exploits, So, why hasn't a security update been released for it? There has been a DSA about Snort. That pointed to my previous backported packages. Neither me, nor the security team were able to backport the security fixes to 1.8.4, so this was the best approach, they thought. -- | How can there be self-help groups? | 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8 9BDB D463 7E41 08CE C94D
Re: Snort: Mass Bug Closing
Quoting Josip Rodin ([EMAIL PROTECTED]): I've upgraded to this version and it has required me to press y to replace modified conffiles in /etc/snort/rules/ about two dozen times, while I'm pretty sure I never touched any of them. That's an pretty impressive amount of annoyance you managed to cause there. I wish I knew what I could do about that. It's some sort of a corner case situation in which actually unchanged files appear changed and dpkg prompts for them. Did the packages ever modify the files? Did they move them around? I believe that in the real 1.8.4 release that is in woody, the rules files were all places in /etc/snort/ amongst the configuration files etc. In later releases the files moved to /etc/snort/rules/. I believe this change was introduced even before I adopted the package. -- | A conscience is what hurts when all of your other parts feel so good. | 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8 9BDB D463 7E41 08CE C94D
Re: Snort: Mass Bug Closing
On Sun, Aug 24, 2003 at 10:02:02PM -0400, Noah L. Meyerhans wrote: I can think off-hand of at least one other security related tool that needs frequent updating of a ruleset: nessus. It is an active probing tool that scans a network for vulnerable systems. If it doesn't have a current set of rules, it may fail to identify vulnerable systems, leading to the same issues that snort has. Yes, and the upstream and Debian maintainers are requesting the removal of the very old version from woody, see bug #183524. :| -- 2. That which causes joy or happiness.
Re: Snort: Mass Bug Closing
Quoting Sander Smeenk ([EMAIL PROTECTED]): Hi, I'm about to close 95153, 133049, 158040, 16, 170580, 173331, 176223, 135603, 161659, 165107, 165135, 165351, 171190, 172529, 173663, 174506, 174508, 174509, 192401, 193544, 101725, 122689, 159575, 165126, 182280, and 189780 with a nice message telling that the bug was reported on a Why not just tag these bugs as woody ? Then close them when sarge is released. This would prevent further bug reports on the exact same subject, at the minimum. You may then put the exact same message you proposed to send when closing the bugs, but with the control message you will send for tagging the bugs as woody.
Re: Snort: Mass Bug Closing
On Mon, Aug 25, 2003 at 10:19:55AM +0200, Sander Smeenk wrote: Quoting Javier Fernández-Sanguino Peña ([EMAIL PROTECTED]): (...) It's annoying now, to see what bugs really are bugs, and what are bugs You mean are bugs related to the latest version instead of really are bugs. filed against stable. Some submitters didn't even specify versionnumbers. Why don't you tag the bugs as such? (i.e. pertaining to 'stable') Before you object to this rather 'rude' bughandling, please keep in mind that version 1.8.4 of snort Then you should work towards fixing them in stable or having ftp-masters agreeing with including a new (backported) version at proposed-updates. We've been over this in debian-security before. I fixed the 1.8.4 package once, it got rejected, and I tried to have 2.0.x installed in Stable, but ofcourse, you can't put a new upstream version in a released stable Debian. Why did it get rejected? I'm surprised about that. As of putting a new upstream version in a released stable Debian it did happen in some ocasion (openssh anyone?) That's why i'm doing backports on p.d.o, and that's why i want the bugs closed if I can't fix them. But you have to agree with me that that's completely useless. It does not help users at all and it's even against their best interest (since they cannot see that the package is buggy!) The only thing that it helps is your 'karma' wrt to Debian-bug count :-) It's for the users best interrest that I tell them to use the new version. It is for the best interest of the users that you provide a proper snort version in proposed-updates. THEN LET ME! Do it, and maybe discuss here why it got rejected. ffs! I know the way i'm going now isn't the correct way, but the tight rules about updating stable prevent me from doing it any better. Staying with 1.8.4 in Stable is useless, it is out dated, which is bad for a security tool. Going with 2.0.1 is impossible, because it might (and probably will...) introduce new bugs to stable. So open a bug in ftp.debian.org, like it was done with Nessus, and have the security team or the Release Manager agree with you in including a new version instead of backporting. Those tight rules are not that tight, remember OpenSSH. This is a similar situation to #183524. We have to determine a way to remove packages completely out of stable (due to unfixable security bugs, for example) in a way that do not leave users exposed to these and their bugs. A pseudo-package. But then what. Have people not run snort while using stable? That is, as a matter of fact, what it has been proposing in some of the bug reports. You said so yourself in bug 173254 which, BTW, should be re-openened. And maybe re-assigned to the the release manager or the security team? Or tagged security, or whatever. Bugs should be handled, not closed. I'm sorry if i sound harsh, i don't mean to. That's because of the rest of the replies in this thread. don't take it personal okay ;) I won't. Regards Javi PS: Please don't CC me, I'm in the list. pgpNd2Eryd6uu.pgp Description: PGP signature
Re: Snort: Mass Bug Closing
On Sun, Aug 24, 2003 at 10:02:02PM -0400, Noah L. Meyerhans wrote: I can think off-hand of at least one other security related tool that needs frequent updating of a ruleset: nessus. It is an active probing tool that scans a network for vulnerable systems. If it doesn't have a current set of rules, it may fail to identify vulnerable systems, leading to the same issues that snort has. But nessus does provide a tool to download latest plugins (nessus-update-plugins) which provides a way to update regardless of your version (although some plugins might not work in older releases). Snort does not provide anything similar. Regards Javi pgp7bNn614zHm.pgp Description: PGP signature
On packages depending on up-to-date data (was Re: Snort: Mass Bug Closing)
On Sun, Aug 24, 2003 at 07:32:10PM -0400, Noah L. Meyerhans wrote: Snort depends on a set of rules to detect potentially malicious traffic. Obviously this set of rules needs to be updates on a regular basis in order to keep up with new security issues. The problem is that the version of snort in stable is old enough that the upstream maintainers are no longer releasing new rulesets for it. Thus, it can't detect potentially harmful traffic. That's not correct, it cannot detected _new_ potentially harmful traffic. There's quite a lot of potentially harmful traffic (stable) snort can detect. The fact that it's not up-to-date does not mean that it's useless, it means that it won't detect new attacks (but it will detect old attacks). Depending on your security policy that might, or might not, be enough. Really, the way to fix this package X needs data Y to be up-to-date is to: a) separate data from the package (Nessus plugins are available in the 'nessus-plugins' package and can be updated separately, for example) b) provide some way to retrieve new data (signatures, attacks, whatever) either: downloading them from the main site directly (as nessus-update-plugins does) or providing backported packages (and have them included in stable revisiones. Since in most cases there is no code involved, it's just data, maybe the Release Manager could be convinced to include new versions in revisions of the stable release. c) have a way to determine properly when new data needs a new engine and won't work with older versions and warn the user about it. This means that the engine needs to be programmed beforehand to understand a given dataset version and complain when the dataset is of a newer (and potentially worthless) version. That's the approach that all packages that depend on up-to-date data should take, and is sometimes something that should be coordinated with upstream. The fact that security-related software is more prone to this problem is just related to the way attacks are constantly appearing for vulnerable software. Unless a package providing a security tool does not implement the above there is no way (save for backports) that security software will be 100% useful and up-to-date (giving our release process) in a Debian stable release. That includes: - vulnerability assesment scanners (nessus, nikto, since new checks depend on new signatures) - anti-virus tools (clamav...) - intrusion detection systems if based on signatures (such as snort, but others, for example Tiger, might but not completely dependant on them) - spam-filter tools based on rules (spamassasin comes to mind) But keep in midn that's not just related to security tools (think of lintian, for example). That doesn't mean that it's worthless, however, it's just that it's usefulness decreases as time goes by and the tool's _data_ is not updated. Regards Javi
Re: Snort: Mass Bug Closing
On Mon, Aug 25, 2003 at 01:37:03PM +0200, Javier Fern?ndez-Sanguino Pe?a wrote: On Mon, Aug 25, 2003 at 10:19:55AM +0200, Sander Smeenk wrote: We've been over this in debian-security before. I fixed the 1.8.4 package once, it got rejected, and I tried to have 2.0.x installed in Stable, but ofcourse, you can't put a new upstream version in a released stable Debian. Why did it get rejected? I'm surprised about that. As of putting a new upstream version in a released stable Debian it did happen in some ocasion (openssh anyone?) Considering the disaster that the openssh update to potato was, and the bugs it caused, I'm not sure that that's a good example to bring up if you're *advocating* upgrading a package to a new upstream version ... Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Snort: Mass Bug Closing
On Mon, Aug 25, 2003 at 10:19:55AM +0200, Sander Smeenk wrote: The problem is that the buglist i'm having on snort now, consists of mainly bugs filed on the stable package of snort, which has been long solved in the later releases of snort that didn't make it in the release of Debian. So, tag them as such. If you close them, they will just be reopened by the next individual to find it in the stable package. Tagging it with the release effected. We've been over this in debian-security before. I fixed the 1.8.4 package once, it got rejected, and I tried to have 2.0.x installed in Stable, but ofcourse, you can't put a new upstream version in a released stable Debian. Actually that's not true, as an example I refer you to SSH. -- Jamin W. Collins This is the typical unix way of doing things: you string together lots of very specific tools to accomplish larger tasks. -- Vineet Kumar
Re: Snort: Mass Bug Closing
Sander Smeenk wrote: I'm about to close 95153, 133049, 158040, 16, 170580, 173331, 176223, 135603, 161659, 165107, 165135, 165351, 171190, 172529, 173663, 174506, 174508, 174509, 192401, 193544, 101725, 122689, 159575, 165126, 182280, and 189780 with a nice message telling that the bug was reported on a really old package-version and the bug is really old too, including a URL to an up to date version of the package, where most probably all these bugs are fixed. It would probably be better if you would send the information you prepared to nnn-submitter and tag those bugs `stable' and `wontfix' and close them after sarge is released and woody removed from ftp.debian.org. Regards, Joey -- GNU does not eliminate all the world's problems, only some of them. -- The GNU Manifesto Please always Cc to me when replying to me on the lists.
Re: Snort: Mass Bug Closing
On Mon, Aug 25, 2003 at 12:46:27PM +0100, Colin Watson wrote: Considering the disaster that the openssh update to potato was, and the bugs it caused, I'm not sure that that's a good example to bring up if you're *advocating* upgrading a package to a new upstream version ... Well, I was really giving a counter-example on the policy of do not upload new version, however that's up to the Release Manager and the Snort maintainer, of course. Regards Javi pgpl87U2h8077.pgp Description: PGP signature
Re: Snort: Mass Bug Closing
On Mon, 25 Aug 2003, Josip Rodin wrote: On Mon, Aug 25, 2003 at 10:25:28AM +0200, Sander Smeenk wrote: I've upgraded to this version and it has required me to press y to replace modified conffiles in /etc/snort/rules/ about two dozen times, while I'm pretty sure I never touched any of them. That's an pretty impressive amount of annoyance you managed to cause there. I wish I knew what I could do about that. It's some sort of a corner case situation in which actually unchanged files appear changed and dpkg prompts for them. Did the packages ever modify the files? Did they move them around? You know, I don't think that's the case, really.
Re: On packages depending on up-to-date data (was Re: Snort: Mass Bug Closing)
On Mon, Aug 25, 2003 at 01:56:40PM +0200, Javier Fern?ndez-Sanguino Pe?a wrote: That's not correct, it cannot detected _new_ potentially harmful traffic. There's quite a lot of potentially harmful traffic (stable) snort can detect. The fact that it's not up-to-date does not mean that it's useless, it means that it won't detect new attacks (but it will detect old attacks). Depending on your security policy that might, or might not, be enough. No. New attacks represent security threats. Old attacks represent curiosities, at best (i.e. have you seen any Redhat 6.2 rpc.statd attacks lately?) An intrusion detection system that can not detect known intrusions is not useful. It's dangerous in the same way that turning syslog off is dangerous: Well, there's nothing in the logs, so the system must be fine If you have a specific policy that allows you to only be interested in ancient attacks, good for you. We cannot expect our users to be in such a position. noah pgpXVAqht4O5f.pgp Description: PGP signature
Re: Snort: Mass Bug Closing
In response to several issues raised... http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=191105 Not having updated signatures is not an issue that should keep snort out of stable as administrators may write their own signatures for snort. Perhaps however a wishlist bug asking for a comment (to be put in the description) about signature updating and snort's value without updated signatures should be filed... I would even go so far to say that perhaps this is more than a wishlist issue, but as it's likely not RC then this false sense of security should be documented before snort gets frozen in sarge. The security updates can usually be backported when applicable. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=183719 and bug 189267 say: DSA 297 closes these bugs. It may be worth noting that potato was not affected. What other security issues are there? I made that statement given information from another party, was I incorrect? I'll look up my correspondence and even do some testing if you believe that I was wrong. The ssh precedent of updating non-rc issues in stable was due to no other clear way to resolve the rc issues and political pressure. As Colin Watson said, this is also not a good example as there were many bugs caused by this upgrade. Imho it's ok to close non-rc bugs on stable (main Debian developers do). My rational is that we only fix RC bugs on stable. I like your automated message to some of the bugs, it could probably be done to most of the bugs. I looked through some of the bugs and saw that: 95153 may not even be applicable to snort in stable but should be RC. 133049 seems to indicate to me that this old snort should probably be removed from a few archs. 158040 doesn't have your automated message. It means that snort is unusable. This is likely the problem that was mentioned to you about your backport. Merge 16, 176223 with it (also no automated message)? Is this an upgrade problem? 161659 talks about how a new config file doesn't get generated on even a fresh install. Perhaps this is the issue in 158040 et al? 165107 suggests that the config file/rule file problem is in sid sarge and woody? Tagging this correctly may help the testing script... 135603 is an upgrade problem... rules are incompatible. Is this a stable to stable upgrade? 173331 seems to be related to 158040 (missing config), but talks about how the cron script fails, patch included. 170580 looks like a problem with the debconf script. A simple, obvious workaround is mentioned. This sounds like an upgrade problem. 165135 is a policy violation, which versions are affected? Reported well after woody was released... A quick check of the source code could reveal the answer. I don't know if you should close the upgrade bugs as I've heard the argument users should only be using stable releases of packages and I don't know about snort in potato (is it there? does it upgrade correctly?). I'm getting a bit frustrated going through these myself. It seems that there's a lot of duplication, and (without testing) it looks like many of these bugs are still in sid. If you would like help going through these bugs, tagging them correctly, merging them, closing some, etc. I'd be happy to look even closer. Drew Daniels
Re: On packages depending on up-to-date data (was Re: Snort: Mass Bug Closing)
On Tue, Aug 26, 2003 at 12:24:11AM +0200, Sander Smeenk wrote: Really, the way to fix this package X needs data Y to be up-to-date is to: a) separate data from the package (Nessus plugins are available in the 'nessus-plugins' package and can be updated separately, for example) snort has that. snort-rules-default is the default set of rules found on snort.org for the release that is in debian, almost always updated when a new debian-release of the package is done. People can start packaging their own rulesets, maybe even local rulesets or something. Sure, I'm not saying that snort does not have it. I'm just saying that maybe you should consider upgrading the one in stable. The differences in format are known and you should be able to find a way to convert older rules set. b) provide some way to retrieve new data (signatures, attacks, whatever) either: downloading them from the main site directly (as nessus-update-plugins does) or providing backported packages (and have them included in stable revisiones. This problem only exists for snort packages that aren't going to be updated, like the ones that reach stable. The unstable package is up to date enough to have all correct rules, imho. You can convince the stable release manager to put a new snort-rules-default package into sarge, for example, 6 months after it is released. It's easier to do that than to try to push a new upstream version into sarge, and you will be providing the new rules users might want. In any case, I was thinking on the lines of a separate (not packaged) method to download rules directly from snort.org. Please take a look at the 'nessus-update-plugins' to see what I mean. The other thing is, snort.org's people quickly start to drop old rule formats when newer formats are used. Should I be the one that has to convert every rule back to the old format to have stable users of snort safe and sound? It'll take alot of time. And I believe it is not always scriptable. You are, after all, the snort package maintainer. If you don't want to do this you can try to find people who might volunteer to do the work for stable and provide a new snort-rules-default package for stable maybe converting some of the new rules which are no longer valid. Granted, some information might be lost in the conversion and some rules might not be converted, but still, better than no updates. So, although it sounds nice to have scripts to update rulefiles, I don't really see it happening, because of the problems amentioned above. If no one works to see that happen it will never be. c) have a way to determine properly when new data needs a new engine and won't work with older versions and warn the user about it. This means that the engine needs to be programmed beforehand to understand a given dataset version and complain when the dataset is of a newer (and potentially worthless) version. Well. Snort just fails to start if it can't parse the rule files. And usually that is with every major upstream release. :( [Short version: see the patch below.] [Long version: follows] That's obviously, suboptimal, snort should be able to determine in some way from a rules file if the format is a version it knows or it isn't. C'mon version headers are not unheard of, just take a look at the header of any HTML file in www.debian.org, it will tell you precisely which DTD to use to be able to understand it. It wouldn't be so difficult [1] to have snort analyse the rules file before including and determine if its rules can, or cannot, be added. Of course, that would be mean improving the way rules files are parsed currently. There is currently no distinction between snort's configuration and the rules files themselves (pv.config_file in snort.c) but if they were separated the ParseRulesFile in snort's parser.c could be rewritten to verify the call to ParseRule and not proceed if there is an indication that the rules belong to a new version. The adjointed patch (probably very ugly, untested and maybe broken) provides that functionality. If the snort parser encounters a place of the file which has 'version X' with X SNORT_MAJOR_VERSION then it will not go on reading the rest of the rules file. That way you can have rules in one file which are read by older snort versions and rules that cannot (maybe because the Parser has been enhanced to included new formats). Regards Javi --- parser.c.old2003-08-26 01:04:50.0 +0200 +++ parser.c2003-08-26 01:20:40.0 +0200 @@ -55,6 +55,8 @@ #include threshold.h #include snort.h +#define SNORT_MAJOR_VERSION 2 +/* SNORT_VERSION should probably be defined in the snort generic headers */ ListHead Alert; /* Alert Block Header */ ListHead Log; /* Log Block Header */ @@ -128,6 +130,7 @@ int stored_file_line = file_line; char *saved_line = NULL; int continuation = 0; +int continueread = 1;
Re: On packages depending on up-to-date data (was Re: Snort: Mass Bug Closing)
Quoting Javier Fernández-Sanguino Peña ([EMAIL PROTECTED]): Thus, it can't detect potentially harmful traffic. That's not correct, it cannot detected _new_ potentially harmful traffic. There's quite a lot of potentially harmful traffic (stable) snort can detect. The fact that it's not up-to-date does not mean that it's useless, it means that it won't detect new attacks (but it will detect old attacks). Depending on your security policy that might, or might not, be enough. If you don't care that much about security, snort isn't the right tool anyhow. Snort starts raising hell when a large ping packet comes across your interface, someone with such a low security interrest as you described would go nuts with snort. But, that aside, cause it's not what this is all about ;) Really, the way to fix this package X needs data Y to be up-to-date is to: a) separate data from the package (Nessus plugins are available in the 'nessus-plugins' package and can be updated separately, for example) snort has that. snort-rules-default is the default set of rules found on snort.org for the release that is in debian, almost always updated when a new debian-release of the package is done. People can start packaging their own rulesets, maybe even local rulesets or something. b) provide some way to retrieve new data (signatures, attacks, whatever) either: downloading them from the main site directly (as nessus-update-plugins does) or providing backported packages (and have them included in stable revisiones. This problem only exists for snort packages that aren't going to be updated, like the ones that reach stable. The unstable package is up to date enough to have all correct rules, imho. The other thing is, snort.org's people quickly start to drop old rule formats when newer formats are used. Should I be the one that has to convert every rule back to the old format to have stable users of snort safe and sound? It'll take alot of time. And I believe it is not always scriptable. So, although it sounds nice to have scripts to update rulefiles, I don't really see it happening, because of the problems amentioned above. c) have a way to determine properly when new data needs a new engine and won't work with older versions and warn the user about it. This means that the engine needs to be programmed beforehand to understand a given dataset version and complain when the dataset is of a newer (and potentially worthless) version. Well. Snort just fails to start if it can't parse the rule files. And usually that is with every major upstream release. :( Sander. -- | Ik zit met een dilemma en ik heb geen flauw idee wat ik ermee moet doen | 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8 9BDB D463 7E41 08CE C94D
Re: Snort: Mass Bug Closing
Quoting Drew Scott Daniels ([EMAIL PROTECTED]): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=183719 and bug 189267 say: DSA 297 closes these bugs. It may be worth noting that potato was not affected. What other security issues are there? Let's first start by telling that my backported packages never made it to security updates that every good stable user should have in their apt sources. The DSA just pointed users who actually read it to my p.d.o. site. There was a total of 3 advisories against snort. Two of them related to RPC, another to reconstructing fragmented packets IIRC(!). Imho it's ok to close non-rc bugs on stable (main Debian developers do). My rational is that we only fix RC bugs on stable. It also has an 'archival' kind of function where people can see what's wrong with a package if they experience weirdness. The thing is that the stable snort package is nothing but weirdness, and I can't fix it, but I do have this huge pile of bugs on my sheet that i'd like to rid of cause it really interferes with bug handling the unstable packages. 95153 may not even be applicable to snort in stable but should be RC. [ .. ] 158040 doesn't have your automated message. It means that snort is unusable. This is likely the problem that was mentioned to you about your backport. Merge 16, 176223 with it (also no automated message)? Is this an upgrade problem? The first automated message thing only went to submitters of critical, grave, important etc. bugs. 158040 is indeed similar to what Joy 'discovered' in my backported packages: a slip of the fingers of the maintainer who forgot to change the 'factory default' configuration file to point to the debian rule-path. It's not an upgrade problem, as long as I don't forget to set the path correctly, which most of the times I am quite capable of remembering ;) 161659 talks about how a new config file doesn't get generated on even a fresh install. Perhaps this is the issue in 158040 et al? No. The old stable package was incapable of filling in the debconf generated 'snort.debian.conf' that is sourced to start snort later on. This was one of the first problems I fixed when I took over the package. It has nothing to do with 158040. 165107 suggests that the config file/rule file problem is in sid sarge and woody? Tagging this correctly may help the testing script... This is (was) an upgrading problem. Because of the move of rule files from /etc/snort to /etc/snort/rules/. And I forgot to move some files in the postinst. Something like that. It has been fixed in later versions. 135603 is an upgrade problem... rules are incompatible. Is this a stable to stable upgrade? It's not a real upgrade problem. It's that someone has a combination of Debian releases in his aptsources, and both have versions of the snort packages, and snort did not depend on a specific version of the rule files, so apt thinks 'ah! snort-rules-default! already got that! no need to upgrade!' or something like that. 170580 looks like a problem with the debconf script. A simple, obvious workaround is mentioned. This sounds like an upgrade problem. What exacly do you mean with 'upgrade problem' ? The debconf scripts (or templates, iirc) in that release of the package were broken for some reason. 165135 is a policy violation, which versions are affected? Reported well after woody was released... A quick check of the source code could reveal the answer. It is a policy violation. Leftover, I guess. Stable doesn't have invoke-rc.d, I discovered that when I built and 'tested' the backported packages. I don't know if you should close the upgrade bugs as I've heard the argument users should only be using stable releases of packages and I don't know about snort in potato (is it there? does it upgrade correctly?). I haven't tried upgrading from 1.8.4 to any of my backported packages myself. Upgrading should go quite pain free, the only annoyance would be dpkg asking to overwrite each seperate rule file, as Joy also mentioned. I don't know what I can do about that, other dan grossly violating the policies to fix it. I'm getting a bit frustrated going through these myself. It seems that there's a lot of duplication, and (without testing) it looks like many of these bugs are still in sid. Ehm. Some of them are, but not the ones I mentioned in my original post. They are all fixed in the current backported release available at p.d.o. If you would like help going through these bugs, tagging them correctly, merging them, closing some, etc. I'd be happy to look even closer. Snort has a spot on alioth since a while and is now being co-maintained by Pascal Hakim (pasc@). The buildtrees for both the backported packages aswell as the unstable packages are in cvs. Any help is welcome. I just want to have a clean sheet and get a bit of overview of real problems that exist with snort. Like the BUS errors on sparc, for which workarounds came in? Thanks for your
Re: Snort: Mass Bug Closing
On Tue, Aug 26, 2003 at 12:46:45AM +0200, Sander Smeenk wrote: Quoting Drew Scott Daniels ([EMAIL PROTECTED]): Imho it's ok to close non-rc bugs on stable (main Debian developers do). My rational is that we only fix RC bugs on stable. It also has an 'archival' kind of function where people can see what's wrong with a package if they experience weirdness. The thing is that the stable snort package is nothing but weirdness, and I can't fix it, but I do have this huge pile of bugs on my sheet that i'd like to rid of cause it really interferes with bug handling the unstable packages. If they're being repeatedly reported, you can tag them woody and then add 'exclude=woody' to the URL you use to view your bugs. Would that help? Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Snort: Mass Bug Closing
On Sun, Aug 24, 2003 at 03:57:45PM +0200, Sander Smeenk wrote: Hi, I'm about to close 95153, 133049, 158040, 16, 170580, 173331, 176223, (...) I object. Instead I provide signed backported packages on p.d.o which I will keep 'semi up to date'. Still a lot of people use the outdated and utterly broken 1.8.4 release and complain. Although these complaints are correct, Maybe because they are not aware of your backporting efforts. I will from now on close them and tell the submitter to use my backported, newer packages or compile his/her own. Yes, these utterly broken release is in all Debian CDs and mirrors. Bugs are bugs, if they are not fixed then don't close them. BTW, they are not even tagged properly (i.e. 'stable') Before you object to this rather 'rude' bughandling, please keep in mind that version 1.8.4 of snort, which is in stable, has 3 severe security exploits, and is completely outdated in catching crooks (rulefiles) and detection mechanisms. Not to speak of package stability ;) Then you should work towards fixing them in stable or having ftp-masters agreeing with including a new (backported) version at proposed-updates. It's for the users best interrest that I tell them to use the new version. It is for the best interest of the users that you provide a proper snort version in proposed-updates. Having bugs closed in a package which is still distributed leads to a false sense of workability of the package. Having all these bugs marked 'stable' and tagged 'wontfix' tells users best that they should not be using them at all! For example, closing bug #173254 instead of reassigning it to www.debian.org or ftp.debian.org was not proper. It should be marked 'stable', or reassigned to other team! You should not close bugs just because you cannot solve them, they will not go away just because of that. This is a similar situation to #183524. We have to determine a way to remove packages completely out of stable (due to unfixable security bugs, for example) in a way that do not leave users exposed to these and their bugs. Having a dummy package at proposed-updates which just says please do X, Y, and z to have package A in your Debian stable system might be one of them. Regards Javi pgp1VE348GaBe.pgp Description: PGP signature
Re: Snort: Mass Bug Closing
Sander, in principle, I agree that fixing those bugs by backporting patches is not worth the effort, but let me suggest an alternative plan (which the SRM will hate me for, so you should probably ask him before): - Check which of those bugs are really fixed in the newest version - Upload a backported package that + Pre-Depends on debconf + in its preinst gives the user the choice to abort the installation along with a message describing the situation (no new rules in the old format, ...). + includes a script to convert rules from the old to the new format + closes all the bugs in the changelog (they will be closed when the SRM installs the packages in the next point release or on security, depending on what you and the SRM agree is more appropriate) This way, all users will benefit from the upgrade, not only those who have sent in bug reports. If people have written local rule files, they get the chance to convert them to the new format and are not suddenly left with a system that cannot read their rule files. While this may not be a good idea to go about every outdated package in stable, I do think this particular update makes sense. Also, you don't have to worry about other arches that way, since they will be autobuilt. Then go on backporting necessary fixes to that version, so people aren't forced into an incompatible upgrade again. Simon (who didn't mean to turn on his box while officially on vacation) -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 pgpJlG645KUrj.pgp Description: PGP signature
Re: Snort: Mass Bug Closing
On Sun, Aug 24, 2003 at 03:57:45PM +0200, Sander Smeenk wrote: Instead I provide signed backported packages on p.d.o which I will keep 'semi up to date'. Before you object to this rather 'rude' bughandling, please keep in mind that version 1.8.4 of snort, which is in stable, has 3 severe security exploits, and is completely outdated in catching crooks (rulefiles) and detection mechanisms. Not to speak of package stability ;) It's for the users best interrest that I tell them to use the new version. [2] deb http:///people.debian.org/~ssmeenk/snort-stable-i386/ ./ ~ Typo. I've upgraded to this version and it has required me to press y to replace modified conffiles in /etc/snort/rules/ about two dozen times, while I'm pretty sure I never touched any of them. That's an pretty impressive amount of annoyance you managed to cause there. -- 2. That which causes joy or happiness.
Re: Snort: Mass Bug Closing
On Sun, Aug 24, 2003 at 03:57:45PM +0200, Sander Smeenk wrote: Before you object to this rather 'rude' bughandling, please keep in mind that version 1.8.4 of snort, which is in stable, has 3 severe security exploits, So, why hasn't a security update been released for it? -- Jamin W. Collins Remember, root always has a loaded gun. Don't run around with it unless you absolutely need it. -- Vineet Kumar
Re: Snort: Mass Bug Closing
On Sun, Aug 24, 2003 at 04:51:08PM +0200, Josip Rodin wrote: Instead I provide signed backported packages on p.d.o which I will keep 'semi up to date'. Before you object to this rather 'rude' bughandling, please keep in mind that version 1.8.4 of snort, which is in stable, has 3 severe security exploits, and is completely outdated in catching crooks (rulefiles) and detection mechanisms. Not to speak of package stability ;) It's for the users best interrest that I tell them to use the new version. [2] deb http:///people.debian.org/~ssmeenk/snort-stable-i386/ ./ ~ Typo. I've upgraded to this version and it has required me to press y to replace modified conffiles in /etc/snort/rules/ about two dozen times, while I'm pretty sure I never touched any of them. That's an pretty impressive amount of annoyance you managed to cause there. Oh and it didn't even want to start properly -- and the init script wasn't even so kind to tell me, I had to learn from syslog that Aug 24 16:57:23 hostname snort: FATAL ERROR: Unable to open rules file: ../rules/bad-traffic.rules or /etc/snort/../rules/bad-traffic.rules All it took to make it work was to change RULE_PATH from ../rules to /etc/snort/rules, but it's still broken that it didn't detect this properly. -- 2. That which causes joy or happiness.
Re: Snort: Mass Bug Closing
On Sun, Aug 24, 2003 at 04:39:58PM +0200, Javier Fern?ndez-Sanguino Pe?a wrote: Before you object to this rather 'rude' bughandling, please keep in mind that version 1.8.4 of snort, which is in stable, has 3 severe security exploits, and is completely outdated in catching crooks (rulefiles) and detection mechanisms. Not to speak of package stability ;) Then you should work towards fixing them in stable or having ftp-masters agreeing with including a new (backported) version at proposed-updates. That's for Martin Schulze (Joey - Stable Release Manager) and/or the security team to decide; not ftpmaster. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgpZprBrwjcR3.pgp Description: PGP signature
Re: Snort: Mass Bug Closing
On Sun, Aug 24, 2003 at 08:59:06AM -0600, Jamin W. Collins wrote: Before you object to this rather 'rude' bughandling, please keep in mind that version 1.8.4 of snort, which is in stable, has 3 severe security exploits, So, why hasn't a security update been released for it? Largely this is because snort should simply be removed from stable completely, as it is not useful, even if the security exploits are fixed. Snort depends on a set of rules to detect potentially malicious traffic. Obviously this set of rules needs to be updates on a regular basis in order to keep up with new security issues. The problem is that the version of snort in stable is old enough that the upstream maintainers are no longer releasing new rulesets for it. Thus, it can't detect potentially harmful traffic. A person responsible for the security of a system or network of systems needs to know if attacks on current vulnerabilities are being made on his system at least as bad as he needs to know that two year old vulnerabilities are being probed. snort 1.8.4 cannot report such activity, and can only lead to a false sense of security. Thus, trusting an old version of snort is more dangerous than not using it at all, IMHO. In the case of tools like snort, I strongly believe that we either need to remove it from stable or permit new upstream versions to be released for stable with point releases. noah pgpcNGk76ZOYD.pgp Description: PGP signature
Re: Snort: Mass Bug Closing
Noah L. Meyerhans [EMAIL PROTECTED] writes: On Sun, Aug 24, 2003 at 08:59:06AM -0600, Jamin W. Collins wrote: Before you object to this rather 'rude' bughandling, please keep in mind that version 1.8.4 of snort, which is in stable, has 3 severe security exploits, So, why hasn't a security update been released for it? Largely this is because snort should simply be removed from stable completely, as it is not useful, even if the security exploits are fixed. Snort depends on a set of rules to detect potentially malicious traffic. Obviously this set of rules needs to be updates on a regular basis in order to keep up with new security issues. ... In the case of tools like snort, I strongly believe that we either need to remove it from stable or permit new upstream versions to be released for stable with point releases. Why don't you add an option to load newer rulesets and/or update information to snort. Once a day/week/month snort you probe some url for a signed ruleset or news file and report to the user about any updates. That way you can have the binary in stable and still provide changes on a more regular basis. Of cause you should first get up to a still suported version,but you could put that in the news file. MfG Goswin
Re: Snort: Mass Bug Closing
On Mon, Aug 25, 2003 at 01:33:37AM +0200, Goswin von Brederlow wrote: Why don't you add an option to load newer rulesets and/or update information to snort. Once a day/week/month snort you probe some url for a signed ruleset or news file and report to the user about any updates. That way you can have the binary in stable and still provide changes on a more regular basis. That's a perfect solution, but only works for the cases which the snort binary can understand the rulesets which are being downloaded. The way I understand the current situation the real problem is that the stable snort cannot understand the newer rule files; because it's simply too old. However the solution would have to be a little bit more complex than that which you select - blindly installing the rulesets might not be the best idea. I'd love to see a system which used a simple curses interface to: 1. List all new rulesets with a discription of their use. (eg. msblast.snrt - Alert on MSBlaster worm probes). 2. Upgrade all the rules which are currently installed. (Essentially apt-get + apt-cache for snort rules. Clearly packaging a single rule file within one package is a gross misuse of resources but it might be sufficient if they were signed and hosted somewhere sensible..) Steve -- pgpWkMvO3c77w.pgp Description: PGP signature
Re: Snort: Mass Bug Closing
On Mon, Aug 25, 2003 at 02:27:41AM +0100, Steve Kemp wrote: (Essentially apt-get + apt-cache for snort rules. Clearly packaging a single rule file within one package is a gross misuse of resources but it might be sufficient if they were signed and hosted somewhere sensible..) Such a system as you describe would be fine, and should somehow be incorporated into the Debian release design (especially since snort is by no means the only package that would benefit) but it doesn't get you around the current issue, which is that there simply are no new rules being developed for woody's snort. I can think off-hand of at least one other security related tool that needs frequent updating of a ruleset: nessus. It is an active probing tool that scans a network for vulnerable systems. If it doesn't have a current set of rules, it may fail to identify vulnerable systems, leading to the same issues that snort has. noah pgp0miX4DCekT.pgp Description: PGP signature
