Microsoft Security Bulletin MS01-015

2001-03-06 Thread Microsoft Product Security
The following is a Security Bulletin from the Microsoft Product Security Notification Service. Please do not reply to this message, as it was sent from an unattended mailbox. -BEGIN PGP SIGNED MESSAGE- - --

[SECURITY] [DSA-032-1] proftp runs as root, /var symlink removal

2001-03-06 Thread debian-security-announce
-BEGIN PGP SIGNED MESSAGE- - Debian Security Advisory DSA-032-1 [EMAIL PROTECTED] http://www.debian.org/security/ Wichert Akkerman March 7, 2001 - --

Re: Loopback and multi-homed routing flaw in TCP/IP stack.

2001-03-06 Thread Woody
Darren Reed wrote: > > In some mail from Woody, sie said: > > > > Subject: Loopback and multi-homed routing flaw in TCP/IP stack. > > Author: Woody <[EMAIL PROTECTED]> > > > > We believe there to be a serious security flaw in the TCP/IP stack of > > several Unix-like operating systems. Whilst bein

Re: Loopback and multi-homed routing flaw in TCP/IP stack.

2001-03-06 Thread Crist Clark
bert hubert wrote: [snip] > I still feel that this is a pretty stupid oversight - if routing is switched > off as it SHOULD or even MUST be on a host, this is not supposed to happen. People keep saying this and I don't think they mean it. "ROUTING" is never turned off on host doing IP (at least

Re: Loopback and multi-homed routing flaw in TCP/IP stack.

