This is thrown together partially from the original sources of stream, and
partially from my own ramblings, it was a quick and dirty hack, so there
are parts of it that are messy. For testing purposes on a lan, if you
want to verify packet headers, and not send as fast as it can, you can
define SLOW.
This version has the fixed tcp cksum, and a MSS window of compile-time
definable size.
--- stream2.c ---
#include <stdio.h>
#include <time.h>
#include <stdlib.h>
#include <unistd.h>
#include <strings.h>
#include <sys/time.h>
#include <sys/param.h>
#include <sys/types.h>
#include <sys/socket.h>
#ifndef __USE_BSD
#define __USE_BSD
#endif
#ifndef __FAVOR_BSD
#define __FAVOR_BSD
#endif
#include <netinet/in_systm.h>
#include <netinet/in.h>
#include <netinet/ip.h>
#include <netinet/tcp.h>
#include <arpa/inet.h>
#include <netdb.h>
/*
* QUIET controls whether to print out errors (can be very noisy, if this is
* undef'd, when buffers are full)
Excuse me susan. Dont read any further.
Jason:
Why must you - and other people - be so fucking stupid?
Why not release a technical explanation of a problem, or something
in a package, network stack, operating system or (*) - in a logical,
"Hey, here's a problem, I think we should figure out how to fix it" or
"Hey, here's a problem, and here's how I think it can be fixed" manner?
Are you twelve?
Do you think youre gonna get sucked off more now (or perhaps, more
accurately, sucked off period) now that the #chix-with-big-tits
IRC channel knows that you released something that's gonna be a pain in
engineers' asses all over the world?
You've gained no respect here.
Thank you for making available code that now _all_ the packet kids can
use. Releasing this doesn't prove any theories, expose something new,
or have any redeemable value whatsoever. The sound everyone hears is
a collective orgasm of 12-year-olds with linux machines everywhere.
... or maybe they just saw http://www.tch.org/~ser/wtf2.jpg recently.
Perhaps if people read the source, and compared it with the original, they
would notice that there are not many operational differences, aside from
the fact that this goes through the extra step of setting MSS, and
calculating the correct checksum. The fact that the _all_ the packet kids
can use this, doesn't unleash a deadly new tool, merely a slightly
modified one. There are no optimizations in this upon the original, nor
are there any real benefits. It was merely written to produce a syn
generator that created packets with correct checksums and MSS.
The further comment you made regarding the url merely demonstrates your
immaturity to deal with a situation when it arises.
Well, given that you've eliminated 2 useful attributes by which such
an attack could be identified and/or filtered, I'd say there is an
immediate benefit for the kiddies to make use of your version.
And as far as releasing the code, you could at least have broken it in
a couple of simple ways so that someone would have to have half a brain
to make it work.
-c
This is the type of behavior I was talking about when I coined the term
cyber-terrorism. Releasing such code for the use of others in public forum,
will harm the fabric of the network, is an overt act of terrorism in its final
result.
I hope when they the FBI catch up with you, they pipe sunlight and air
to you.
jamie rishaw wrote:
>
> This is thrown together partially from the original sources of stream, and
> partially from my own ramblings, it was a quick and dirty hack, so there
> are parts of it that are messy. For testing purposes on a lan, if you
> want to verify packet headers, and not send as fast as it can, you can
> define SLOW.
Thank you for making available code that now _all_ the packet kids can
use. Releasing this doesn't prove any theories, expose something new,
or have any redeemable value whatsoever. The sound everyone hears is
a collective orgasm of 12-year-olds with linux machines everywhere.
... or maybe they just saw http://www.tch.org/~ser/wtf2.jpg recently.
No reason to include that JPG!
-Hank
Guys, there is no way this group is going to resolve this huge difference
of opinion in the industry in this occurance of the thread, any more than
we did the last 53 times it occurred here, or the thousands of other
times it's been fought across the 'net.
The fact that it started out with the childish insults in the SECOND
email in the entire thread should be ample proof of that.
There is a huge segment of the industry that thinks publishing exploits is
a bad thing, which will result in people getting hurt. This segment
includes some of the best and brightest in our ranks, and they use
well-reasoned logical arguments to prove their case.
There is a huge segment of the industry that thinks that publishing
exploits is a good thing, which will result in problems that have lingered
for years getting fixed. This segment includes some of the best and
brightest in our ranks, and they use well-reasoned logical arguments to
prove their case.
So can we just shut the eff up about the whole argument and go on with
our lives, please? Go argue about this over in Bugtraq or something.
Agreed. Now my eyes have been given a denial of service. 
I think I have been damaged more by the JPG than the software that
prompted the posting.
-Paul
>
>... or maybe they just saw http://www.tch.org/~ser/wtf2.jpg recently.
No reason to include that JPG!
-Hank
>--
>Bill Fumerola <billf@FreeBSD.org>
By popular request my signature has moved to
<http://198.87.147.226/paulsig.txt>
Paul Timmins
paul@timmins.net
"By definition, if you don't stand up for anything, you stand for
nothing."
---Paul Timmins
