This does not `freeze' the system per se. What it does is tie up all
the network resources, and make it impossible to any network I/O (even
through Un*x-domain sockets).
Linux is not generally vulnerable to the exploit as posted, because it
seems to only accept 64512 bytes from the write(2)s,
You can do a variation on this one (well sort opf - is a logstanding prob)
basically find two sites whose FW is conf'd to accept all mail and forward
it to the real mailserver. If this mailserver bounces invalid addresses
then you're on your way...
spoof a mail from an invalid address on one
Jordan Ritter wrote:
On Mon, 30 Aug 1999, Nic Bellamy wrote:
tracked this problem to an sprintf() into a buffer on the stack
in the log_xfer() routine in src/log.c. Gotta love it. Sigh.
What's interesting to note is that I notified the contact at ProFTPd of
this exact overflow
On Tue, 31 Aug 1999, "CC" = Crispin Cowan wrote:
+ So, why would one use the approach of saving the return address on
+ another stack, instead of patching the stack itself, like StackGuard?
+ The only reason I can imagine, is that one does not want to change the
+ stack layout. The
This would seem to protect against precisely the same class of attacks
as StackGuard: those that use buffer overflows to corrupt the return
address in an activation record. The response to attack is subtly
differet:
* StackGuard: assumes the program is hopelessly corrupted, syslog's
Hello to everyone.
Date: 09-01-1999 (By NtWaK0)
---
Bug Title:
LSA and LSA3 HotFix Malformed Request Causes LSA Service Hang
"CAPI: The install program could not open signature file"