2001-03-06 Thread bert hubert
On Tue, Mar 06, 2001 at 01:34:18PM +0300, 3APA3A wrote: > Windows NT behaves same way - it will accept connection to internal > address through external interface even if routing is not enabled (I'm > not sure about loopback). Then configuring Cisco routers it's quite One thing that hasn't

Re: Loopback and multi-homed routing flaw in TCP/IP stack.

2001-03-06 Thread Robert Collins
In recent versions (2.3 I believe) Squid has acl types for the listening port & ip that the request was recieved on, as well as the source ip of the request. There is no concept of LAT as such, just a series of acl checks that every request must pass to be serviced. Thus it is easy for existing

Passwords in Net.Commerce/WebSphere decryptable, any version

2001-03-06 Thread Rasmus Petersen
Seems like the IBM Net.Commerce Remote Arbitrary Command Execution Vulnerability discovered by Rudi Cantrell is more dangerous than first thought of.    http://suqdiq.tripod.com       - rasmus petersen

Re: Loopback and multi-homed routing flaw in TCP/IP stack.

2001-03-06 Thread Darren Reed
In some mail from Woody, sie said: > > Subject: Loopback and multi-homed routing flaw in TCP/IP stack. > Author: Woody <[EMAIL PROTECTED]> > > We believe there to be a serious security flaw in the TCP/IP stack of > several Unix-like operating systems. Whilst being "known" behavior on > technical m

MDKSA-2001:026 - joe update

2001-03-06 Thread Linux Mandrake Security Team
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Linux-Mandrake Security Update Advisory Package name: joe Date:

Re: Loopback and multi-homed routing flaw in TCP/IP stack.

2001-03-06 Thread Martin Macok
On Tue, Mar 06, 2001 at 01:34:18PM +0300, 3APA3A wrote: > I believe solution for this problem may be something like > > ipfw add allow all via lo* > ipfw add deny all to 127.0.0.0/8 > > if you want this behavior to be changed. (In case Linux 2.4 ''suffer'' ... I had no time to test it but o

Re: [Fwd: Re: Loopback and multi-homed routing flaw in TCP/IP stack.]

2001-03-06 Thread Ben Laurie
Aleph1 wrote: > A flaw in the standard not on the stack. RFC 1122 "Requirements for > Internet > Hosts -- Communication Layers" covers this issue although without > pointing > out its security consequences. In the case that a host is not routing, it is abundantly clear that the strong model is th

Re: Loopback and multi-homed routing flaw in TCP/IP stack.

2001-03-06 Thread David Litchfield
> > >We believe there to be a serious security flaw in the TCP/IP stack of > > >several Unix-like operating systems. Whilst being "known" behavior on > > >technical mailing lists, we feel that the implications of this > > >"feature" are unexpected. Furthermore, not all platforms behave in the > >

Immunix OS Security update for joe

2001-03-06 Thread Greg KH
--- Immunix OS Security Advisory Packages updated: joe Affected products: Immunix OS 6.2 and 7.0-beta Bugs Fixed: immunix/1329 Date: March 6, 2001 Advisory ID:IMNX-200

Re: Loopback and multi-homed routing flaw in TCP/IP stack.

2001-03-06 Thread Kurt Seifried
Kurt Seifried, [EMAIL PROTECTED] Securityportal - your focal point for security on the 'net > 2.2 is vulnerable, but 2.4 is not. as far as i can tell, 2.4 systems > don't even have a localhost routing entry anymore. > > martin Huh? loLink encap:Local Loopback inet addr:127.0

Re: Loopback and multi-homed routing flaw in TCP/IP stack.

2001-03-06 Thread 3APA3A
Hello Woody, Monday, March 05, 2001, 10:44:43 PM, you wrote: W> There is a flaw in the TCP/IP stack, such that packets intended for W> loopback and/or local network interfaces, routed via any other W> interface, will be delivered EVEN IF THE MACHINE IS CONFIGURED NOT W> TO BE A GATEWAY (n

Warftp 1.67b04 Directory Traversal

2001-03-06 Thread se00020
Overview: by adding a special formed argument to the dir command, it is possible to list the /../ directory. Detail: the command is the following: dir *./../.. Log: Verbindung mit 10.17.3.44 wurde hergestellt. 220- Jgaa's Fan Club FTP Service WAR-FTPD 1.67- 04 Ready 220 Please enter your user

Re: Loopback and multi-homed routing flaw in TCP/IP stack.

2001-03-06 Thread Kyle Sparger
Mad Duck wrote: > 2.2 is vulnerable, but 2.4 is not. as far as i can tell, 2.4 systems > don't even have a localhost routing entry anymore. Actually I can confirm that Linux 2.4 does suffer from it, at least in the hardwired MAC address case I mentioned. Just took the time to test it. Andrew Ba

Re: Loopback and multi-homed routing flaw in TCP/IP stack.

2001-03-06 Thread Lars Mathiesen
On Mar 5, 20:07, Neil W Rickert wrote: > I am surprised to see this described as a flaw. It is behavior I > have been relying on for some time. Specifically, on my client > machines, I add a route to the alternate interface of my servers via > the direct interface of the same server. This allow

Re: Loopback and multi-homed routing flaw in TCP/IP stack.

2001-03-06 Thread J. Bol
> 2.2 is vulnerable, but 2.4 is not. as far as i can tell, 2.4 systems > don't even have a localhost routing entry anymore. We've been testing with a kernel 2.2.16 victim, which is standard with RH7.0 and an attacker with kernel 2.0.34. I can see packets comming in from the attacker, but the kern

Re: Loopback and multi-homed routing flaw in TCP/IP stack.

2001-03-06 Thread Dan Harkless
Perry Harrington <[EMAIL PROTECTED]> writes: > I don't think the behavior should change because of DSR. DSR is more > useful than 'rightness' in my opinion. A switch to turn it off if you > don't want it is something I'd advocate, but the default should be 'on'. Why? Using direct service retur

Re: Loopback and multi-homed routing flaw in TCP/IP stack.

2001-03-06 Thread Ben Laurie
Perry Harrington wrote: > > On Tue, Mar 06, 2001 at 09:05:32AM +, Ben Laurie wrote: > > when routing is disabled. Further, there's no circumstance I can think > > of where it makes sense to route 127/8 from an external interface! That > > It's not 127/8 that we're talking about. You can assig

Re: Loopback and multi-homed routing flaw in TCP/IP stack.

2001-03-06 Thread Ben Laurie
John Cronin wrote: > > > The Issue: > > > > > > There is a flaw in the TCP/IP stack, such that packets intended for > > > loopback and/or local network interfaces, routed via any other > > > interface, will be delivered EVEN IF THE MACHINE IS CONFIGURED NOT TO > > > BE A GATEWAY (note that in the

Re: Loopback and multi-homed routing flaw in TCP/IP stack.

2001-03-06 Thread Perry Harrington
On Tue, Mar 06, 2001 at 09:05:32AM +, Ben Laurie wrote: > when routing is disabled. Further, there's no circumstance I can think > of where it makes sense to route 127/8 from an external interface! That It's not 127/8 that we're talking about. You can assign perfectly valid real world IPs to

Re: Loopback and multi-homed routing flaw in TCP/IP stack.

2001-03-06 Thread David Damerell
On Mon, 5 Mar 2001, Lothar Beta wrote: >The default "simple" firewall rules for ipfw in FreeBSD specify that >packets destined for the 127.0.0.0/8 network not coming from the lo0 >device will be dropped. Debian GNU/Linux installations nowadays will attempt to set up spoof protection, with similar

announcement: Hacker's conference "HAL 2001"

2001-03-06 Thread Gerrit Hiddink
Press Release Enschede, The Netherlands March 5th, 2001 Hackers At Large 2001: debating the future of the Internet. >From August 9th until August 12th, the campus of the University of Twente will feature a congress that is unique in its kind: Hackers at Large, or HAL 2001. The congress expects

Re: [GSA2001-01] PHP IMAP overflow fix problems

2001-03-06 Thread Anil Madhavapeddy
Quoting pre <[EMAIL PROTECTED]>: > > This issue appears to be fixed in the current CVS version of PHP (I > haven't tested it, just looked at the code). > > The gsa2001-01.diff patch against php-4.0.4pl1 reverts the imap module > to 4.0.3 behavior, without reintroducing the buffer overflow. > Att

Re: Loopback and multi-homed routing flaw in TCP/IP stack.

2001-03-06 Thread Ben Laurie
Neil W Rickert wrote: > > Woody <[EMAIL PROTECTED]> wrote: > > >We believe there to be a serious security flaw in the TCP/IP stack of > >several Unix-like operating systems. Whilst being "known" behavior on > >technical mailing lists, we feel that the implications of this > >"feature" are unexpect

Re: Loopback and multi-homed routing flaw in TCP/IP stack.

2001-03-06 Thread Lothar Beta
Greetinks, On Mon, Mar 05, 2001 at 07:44:43PM +, Woody wrote: > Subject: Loopback and multi-homed routing flaw in TCP/IP stack. > Author: Woody <[EMAIL PROTECTED]> [snip] > must be configured, using a firewall, to drop IP packets arriving from > the wrong network in order to be secure. This

Re: Loopback and multi-homed routing flaw in TCP/IP stack.

2001-03-06 Thread Ben Laurie
Perry Harrington wrote: > > I don't think the behavior should change because of DSR. DSR is more useful > than 'rightness' in my opinion. A switch to turn it off if you don't want it is > something I'd advocate, but the default should be 'on'. The FreeBSD guys are making the behaviour switchabl