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-
- --
-BEGIN PGP SIGNED MESSAGE-
-
Debian Security Advisory DSA-032-1 [EMAIL PROTECTED]
http://www.debian.org/security/ Wichert Akkerman
March 7, 2001
- --
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
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
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
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
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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Linux-Mandrake Security Update Advisory
Package name: joe
Date:
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
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
> > >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 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
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
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
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
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
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
> 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
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
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
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
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
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
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
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
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
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
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
29 matches
Mail list logo