Re: portsentry dangerous? hardly; RTFM. (was Re: checking security logs)
thomas lakofski [EMAIL PROTECTED] writes:
On 29 Jan 2001, Rainer Weikusat wrote:
Random garbage traveling across the 'net is exactly this: Random
garbage.
ok, and?
Why bother?
If I suffer from dynamic IP allocations, you would be blocking
hundreds of IPs within a comparatively short amount of time
[...]
I think the machine can manage to handle executing a command every three
seconds.
Probably. But checking every incoming packet against some hundred
bogus filtering rules will degrade network performance, possibly in a
way that might get noticed.
Why do you worry about holes in programs you don't even run?
I'm not worried about holes in programs I don't even run. I'm interested in
detecting, and taking action against, actions which appear to be
suspicious.
Like prohpylacticyally lynching certain 32-bit-numbers?
If I know what's happening on the box, I don't need a tool like this,
as I don't run any services except those I intend to, with the latter
ones being reasonably configured.
I still want to detect behaviour indicative of an attack
You *cannot*. You can recognize an attack that's happening, not a
possibly happening attack. For instance, shortly after w2k hit the
'net, machines from all over the world startet flooding us with
packets to port 28800, which, due to a dialup-link, became quite
expensive to us. Nethertheless, this probably wasn't an attack, but a
simple configuration problem (and I don't even know if it was
Windows-related. It just happened around the same time).
and take action.
Your TCP/IP-stack would take that action ("dumping of garbage
packets") automatically.
I have a default-deny firewall with portsentry.
Consider a default-REJECT firewall. This is a lot nicer to others.
Until someone uses it as a mirror for a denial of service attack.
Or a certain person comes accross a certain RFC, wherein 'they talk'
of ICMP rate limiting.
Legitimate traffic will never have any problems.
Legitmate traffic will have problems, given the situation outlined in
my previous post.
mode=flame
Was that too complicated for you or are have you simply been
lobotomized in the past?
/
They will, as demonstrated above.
Unlikely; at least, it hasn't happened in the last 3 or so years.
There's no way for you to tell.
--
SIGSTOP
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: portsentry dangerous? hardly
ICS - Eelco van Beek [EMAIL PROTECTED] writes: Portsentry is just wonderfull for blocking people running subnet scans for certain ports that you're machine isn't providing any services for All ports I don't provide services on _are blocked_. Would you please dig that? -- SIGSTOP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Is debian OpenBSD ftpd secure?
Hi. I ran SAINT over my system today, and it highlighted a possible vulnerability in the "ftpd" package[1]. I believe this relates to "anonymous" access. Now, access to the "anonymous" account is disabled in the /etc/ftpusers file, which I understand leads to this: ... Name (ftp.houseofmoran.com:mm): anonymous 331 Guest login ok, send your complete e-mail address as password. Password: 530 Login incorrect. Login failed. ftp bye 221 Goodbye. It fails even if you give a valid email address. I take it that this is because the strategy is to not give away immediately that access is denied, like login does with non-existent accounts? However, SAINT still seems to pick this up as a vulnerability. Is this just because the SAINT detection routines get fooled by the almost-successful login, or is there actually a real vulnerability? Thanks, [1]: ftpd 0.11-8potato.1 -- [EMAIL PROTECTED] Web: http://houseofmoran.com/ AvantGo: http://houseofmoran.com/Lite/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is debian OpenBSD ftpd secure?
On Tue, 30 Jan 2001 15:45:50 Mike Moran wrote: | | Hi. I ran SAINT over my system today, and it highlighted a possible | vulnerability in the "ftpd" package[1]. I believe this relates to | "anonymous" access. There was a security bug recently, which was fixed in the woody release. As far as I know, it wasn't fixed in potato (but did it exist in potato? I recompiled woody's for potato) | Now, access to the "anonymous" account is disabled in the /etc/ftpusers | file, which I understand leads to this: | | ... | Name (ftp.houseofmoran.com:mm): anonymous | 331 Guest login ok, send your complete e-mail address as password. | Password: | 530 Login incorrect. | Login failed. | ftp bye | 221 Goodbye. | | It fails even if you give a valid email address. I take it that this is | because the strategy is to not give away immediately that access is | denied, like login does with non-existent accounts? Yes. | However, SAINT still seems to pick this up as a vulnerability. Is this | just because the SAINT detection routines get fooled by the | almost-successful login, or is there actually a real vulnerability? It shouldn't. Its "best practice" to ALWAYS ask for a password, even if the account is disabled. Does SAINT give any more info? | Thanks, | | [1]: ftpd 0.11-8potato.1 | | -- | [EMAIL PROTECTED] |Web: http://houseofmoran.com/ |AvantGo: http://houseofmoran.com/Lite/ | | | -- | To UNSUBSCRIBE, email to [EMAIL PROTECTED] | with a subject of "unsubscribe". Trouble? Contact | [EMAIL PROTECTED] | Kind regards, Berend -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Berend De Schouwer, +27-11-712-1435, UCS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is debian OpenBSD ftpd secure?
Berend De Schouwer wrote: On Tue, 30 Jan 2001 15:45:50 Mike Moran wrote: [ ... ] | However, SAINT still seems to pick this up as a vulnerability. Is this | just because the SAINT detection routines get fooled by the | almost-successful login, or is there actually a real vulnerability? It shouldn't. Its "best practice" to ALWAYS ask for a password, even if the account is disabled. Does SAINT give any more info? Not that I remember (I don't have SAINT available here right now). It just highlighted the OpenBSD server in its vulnerability list, and gave a link to a list of known problems with a whole load of ftp servers. OpenBSD was mentioned in the section about anonymous access vulnerability. However, from my reading, it is only vulnerable if the "anonymous" account is available for login. Still, I'd like to be sure that it isn't vulnerable; the previous (RH) machine I was on got hit by the Ramen Worm last week, so I'd like to be doubly sure I am safe from similar attacks on debian. Are there any other SAINT-like vulnerability testers that I could double check it with? -- [EMAIL PROTECTED] Web: http://houseofmoran.com/ AvantGo: http://houseofmoran.com/Lite/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is debian OpenBSD ftpd secure?
On Tue, 30 Jan 2001 16:37:03 Mike Moran wrote: | Berend De Schouwer wrote: | | On Tue, 30 Jan 2001 15:45:50 Mike Moran wrote: | [ ... ] | | | However, SAINT still seems to pick this up as a vulnerability. Is | this | | just because the SAINT detection routines get fooled by the | | almost-successful login, or is there actually a real vulnerability? | | It shouldn't. Its "best practice" to ALWAYS ask for a password, | even if the account is disabled. Does SAINT give any more info? | | Not that I remember (I don't have SAINT available here right now). It | just highlighted the OpenBSD server in its vulnerability list, and gave | a link to a list of known problems with a whole load of ftp servers. Nothing specific? Then please try the SAINT people for info. | OpenBSD was mentioned in the section about anonymous access | vulnerability. However, from my reading, it is only vulnerable if the | "anonymous" account is available for login. Still, I'd like to be sure | that it isn't vulnerable; the previous (RH) machine I was on got hit by | the Ramen Worm last week, so I'd like to be doubly sure I am safe from | similar attacks on debian. If the ftpd server is vulnerable if anonymous is allowed, it usually means its vulnerable if "at least" anonymous is allowed. Usually its "even worse" if other logins are available. The two bugs I do know about, which got fixed in OpenBSD over the last year, are the setproctitle() bug, and the replydirname() bug. Are there any others? The version in potato (just apt-get source ftpd now), does not contain the replydirname() function at all, and setproctitle() seems fine. Disclaimer applies. Someone correct me if I am wrong... | Are there any other SAINT-like vulnerability testers that I could double | check it with? Maybe nessus? | -- | [EMAIL PROTECTED] |Web: http://houseofmoran.com/ |AvantGo: http://houseofmoran.com/Lite/ | Kind regards, Berend -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Berend De Schouwer, +27-11-712-1435, UCS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: portsentry dangerous? hardly; RTFM. (was Re: checking securitylogs)
On 30 Jan 2001, Rainer Weikusat wrote: mode=flame Was that too complicated for you or are have you simply been lobotomized in the past? / leaving aside the above... They will, as demonstrated above. Unlikely; at least, it hasn't happened in the last 3 or so years. There's no way for you to tell. ipchains -L -n now talking of lobotomies... end of topic. -thomas -- who's watching your watchmen? gpg: pub 1024D/81FD4B43 sub 4096g/BB6D2B11=p.nu/d 2B72 53DB 8104 2041 BDB4 F053 4AE5 01DF 81FD 4B43 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: portsentry dangerous? hardly; RTFM. (was Re: checking security logs)
thomas lakofski [EMAIL PROTECTED] writes: On 30 Jan 2001, Rainer Weikusat wrote: leaving aside the above... ... for obvious reasons. They will, as demonstrated above. Unlikely; at least, it hasn't happened in the last 3 or so years. There's no way for you to tell. ipchains -L -n As I've demonstrated to you how someone with enough spare time could cause large amounts of dynamically allocated IPs to be blocked by you without any need for him to be associated with said IPs any longer, this is meaningless. now talking of lobotomies... end of topic. You misinterpreted me. I was talking about thought-resistance. -- SIGSTOP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: glibc LD_PRELOAD
Ethan Benson wrote: is potato vulnerable to the LD_PRELOAD file overwriting vulnerability discussed at http://www.securityfocus.com/vdb/bottom.html?vid=2223 there was an unexplained libc6 update on Jan 10 for i386 (but not powerpc, not sure about other archs) to security.debian.org, all the changelog mentions is `Add backported security patch from glibc 2.2' current version of libc6 on powerpc is: 2.1.3-13 current version of libc6 on i386 is: 2.1.3-15 I believe there have been attempts to fix this, atleast in 2.1.3-16 and later. From the 2.1.3-16 changelog: * Ok, include Solar Designers nifty patch for more security issues. Thanks to Solar again for making me do a double release :) -- Ben Collins [EMAIL PROTECTED] Sun, 14 Jan 2001 00:30:17 -0500 However 2.1.3-17 exhibits odd behavior which I mentioned to Ben in a private email, though he hasn't got back to me on if its now deemed "normal" or whatever. Basically ldd doesn't work as expected anymore, as illustrated by: [60]polyphony~/ls -l /usr/bin/wall -rwxr-sr-x1 root tty 9276 Jul 27 2000 /usr/bin/wall [61]polyphony~/ldd /usr/bin/wall y0 wall: /dev/:0: No such file or directory Broadcast Message from jamie@polyphony (/dev/pts/4) at 13:20 ... y0 [62]polyphony~/sudo su - polyphony:~# ldd /usr/bin/wall hrmmm wall: /dev/:0: No such file or directory Broadcast Message from jamie@polyphony (/dev/pts/4) at 13:21 ... hrmmm polyphony:~# I have no idea if this has further reaching consequences, but ldd didn't used to actually execute the programs you ran it on. This seems to only affect sgid applications. -- Jamie Heilman http://audible.transient.net/~jamie/ "Most people wouldn't know music if it came up and bit them on the ass." -Frank Zappa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
CA-2000-22 Feedback VU-23382365 (LPRng)
I am the maintainer of the LPRng package for the Debian GNU/Linux distribution. I have noticed in your advisory that Debian does not have an entry in the Vendor Inofrmation appendix and would like to correct that. I apologise for the very late notice. In our stable distribution, LPRng versions below 3.6.12-7 are vulnerable and it is highly recommended to upgrade to 3.6.12-8 (3.6.12-7 has a serious non-security related bug). Please note that it is Debian policy to back-port serious bug fixes to our stable distribution as we have done in this case. In unstable/testing distribution, LPRng version below 3.6.24-3 are vulnerable. It is recommended to upgrade to at least 3.6.26-1 or better. 3.6.24-3 fixes the syslog security bug (as mentioned in this advisory) while 3.6.26-1 fixes a NLSPATH/gettext security bug. Both of these versions have been available since mid October. Finally, I have some comments about other versions. I am not sure that it is a good idea to recommend 3.6.25 from Patrick, you may want to check with him but an odd number implies test code. My suggestion is 3.6.26 Also I believe there is no such version 3.6.24 from RedHat. RedHat uses the same numbering system as Debian. Putting 3.6.24 confuses people as RedHat's 3.6.24-1 IS vulnerable (equivalent to Debian 3.6.24-1 and -2) but RedHat's 3.6.24-2 IS NOT vulnerable (equivalent to Debian 3.6.24-3). FYI 3.6.24-2 means that Debian/RedHat have made a localised change. Anything with a -1 version means a largely unchanged version from what we get from Patrick Powell. - Craig Debian LPRng maintainer -- Craig Small VK2XLZ GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.eye-net.com.au/[EMAIL PROTECTED] MIEEE [EMAIL PROTECTED] Debian developer [EMAIL PROTECTED] PGP signature
Re: portsentry dangerous? hardly; RTFM. (was Re: checking security logs)
On Tue, Jan 30, 2001 at 04:56:12PM +, thomas lakofski wrote: ipchains -L -n Excuse me if I'm missing the point, but what will this show other than any rules you already have in place? Cheers, Tom -- Your CHEEKS sit like twin NECTARINES above a MOUTH that knows no BOUNDS -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: portsentry dangerous? hardly; RTFM. (was Re: checking security logs)
On Wed, Jan 31, 2001 at 12:54:41AM +, Quietman wrote: On Tue, Jan 30, 2001 at 04:56:12PM +, thomas lakofski wrote: ipchains -L -n Excuse me if I'm missing the point, but what will this show other than any rules you already have in place? And obviously, how many packets have been intercepted by that rule. Cheers, Tom -- On-line, adj.: The idea that a human being should always be accessible to a computer. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: portsentry dangerous? hardly; RTFM. (was Re: checking security logs)
thomas lakofski [EMAIL PROTECTED] writes: On 29 Jan 2001, Rainer Weikusat wrote: Random garbage traveling across the 'net is exactly this: Random garbage. ok, and? Why bother? If I suffer from dynamic IP allocations, you would be blocking hundreds of IPs within a comparatively short amount of time [...] I think the machine can manage to handle executing a command every three seconds. Probably. But checking every incoming packet against some hundred bogus filtering rules will degrade network performance, possibly in a way that might get noticed. Why do you worry about holes in programs you don't even run? I'm not worried about holes in programs I don't even run. I'm interested in detecting, and taking action against, actions which appear to be suspicious. Like prohpylacticyally lynching certain 32-bit-numbers? If I know what's happening on the box, I don't need a tool like this, as I don't run any services except those I intend to, with the latter ones being reasonably configured. I still want to detect behaviour indicative of an attack You *cannot*. You can recognize an attack that's happening, not a possibly happening attack. For instance, shortly after w2k hit the 'net, machines from all over the world startet flooding us with packets to port 28800, which, due to a dialup-link, became quite expensive to us. Nethertheless, this probably wasn't an attack, but a simple configuration problem (and I don't even know if it was Windows-related. It just happened around the same time). and take action. Your TCP/IP-stack would take that action (dumping of garbage packets) automatically. I have a default-deny firewall with portsentry. Consider a default-REJECT firewall. This is a lot nicer to others. Until someone uses it as a mirror for a denial of service attack. Or a certain person comes accross a certain RFC, wherein 'they talk' of ICMP rate limiting. Legitimate traffic will never have any problems. Legitmate traffic will have problems, given the situation outlined in my previous post. mode=flame Was that too complicated for you or are have you simply been lobotomized in the past? / They will, as demonstrated above. Unlikely; at least, it hasn't happened in the last 3 or so years. There's no way for you to tell. -- SIGSTOP
Re: portsentry dangerous? hardly
ICS - Eelco van Beek [EMAIL PROTECTED] writes: Portsentry is just wonderfull for blocking people running subnet scans for certain ports that you're machine isn't providing any services for All ports I don't provide services on _are blocked_. Would you please dig that? -- SIGSTOP
glibc LD_PRELOAD
is potato vulnerable to the LD_PRELOAD file overwriting vulnerability discussed at http://www.securityfocus.com/vdb/bottom.html?vid=2223 there was an unexplained libc6 update on Jan 10 for i386 (but not powerpc, not sure about other archs) to security.debian.org, all the changelog mentions is `Add backported security patch from glibc 2.2' current version of libc6 on powerpc is: 2.1.3-13 current version of libc6 on i386 is: 2.1.3-15 -- Ethan Benson http://www.alaska.net/~erbenson/ pgpU4Ru6wpj7i.pgp Description: PGP signature
Is debian OpenBSD ftpd secure?
Hi. I ran SAINT over my system today, and it highlighted a possible vulnerability in the ftpd package[1]. I believe this relates to anonymous access. Now, access to the anonymous account is disabled in the /etc/ftpusers file, which I understand leads to this: ... Name (ftp.houseofmoran.com:mm): anonymous 331 Guest login ok, send your complete e-mail address as password. Password: 530 Login incorrect. Login failed. ftp bye 221 Goodbye. It fails even if you give a valid email address. I take it that this is because the strategy is to not give away immediately that access is denied, like login does with non-existent accounts? However, SAINT still seems to pick this up as a vulnerability. Is this just because the SAINT detection routines get fooled by the almost-successful login, or is there actually a real vulnerability? Thanks, [1]: ftpd 0.11-8potato.1 -- [EMAIL PROTECTED] Web: http://houseofmoran.com/ AvantGo: http://houseofmoran.com/Lite/
Re: Is debian OpenBSD ftpd secure?
On Tue, 30 Jan 2001 15:45:50 Mike Moran wrote: | | Hi. I ran SAINT over my system today, and it highlighted a possible | vulnerability in the ftpd package[1]. I believe this relates to | anonymous access. There was a security bug recently, which was fixed in the woody release. As far as I know, it wasn't fixed in potato (but did it exist in potato? I recompiled woody's for potato) | Now, access to the anonymous account is disabled in the /etc/ftpusers | file, which I understand leads to this: | | ... | Name (ftp.houseofmoran.com:mm): anonymous | 331 Guest login ok, send your complete e-mail address as password. | Password: | 530 Login incorrect. | Login failed. | ftp bye | 221 Goodbye. | | It fails even if you give a valid email address. I take it that this is | because the strategy is to not give away immediately that access is | denied, like login does with non-existent accounts? Yes. | However, SAINT still seems to pick this up as a vulnerability. Is this | just because the SAINT detection routines get fooled by the | almost-successful login, or is there actually a real vulnerability? It shouldn't. Its best practice to ALWAYS ask for a password, even if the account is disabled. Does SAINT give any more info? | Thanks, | | [1]: ftpd 0.11-8potato.1 | | -- | [EMAIL PROTECTED] |Web: http://houseofmoran.com/ |AvantGo: http://houseofmoran.com/Lite/ | | | -- | To UNSUBSCRIBE, email to [EMAIL PROTECTED] | with a subject of unsubscribe. Trouble? Contact | [EMAIL PROTECTED] | Kind regards, Berend -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Berend De Schouwer, +27-11-712-1435, UCS
Re: Is debian OpenBSD ftpd secure?
Berend De Schouwer wrote: On Tue, 30 Jan 2001 15:45:50 Mike Moran wrote: [ ... ] | However, SAINT still seems to pick this up as a vulnerability. Is this | just because the SAINT detection routines get fooled by the | almost-successful login, or is there actually a real vulnerability? It shouldn't. Its best practice to ALWAYS ask for a password, even if the account is disabled. Does SAINT give any more info? Not that I remember (I don't have SAINT available here right now). It just highlighted the OpenBSD server in its vulnerability list, and gave a link to a list of known problems with a whole load of ftp servers. OpenBSD was mentioned in the section about anonymous access vulnerability. However, from my reading, it is only vulnerable if the anonymous account is available for login. Still, I'd like to be sure that it isn't vulnerable; the previous (RH) machine I was on got hit by the Ramen Worm last week, so I'd like to be doubly sure I am safe from similar attacks on debian. Are there any other SAINT-like vulnerability testers that I could double check it with? -- [EMAIL PROTECTED] Web: http://houseofmoran.com/ AvantGo: http://houseofmoran.com/Lite/
Re: Is debian OpenBSD ftpd secure?
On Tue, 30 Jan 2001 16:37:03 Mike Moran wrote: | Berend De Schouwer wrote: | | On Tue, 30 Jan 2001 15:45:50 Mike Moran wrote: | [ ... ] | | | However, SAINT still seems to pick this up as a vulnerability. Is | this | | just because the SAINT detection routines get fooled by the | | almost-successful login, or is there actually a real vulnerability? | | It shouldn't. Its best practice to ALWAYS ask for a password, | even if the account is disabled. Does SAINT give any more info? | | Not that I remember (I don't have SAINT available here right now). It | just highlighted the OpenBSD server in its vulnerability list, and gave | a link to a list of known problems with a whole load of ftp servers. Nothing specific? Then please try the SAINT people for info. | OpenBSD was mentioned in the section about anonymous access | vulnerability. However, from my reading, it is only vulnerable if the | anonymous account is available for login. Still, I'd like to be sure | that it isn't vulnerable; the previous (RH) machine I was on got hit by | the Ramen Worm last week, so I'd like to be doubly sure I am safe from | similar attacks on debian. If the ftpd server is vulnerable if anonymous is allowed, it usually means its vulnerable if at least anonymous is allowed. Usually its even worse if other logins are available. The two bugs I do know about, which got fixed in OpenBSD over the last year, are the setproctitle() bug, and the replydirname() bug. Are there any others? The version in potato (just apt-get source ftpd now), does not contain the replydirname() function at all, and setproctitle() seems fine. Disclaimer applies. Someone correct me if I am wrong... | Are there any other SAINT-like vulnerability testers that I could double | check it with? Maybe nessus? | -- | [EMAIL PROTECTED] |Web: http://houseofmoran.com/ |AvantGo: http://houseofmoran.com/Lite/ | Kind regards, Berend -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Berend De Schouwer, +27-11-712-1435, UCS
Re: portsentry dangerous? hardly; RTFM. (was Re: checking security logs)
On 30 Jan 2001, Rainer Weikusat wrote: mode=flame Was that too complicated for you or are have you simply been lobotomized in the past? / leaving aside the above... They will, as demonstrated above. Unlikely; at least, it hasn't happened in the last 3 or so years. There's no way for you to tell. ipchains -L -n now talking of lobotomies... end of topic. -thomas -- who's watching your watchmen? gpg: pub 1024D/81FD4B43 sub 4096g/BB6D2B11=p.nu/d 2B72 53DB 8104 2041 BDB4 F053 4AE5 01DF 81FD 4B43
Re: glibc LD_PRELOAD
Ethan Benson wrote: is potato vulnerable to the LD_PRELOAD file overwriting vulnerability discussed at http://www.securityfocus.com/vdb/bottom.html?vid=2223 there was an unexplained libc6 update on Jan 10 for i386 (but not powerpc, not sure about other archs) to security.debian.org, all the changelog mentions is `Add backported security patch from glibc 2.2' current version of libc6 on powerpc is: 2.1.3-13 current version of libc6 on i386 is: 2.1.3-15 I believe there have been attempts to fix this, atleast in 2.1.3-16 and later. From the 2.1.3-16 changelog: * Ok, include Solar Designers nifty patch for more security issues. Thanks to Solar again for making me do a double release :) -- Ben Collins [EMAIL PROTECTED] Sun, 14 Jan 2001 00:30:17 -0500 However 2.1.3-17 exhibits odd behavior which I mentioned to Ben in a private email, though he hasn't got back to me on if its now deemed normal or whatever. Basically ldd doesn't work as expected anymore, as illustrated by: [60]polyphony~/ls -l /usr/bin/wall -rwxr-sr-x1 root tty 9276 Jul 27 2000 /usr/bin/wall [61]polyphony~/ldd /usr/bin/wall y0 wall: /dev/:0: No such file or directory Broadcast Message from [EMAIL PROTECTED] (/dev/pts/4) at 13:20 ... y0 [62]polyphony~/sudo su - polyphony:~# ldd /usr/bin/wall hrmmm wall: /dev/:0: No such file or directory Broadcast Message from [EMAIL PROTECTED] (/dev/pts/4) at 13:21 ... hrmmm polyphony:~# I have no idea if this has further reaching consequences, but ldd didn't used to actually execute the programs you ran it on. This seems to only affect sgid applications. -- Jamie Heilman http://audible.transient.net/~jamie/ Most people wouldn't know music if it came up and bit them on the ass. -Frank Zappa
CA-2000-22 Feedback VU-23382365 (LPRng)
I am the maintainer of the LPRng package for the Debian GNU/Linux distribution. I have noticed in your advisory that Debian does not have an entry in the Vendor Inofrmation appendix and would like to correct that. I apologise for the very late notice. In our stable distribution, LPRng versions below 3.6.12-7 are vulnerable and it is highly recommended to upgrade to 3.6.12-8 (3.6.12-7 has a serious non-security related bug). Please note that it is Debian policy to back-port serious bug fixes to our stable distribution as we have done in this case. In unstable/testing distribution, LPRng version below 3.6.24-3 are vulnerable. It is recommended to upgrade to at least 3.6.26-1 or better. 3.6.24-3 fixes the syslog security bug (as mentioned in this advisory) while 3.6.26-1 fixes a NLSPATH/gettext security bug. Both of these versions have been available since mid October. Finally, I have some comments about other versions. I am not sure that it is a good idea to recommend 3.6.25 from Patrick, you may want to check with him but an odd number implies test code. My suggestion is 3.6.26 Also I believe there is no such version 3.6.24 from RedHat. RedHat uses the same numbering system as Debian. Putting 3.6.24 confuses people as RedHat's 3.6.24-1 IS vulnerable (equivalent to Debian 3.6.24-1 and -2) but RedHat's 3.6.24-2 IS NOT vulnerable (equivalent to Debian 3.6.24-3). FYI 3.6.24-2 means that Debian/RedHat have made a localised change. Anything with a -1 version means a largely unchanged version from what we get from Patrick Powell. - Craig Debian LPRng maintainer -- Craig Small VK2XLZ GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.eye-net.com.au/[EMAIL PROTECTED] MIEEE [EMAIL PROTECTED] Debian developer [EMAIL PROTECTED] pgpRdfQ3UV4GF.pgp Description: PGP signature
Disappointment in security handling in Debian
G'day, I'm writing this to express my frustration at the slowness Debian seems to be afflicted with when it comes to letting people know about our security vulnerabilities and fixes. We seem to be able to find, fix and upload fixed packages quite quickly, however we are usually the last to let others know that they should upgrade to the new packages, making our users unnecessarily vulnerable. Take the LPRng syslog() bug for example. I've just had to email CERT myself because there is no advisory. If it is my responsibility to write these things, then it should be clearly stated for all developers somewhere. If it is not, then it should be clearly stated what I am supposed to do to make it happen. This fix was mid-October, it is now mid-January. Taking 3 months to write something up is clearly not acceptable and something needs to be done to correct it. I'm sick of seeing emails saying basically a user thought we were vulnerable until they accidently stumbled upon some obscure email somewhere. We are not doing the project or our users justice with these delays. - Craig -- Craig Small VK2XLZ GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 Eye-Net Consulting http://www.eye-net.com.au/[EMAIL PROTECTED] MIEEE [EMAIL PROTECTED] Debian developer [EMAIL PROTECTED] pgpxp6kDvxIUE.pgp Description: PGP signature
Re: portsentry dangerous? hardly; RTFM. (was Re: checking security logs)
On Tue, Jan 30, 2001 at 04:56:12PM +, thomas lakofski wrote: ipchains -L -n Excuse me if I'm missing the point, but what will this show other than any rules you already have in place? Cheers, Tom -- Your CHEEKS sit like twin NECTARINES above a MOUTH that knows no BOUNDS --
Re: portsentry dangerous? hardly; RTFM. (was Re: checking security logs)
On Wed, Jan 31, 2001 at 12:54:41AM +, Quietman wrote: On Tue, Jan 30, 2001 at 04:56:12PM +, thomas lakofski wrote: ipchains -L -n Excuse me if I'm missing the point, but what will this show other than any rules you already have in place? And obviously, how many packets have been intercepted by that rule. Cheers, Tom -- On-line, adj.: The idea that a human being should always be accessible to a computer.
