Re: iptables not logging or dhcp-client lying?
On Wednesday, 2002-04-03 at 14:02:20 +0900, Olaf Meeuwissen wrote: I am playing with packet filtering on a DHCP client and trying to get it done the right way. The right way is to dispense with DHCP. The protocol has no security whatsoever. Read RFC2131, 7. Security Considerations for details. HTH, Lupe Christoph -- | [EMAIL PROTECTED] |http://free.prohosting.com/~lupe | | I have challenged the entire ISO-9000 quality assurance team to a | | Bat-Leth contest on the holodeck. They will not concern us again. | | http://public.logica.com/~stepneys/joke/klingon.htm| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on potato's proftpd
Release early; release often. -- Martin Wheeler [EMAIL PROTECTED] gpg key 01269BEB @ the.earth.li -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: iptables not logging or dhcp-client lying?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lupe Christoph [EMAIL PROTECTED] writes: On Wednesday, 2002-04-03 at 14:02:20 +0900, Olaf Meeuwissen wrote: I am playing with packet filtering on a DHCP client and trying to get it done the right way. The right way is to dispense with DHCP. The protocol has no security whatsoever. Read RFC2131, 7. Security Considerations for details. Although I may share your sympaties on this point (still have to read up on it), you assume I am in a position to do so. - -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE8qsWeFsfyfWvjfZARAjQLAJ0cA8X1NNPGDWBeVT2yh2PAp/2ZJwCfZf44 gDj83SMnXI2ATIDfg8SQGMA= =G8AJ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on potato's proftpd
On Wed, Apr 03, 2002 at 03:22:39AM +0200, martin f krafft wrote: but give me at least one argument why these acts cannot combine with a *temporary* fix uploaded to the so-called security archives. There are several good reasons: - If a band-aid fix is allowed, there is less incentive to find the correct fix. - If the problem isn't understood, there is a good chance that the band-aid doesn't really fix the problem, and a fair chance that it creates new problems. If there are related problems (eg, similar bugs in different programs), they may go undiscovered. - Users would have to upgrade again when the permanent fix is released. People running production systems like to minimize changes, so this could make them unhappy. I think Wichert's position Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: iptables not logging or dhcp-client lying?
Olaf Meeuwissen wrote: Basically, I'd like to keep the setup as closed as possible so I make a hole in /etc/dhclient-enter-hooks during the PREINIT stage to let the DHCPDISCOVER broadcast out (and a reply back in eventually, taking this one step at a time ;-). At least, that's what I thought I should do, but I noticed that packets are not logged! I think (but not sure) DHCP client is using (so called) raw sockets which are below the layer where iptables is in the kernel. That's why iptables is unable to see the packets. (There is an option for Raw sockets in the kernel, and it can be used only with root privileges.) KoGa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A question about some network services
On Wed, Apr 03, 2002 at 09:16:03AM +0200, Emmanuel Lacour wrote: 'time' is RFC 868, a pre-NTP time synchronization protocol. It just sends the time as a 32-bit int, where: The time is the number of seconds since 00:00 (midnight) 1 January 1900 GMT, such that the time 1 is 12:00:01 am on 1 January 1900 GMT; this base will serve until the year 2036. I think it sends it big-endian, but I'm not sure. Is it used by the old rdate tools? Indeed. It's quite usefull if you don't have a NTP server at hand, e. g. behind a firewall. It's not ok if you need accuracy of less than 1 sec. /Holger -- ++ GnuPG Key - http://www.t-online.de/~holger.eitzenberger ++ msg06190/pgp0.pgp Description: PGP signature
Re: on potato's proftpd
On Wed, Apr 03, 2002 at 10:56:32AM +0900, Howland, Curtis wrote: I would bet that the vast majority of flame wars begin because someone mistakes terse or concise for hostility. The reverse, being the endless spewing of meaningless words, all the while saying nothing at all or even the opposite of what it sounds like, is the art of politicians and diplomats. I'll take a flame war any day, when compared to the alternative. aol -- Share and Enjoy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on potato's proftpd
On Wed, Apr 03, 2002 at 09:22:34AM +, Martin WHEELER wrote: Release early; release often. bemfont size=7blinkNO/font/em/b Measure twice, cut once. -- Share and Enjoy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on potato's proftpd
On Wed, Apr 03, 2002 at 02:43:10PM -0800, Petro wrote: On Wed, Apr 03, 2002 at 09:22:34AM +, Martin WHEELER wrote: Release early; release often. bemfont size=7blinkNO/font/em/b Measure twice, cut once. i haven't really been following this thread, but i like analogies as much as the next person, so how's this: if you don't have a tape measure, cut large and sand down as needed. xn -- Share and Enjoy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on potato's proftpd
also sprach Andrew Pimlott [EMAIL PROTECTED] [2002.04.03.1754 +0200]: There are several good reasons: - If a band-aid fix is allowed, there is less incentive to find the correct fix. true. doesn't mean that we have to fall into that hole. - If the problem isn't understood, there is a good chance that the band-aid doesn't really fix the problem, and a fair chance that it creates new problems. If there are related problems (eg, similar bugs in different programs), they may go undiscovered. this problem is understood by the developers of proftpd, and their suggestion (if an upgrade to a newer version isn't an option -- which applies to potato) is this temporary fix. then look at the fix and ask yourself how this band-aid could cause other problems, keeping the FTP protocol in mind. - Users would have to upgrade again when the permanent fix is released. People running production systems like to minimize changes, so this could make them unhappy. i also administer production systems, and while i just as well possess a certain inertia with respect to upgrading the packages their, i always try to get security updates tested and distributed as soon as possible... -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; net@madduck information superhighway is just an anagram for i'm on a huge wispy rhino fart. msg06194/pgp0.pgp Description: PGP signature
Re: on potato's proftpd
also sprach Nathan E Norman [EMAIL PROTECTED] [2002.04.03.0732 +0200]: well, i am calm, but i disagree. sure, it boils down to the question who debian's audience are, but for all i am concerned, debian's reputation _used_ to include security, and the reason why i'd (as in would and had) install(ed) debian was because i didn't need to be worrying about the obvious and hence i could spend my resources on other things. had i wanted to patch one-year-old bugs in software that installs from the security archives, then i might have just chosen to fly redhat. i don't understand why you aren't understanding this. i am not at all against finding the real bug as well as investigating why: See, paragraphs like this directly contradict you statement above that you don't want a flame war. Debian used to include security? Apparently you no longer run Debian? Does this mean you've wiothdrawn your name for the NM queue? no and no. i will continue to run debian and i'll support the project! i am just joining in with the group of people who see debian's reputation and quality not keeping up with what it used to be. i see no alternative to debian and so i want to prevent this degradation, simple as that. i am also not attacking anyone, not even the project. what i wrote is based on facts and experience, and if at all, then it should give everyone partaking in the project something to think about. Are you willing to abandon the hyperbole and put forward rational arguments as to why your solution is best? because it will prevent s.d.o from serving a buggy package. it's not fixed perfectly, but at least it's not subject to a known exploit. it's not the best, but it's IMHO really only beaten by the fix of the root of the bug *right now*. this fix isn't available, so i suggest bridging the time until we can patch proftpd properly with a temporary fix. you know, just so that when i have s.d.o in my sources.list, i can actually rely on debian as i usually do. The temporary patch is, well, temporary. It only works on a new install; otherwise the admin has to examine their config file by hand to make the change. well, we have debconf to help. and postinst scripts can be quite intelligent... Worst of all, since the bug was thought to be fixed but isn't, the temporary fix may not in fact prevent the exploit. If the exploit is part of libc globbing code, it may be exploitable in other code, not just proftpd. of course. i am not arguing against that. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; net@madduck there's an old proverb that says just about whatever you want it to. msg06196/pgp0.pgp Description: PGP signature
Re: on potato's proftpd
On Thu, Apr 04, 2002 at 01:09:27AM +0200, martin f krafft wrote: this problem is understood by the developers of proftpd Wichert said that nobody has explained why the current fix on s.d.o doesn't work. If the problem is understood, why hasn't someone explained this? That's all that is asked, AFAICT. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on potato's proftpd
On Thu, Apr 04, 2002 at 01:06:26AM +0200, martin f krafft wrote: because it will prevent s.d.o from serving a buggy package. it's not fixed perfectly, but at least it's not subject to a known exploit. Could you be a little more careful with your terms? A DOS is not an exploit, it's a DOS. By saying exploit your implying a far more critical problem than actually exists. -- Mike Stone msg06198/pgp0.pgp Description: PGP signature
Re: DoS in debian (potato) proftpd: 1.2.0pre10-2.0potato1
At 03:40 PM 3/29/2002, martin f krafft wrote: ls */../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../* ... DenyFilter \*.*/ Just as a quick question, why not deny the string /../ (you may have to deny the regex /\.\./, depending how the filter in question works)? As far as I can tell, it's the ability to embed /../ into a path that is at the root of this, far more than the ability to embed wildcards. I can't think of a situation in which /../ should appear in a user-supplied path, except after a string of repeated ../s. The workaround suggested by Mr Krafft would disable some useful functionality - one large user of mine, for instance, was keen to have my own software evaluate wildcards in the body of the path, which Mr Krafft's workaround disables completely. They even paid for the privilege (not enough, but they paid ;-)) So, let's see, a regex that would deny /../, except as part of a string of such... One bash would be [^/.].*/\.\./ - matching /../ if it's after any character other than '/' or '.'. Doubtless someone can come up with something better. Alun. -- Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us at 1602 Harvest Moon Place | http://www.wftpd.com or email [EMAIL PROTECTED] Cedar Park TX 78613-1419 | VISA/MC accepted. NT-based sites, be sure to Fax/Voice +1(512)258-9858 | read details of WFTPD Pro for NT. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
DoS in Shells: was Re: DoS in debian (potato) proftpd: 1.2.0pre10-2.0potato1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello All, I can confirm that the ls strings dos' slackware 8.0. Causes shell process of that user (user or root) to chew up the cpu until the shell terminates on sig 11. Works on any shell the user is using, csh, ksh, bash Tested on: Linux 2.2.19 #93 Thu Jun 21 01:09:03 PDT 2001 i586 unknown SunOS 5.8 Generic_108528-12 sun4u sparc SUNW,Ultra-Enterprise Not Vuln: OpenBSD 3.0 GENERIC#94 i386 Needs more investigation. Gilbert At 03:40 PM 3/29/2002, martin f krafft wrote: ls */../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../* ... DenyFilter \*.*/ Just as a quick question, why not deny the string /../ (you may have to deny the regex /\.\./, depending how the filter in question works)? As far as I can tell, it's the ability to embed /../ into a path that is at the root of this, far more than the ability to embed wildcards. I can't think of a situation in which /../ should appear in a user-supplied path, except after a string of repeated ../s. The workaround suggested by Mr Krafft would disable some useful functionality - one large user of mine, for instance, was keen to have my own software evaluate wildcards in the body of the path, which Mr Krafft's workaround disables completely. They even paid for the privilege (not enough, but they paid ;-)) So, let's see, a regex that would deny /../, except as part of a string of such... One bash would be [^/.].*/\.\./ - matching /../ if it's after any character other than '/' or '.'. Doubtless someone can come up with something better. Alun. - -- Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us at 1602 Harvest Moon Place | http://www.wftpd.com or email [EMAIL PROTECTED] Cedar Park TX 78613-1419 | VISA/MC accepted. NT-based sites, be sure to Fax/Voice +1(512)258-9858 | read details of WFTPD Pro for NT. Hush provide the worlds most secure, easy to use online applications - which solution is right for you? HushMail Secure Email http://www.hushmail.com/ HushDrive Secure Online Storage http://www.hushmail.com/hushdrive/ Hush Business - security for your Business http://www.hush.com/ Hush Enterprise - Secure Solutions for your Enterprise http://www.hush.com/ Looking for a good deal on a domain name? http://www.hush.com/partners/offers.cgi?id=domainpeople -BEGIN PGP SIGNATURE- Version: Hush 2.1 Note: This signature can be verified at https://www.hushtools.com wlwEARECABwFAjyr6acVHHJlYWt0b3JAaHVzaG1haWwuY29tAAoJEJajR/iRqwen8mkA oKWAhCudyOHNoO0TfIeYih8gNz+LAJwNhnWkwhJz0GVeZ4sAuxTE9JP5PA== =Sgqo -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A question about some network services
On Tue, Apr 02, 2002 at 11:49:53AM -0700, Will Aoki wrote: On Tue, Apr 02, 2002 at 10:23:21AM -0800, Anne Carasik wrote: On Tue, Apr 02, 2002 at 07:45:21PM +0200, eim wrote: A question about some network services == Hallo Debian folks, By default, on my debian boxes, I disable this network services which are enabled automaticly during a fresh Debian stable aka potato installtion: * daytime * time * discard All this services are stareted from inet.d / xinet.d so I can easily disable them via update-inetd, so my only question is: Why are this services enabled by default and for 'what' exactly do we need them ? Well, daytime spits out the time of day, time is for NTP, and I'm not sure what discard is used for. 'time' is RFC 868, a pre-NTP time synchronization protocol. It just sends the time as a 32-bit int, where: The time is the number of seconds since 00:00 (midnight) 1 January 1900 GMT, such that the time 1 is 12:00:01 am on 1 January 1900 GMT; this base will serve until the year 2036. I think it sends it big-endian, but I'm not sure. Is it used by the old rdate tools? -- Easter-eggsSp?cialiste GNU/Linux 44-46 rue de l'Ouest - 75014 Paris - France - M?tro Gait? Phone: +33 (0) 1 43 35 00 37- Fax: +33 (0) 1 41 35 00 76 mailto:[EMAIL PROTECTED] -http://www.easter-eggs.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: iptables not logging or dhcp-client lying?
On Wednesday, 2002-04-03 at 14:02:20 +0900, Olaf Meeuwissen wrote: I am playing with packet filtering on a DHCP client and trying to get it done the right way. The right way is to dispense with DHCP. The protocol has no security whatsoever. Read RFC2131, 7. Security Considerations for details. HTH, Lupe Christoph -- | [EMAIL PROTECTED] |http://free.prohosting.com/~lupe | | I have challenged the entire ISO-9000 quality assurance team to a | | Bat-Leth contest on the holodeck. They will not concern us again. | | http://public.logica.com/~stepneys/joke/klingon.htm| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: iptables not logging or dhcp-client lying?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lupe Christoph [EMAIL PROTECTED] writes: On Wednesday, 2002-04-03 at 14:02:20 +0900, Olaf Meeuwissen wrote: I am playing with packet filtering on a DHCP client and trying to get it done the right way. The right way is to dispense with DHCP. The protocol has no security whatsoever. Read RFC2131, 7. Security Considerations for details. Although I may share your sympaties on this point (still have to read up on it), you assume I am in a position to do so. - -- Olaf MeeuwissenEpson Kowa Corporation, CID GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90 LPIC-2 -- I hack, therefore I am -- BOFH -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQE8qsWeFsfyfWvjfZARAjQLAJ0cA8X1NNPGDWBeVT2yh2PAp/2ZJwCfZf44 gDj83SMnXI2ATIDfg8SQGMA= =G8AJ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on potato's proftpd
Release early; release often. -- Martin Wheeler [EMAIL PROTECTED] gpg key 01269BEB @ the.earth.li -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on potato's proftpd
On Wed, Apr 03, 2002 at 03:22:39AM +0200, martin f krafft wrote: but give me at least one argument why these acts cannot combine with a *temporary* fix uploaded to the so-called security archives. There are several good reasons: - If a band-aid fix is allowed, there is less incentive to find the correct fix. - If the problem isn't understood, there is a good chance that the band-aid doesn't really fix the problem, and a fair chance that it creates new problems. If there are related problems (eg, similar bugs in different programs), they may go undiscovered. - Users would have to upgrade again when the permanent fix is released. People running production systems like to minimize changes, so this could make them unhappy. I think Wichert's position Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on potato's proftpd
[ Followup to incomplete send. ] On Wed, Apr 03, 2002 at 10:54:25AM -0500, Andrew Pimlott wrote: I think Wichert's position ... reflects appropriate discipline, given the (relatively modest) severity of the problem. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: iptables not logging or dhcp-client lying?
Olaf Meeuwissen wrote: Basically, I'd like to keep the setup as closed as possible so I make a hole in /etc/dhclient-enter-hooks during the PREINIT stage to let the DHCPDISCOVER broadcast out (and a reply back in eventually, taking this one step at a time ;-). At least, that's what I thought I should do, but I noticed that packets are not logged! I think (but not sure) DHCP client is using (so called) raw sockets which are below the layer where iptables is in the kernel. That's why iptables is unable to see the packets. (There is an option for Raw sockets in the kernel, and it can be used only with root privileges.) KoGa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A question about some network services
On Wed, Apr 03, 2002 at 09:16:03AM +0200, Emmanuel Lacour wrote: 'time' is RFC 868, a pre-NTP time synchronization protocol. It just sends the time as a 32-bit int, where: The time is the number of seconds since 00:00 (midnight) 1 January 1900 GMT, such that the time 1 is 12:00:01 am on 1 January 1900 GMT; this base will serve until the year 2036. I think it sends it big-endian, but I'm not sure. Is it used by the old rdate tools? Indeed. It's quite usefull if you don't have a NTP server at hand, e. g. behind a firewall. It's not ok if you need accuracy of less than 1 sec. /Holger -- ++ GnuPG Key - http://www.t-online.de/~holger.eitzenberger ++ pgpcZ6pzizXFh.pgp Description: PGP signature
Re: on potato's proftpd
On Wed, Apr 03, 2002 at 10:56:32AM +0900, Howland, Curtis wrote: I would bet that the vast majority of flame wars begin because someone mistakes terse or concise for hostility. The reverse, being the endless spewing of meaningless words, all the while saying nothing at all or even the opposite of what it sounds like, is the art of politicians and diplomats. I'll take a flame war any day, when compared to the alternative. aol -- Share and Enjoy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on potato's proftpd
also sprach Andrew Pimlott [EMAIL PROTECTED] [2002.04.03.1754 +0200]: There are several good reasons: - If a band-aid fix is allowed, there is less incentive to find the correct fix. true. doesn't mean that we have to fall into that hole. - If the problem isn't understood, there is a good chance that the band-aid doesn't really fix the problem, and a fair chance that it creates new problems. If there are related problems (eg, similar bugs in different programs), they may go undiscovered. this problem is understood by the developers of proftpd, and their suggestion (if an upgrade to a newer version isn't an option -- which applies to potato) is this temporary fix. then look at the fix and ask yourself how this band-aid could cause other problems, keeping the FTP protocol in mind. - Users would have to upgrade again when the permanent fix is released. People running production systems like to minimize changes, so this could make them unhappy. i also administer production systems, and while i just as well possess a certain inertia with respect to upgrading the packages their, i always try to get security updates tested and distributed as soon as possible... -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] information superhighway is just an anagram for i'm on a huge wispy rhino fart. pgpcKekOX0o7x.pgp Description: PGP signature
Re: on potato's proftpd
also sprach Andrew Pimlott [EMAIL PROTECTED] [2002.04.03.1805 +0200]: On Wed, Apr 03, 2002 at 10:54:25AM -0500, Andrew Pimlott wrote: I think Wichert's position ... reflects appropriate discipline, given the (relatively modest) severity of the problem. i also have to agree with you here since the problem isn't all that bad after all. but it's not the problem which is making me react in such loud ways, it's the principle of why a buggy package in s.d.o doesn't get prioritized attention... -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] printer not ready. could be a fatal error. have a pen handy? pgp967E9LC6aY.pgp Description: PGP signature
Re: on potato's proftpd
also sprach Nathan E Norman [EMAIL PROTECTED] [2002.04.03.0732 +0200]: well, i am calm, but i disagree. sure, it boils down to the question who debian's audience are, but for all i am concerned, debian's reputation _used_ to include security, and the reason why i'd (as in would and had) install(ed) debian was because i didn't need to be worrying about the obvious and hence i could spend my resources on other things. had i wanted to patch one-year-old bugs in software that installs from the security archives, then i might have just chosen to fly redhat. i don't understand why you aren't understanding this. i am not at all against finding the real bug as well as investigating why: See, paragraphs like this directly contradict you statement above that you don't want a flame war. Debian used to include security? Apparently you no longer run Debian? Does this mean you've wiothdrawn your name for the NM queue? no and no. i will continue to run debian and i'll support the project! i am just joining in with the group of people who see debian's reputation and quality not keeping up with what it used to be. i see no alternative to debian and so i want to prevent this degradation, simple as that. i am also not attacking anyone, not even the project. what i wrote is based on facts and experience, and if at all, then it should give everyone partaking in the project something to think about. Are you willing to abandon the hyperbole and put forward rational arguments as to why your solution is best? because it will prevent s.d.o from serving a buggy package. it's not fixed perfectly, but at least it's not subject to a known exploit. it's not the best, but it's IMHO really only beaten by the fix of the root of the bug *right now*. this fix isn't available, so i suggest bridging the time until we can patch proftpd properly with a temporary fix. you know, just so that when i have s.d.o in my sources.list, i can actually rely on debian as i usually do. The temporary patch is, well, temporary. It only works on a new install; otherwise the admin has to examine their config file by hand to make the change. well, we have debconf to help. and postinst scripts can be quite intelligent... Worst of all, since the bug was thought to be fixed but isn't, the temporary fix may not in fact prevent the exploit. If the exploit is part of libc globbing code, it may be exploitable in other code, not just proftpd. of course. i am not arguing against that. -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] there's an old proverb that says just about whatever you want it to. pgpuzwr05YVtu.pgp Description: PGP signature
Re: on potato's proftpd
On Wed, Apr 03, 2002 at 02:43:10PM -0800, Petro wrote: On Wed, Apr 03, 2002 at 09:22:34AM +, Martin WHEELER wrote: Release early; release often. bemfont size=7blinkNO/font/em/b Measure twice, cut once. i haven't really been following this thread, but i like analogies as much as the next person, so how's this: if you don't have a tape measure, cut large and sand down as needed. xn -- Share and Enjoy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on potato's proftpd
On Thu, Apr 04, 2002 at 01:09:27AM +0200, martin f krafft wrote: this problem is understood by the developers of proftpd Wichert said that nobody has explained why the current fix on s.d.o doesn't work. If the problem is understood, why hasn't someone explained this? That's all that is asked, AFAICT. Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: on potato's proftpd
On Thu, Apr 04, 2002 at 01:06:26AM +0200, martin f krafft wrote: because it will prevent s.d.o from serving a buggy package. it's not fixed perfectly, but at least it's not subject to a known exploit. Could you be a little more careful with your terms? A DOS is not an exploit, it's a DOS. By saying exploit your implying a far more critical problem than actually exists. -- Mike Stone pgph90bx8uvSu.pgp Description: PGP signature
Re: DoS in debian (potato) proftpd: 1.2.0pre10-2.0potato1
At 03:40 PM 3/29/2002, martin f krafft wrote: ls */../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../* ... DenyFilter \*.*/ Just as a quick question, why not deny the string /../ (you may have to deny the regex /\.\./, depending how the filter in question works)? As far as I can tell, it's the ability to embed /../ into a path that is at the root of this, far more than the ability to embed wildcards. I can't think of a situation in which /../ should appear in a user-supplied path, except after a string of repeated ../s. The workaround suggested by Mr Krafft would disable some useful functionality - one large user of mine, for instance, was keen to have my own software evaluate wildcards in the body of the path, which Mr Krafft's workaround disables completely. They even paid for the privilege (not enough, but they paid ;-)) So, let's see, a regex that would deny /../, except as part of a string of such... One bash would be [^/.].*/\.\./ - matching /../ if it's after any character other than '/' or '.'. Doubtless someone can come up with something better. Alun. -- Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us at 1602 Harvest Moon Place | http://www.wftpd.com or email [EMAIL PROTECTED] Cedar Park TX 78613-1419 | VISA/MC accepted. NT-based sites, be sure to Fax/Voice +1(512)258-9858 | read details of WFTPD Pro for NT. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
DoS in Shells: was Re: DoS in debian (potato) proftpd: 1.2.0pre10-2.0potato1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello All, I can confirm that the ls strings dos' slackware 8.0. Causes shell process of that user (user or root) to chew up the cpu until the shell terminates on sig 11. Works on any shell the user is using, csh, ksh, bash Tested on: Linux 2.2.19 #93 Thu Jun 21 01:09:03 PDT 2001 i586 unknown SunOS 5.8 Generic_108528-12 sun4u sparc SUNW,Ultra-Enterprise Not Vuln: OpenBSD 3.0 GENERIC#94 i386 Needs more investigation. Gilbert At 03:40 PM 3/29/2002, martin f krafft wrote: ls */../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../*/../* ... DenyFilter \*.*/ Just as a quick question, why not deny the string /../ (you may have to deny the regex /\.\./, depending how the filter in question works)? As far as I can tell, it's the ability to embed /../ into a path that is at the root of this, far more than the ability to embed wildcards. I can't think of a situation in which /../ should appear in a user-supplied path, except after a string of repeated ../s. The workaround suggested by Mr Krafft would disable some useful functionality - one large user of mine, for instance, was keen to have my own software evaluate wildcards in the body of the path, which Mr Krafft's workaround disables completely. They even paid for the privilege (not enough, but they paid ;-)) So, let's see, a regex that would deny /../, except as part of a string of such... One bash would be [^/.].*/\.\./ - matching /../ if it's after any character other than '/' or '.'. Doubtless someone can come up with something better. Alun. - -- Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us at 1602 Harvest Moon Place | http://www.wftpd.com or email [EMAIL PROTECTED] Cedar Park TX 78613-1419 | VISA/MC accepted. NT-based sites, be sure to Fax/Voice +1(512)258-9858 | read details of WFTPD Pro for NT. Hush provide the worlds most secure, easy to use online applications - which solution is right for you? HushMail Secure Email http://www.hushmail.com/ HushDrive Secure Online Storage http://www.hushmail.com/hushdrive/ Hush Business - security for your Business http://www.hush.com/ Hush Enterprise - Secure Solutions for your Enterprise http://www.hush.com/ Looking for a good deal on a domain name? http://www.hush.com/partners/offers.cgi?id=domainpeople -BEGIN PGP SIGNATURE- Version: Hush 2.1 Note: This signature can be verified at https://www.hushtools.com wlwEARECABwFAjyr6acVHHJlYWt0b3JAaHVzaG1haWwuY29tAAoJEJajR/iRqwen8mkA oKWAhCudyOHNoO0TfIeYih8gNz+LAJwNhnWkwhJz0GVeZ4sAuxTE9JP5PA== =Sgqo -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
