Carolyn P. Meinel Hall of Shame
Technical Wonder: TCP/IP For Dummies
[This is probably one of the most amusing threads. The following is
mail from Route (route@infonexus.com) in reply to Carolyn Meinel's
various posts about TCP/IP, SYN floods, network latency, packet
sizes, and more. Material after | is from Carolyn, indented
text is the followup from Route, and my own comments in brackets.
Oh, forgot to mention, Route is a highly respected consultant in
the Information Security field, editor of Phrack magazine, etc.]
---------- Forwarded message ----------
Message-ID: <19961115051936.13262.qmail@onyx.infonexus.com>
Date: Thu, 14 Nov 1996 21:19:36 -0800 (PST)
From: route@onyx.infonexus.com
Cc: jericho@lemming.com,
Subject: Re: ethics (long)
| And about how far the self-described hacker world has
| moved from its roots. Daemon9 implyed, in email to me that because he had
| left two lines out of his exploit, that only elite hackers could run his
| syn flood attacks.
No, you lackwit, I told you STRAIGHT OUT that the code was:
1) Disabled. It has the sendto() call commented out.
2) Crippled. It is a weakened version of the real program.
3) Required a hacked raw sockets interface to run.
Your previous statement shows your technical ineptitude, and obvious
lack of common sense. Futhermore, I *never* said 'only elite hackers could
run {my} syn flood attacks'. I would never say something so pompous and lame
sounding. What I told you is the code required a modicum of sophistication
in order to work. Considering the fact you mailed me to ask questions that
are *answered in the whitepaper*, I greatly doubt you are at this level of
sophistication (or anywhere near it-- see below).
Let us not forget the reason you emailed me. In fact, let's look
over some of your mail to me now (numbers added for discussion below):
----Included Text----------------------------------------------------------
>From cmeinel@swcp.com Sun Nov 10 16:00:49 1996
Return-Path:
Delivered-To: route@onyx.infonexus.com
Received: (qmail-queue invoked from smtpd); 10 Nov 1996 16:00:48 -0000
Received: from slug.swcp.com (198.59.115.24)
by onyx.infonexus.com with SMTP; 10 Nov 1996 16:00:48 -0000
Received: (from cmeinel@localhost) by slug.swcp.com (8.6.9/8.6.9) id JAA03976; Sun, 10 Nov 1996 09:02:20
-0700
Date: Sun, 10 Nov 1996 09:02:18 -0700 (MST)
From: Carolyn Meinel
X-Sender: cmeinel@slug.swcp.com
To: route@onyx.infonexus.com
Subject: Re: syn stuff
In-Reply-To: <19961110091338.11313.qmail@onyx.infonexus.com>
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: RO
1) Thank you for your highly informative reply.
2) I'm keeping the other syn attack under my hat for now. But once you know
what it is, it is breathtakingly obvious.
3) Aleph One knows what it is, too.
4) I trust, given that you only released crippled code, that if you figure
out the attack I mention, you would be kind enough not to publicize even
crippled exploit code. You made your point with the Sept. episodes. I
hope Winn and I can use that to get action on the much larger problem I
so gingerly allude to, using syn flood as the lesson to be learned.
5) I expect to meet you at the Jan. seminar in the Bay area that Villella is
organizing.
----Included Text----------------------------------------------------------
1: Well, you seem polite there. Wonder what happened... Oh! Maybe it's
the fact you just wanted to leech some information off of me to make yourself
seem smart. Odd how it didn't work.
2: The 'other syn attack'. Again it is painfully apparent you have no
idea what the hell you are talking about.
3: We ALL do. It is the *widely* publicized "large packet" attack. It
has nothing to do with the TCP SYN header control bit. It exploits a flaw
in the fragmentation reassembly code in many network stacks. A large packet
is sent from one machine, fragmented for transmission on the physical interface,
and when the packet reassembled at the target, it overflows a kernel buffer
causing a vareity of problems...
4: I hate to be redundant, but AGAIN we see ignorance peeking it's ugly
head. Exploit code is not only available in Windows 95 and Windows NT, but
a *nix based program by Darren Reed also exists.
5: Believe me, Carolyn, I look forward to that meeting.
| Meanwhile, his claim that it took a great deal of knowledge to fix his
| code doesn't hold water. It was only missing two simple write to socket
| statements.
No, you silly little woman, NO. Next time I send you mail, perhaps
you should read it. IT WAS MISSING NO CODE. One sendto() call was commented
out. I have no clue how you came to such an absurd conclusion... Unless it
could be the fact that you are just plain DUMB.
| I wish daemon9 had tried that ploy of embarrassing his readers out of
| actually using syn flood when he released his exploit. It also would have
| been decent of him to alert CERT, CIAC, Bugtraq, etc. first and give them
| time to come up with patches.
Lady, the hole has been known about for over a deacade now. And
how daft would releasing a fully functional attack program, and then
telling people:
"You're a fool if you run this. People will laugh at you and
make fun of you...".
People like you might be disuaded, but doubtfully anyone else.
[Bugtraq is a public list. Releasing it in Bugtraq and Phrack have
the same results... over ten thousand people reading it.]
| I'm writing some articles on computer security and also collecting hacker
| stories for a book proposal. If you wish to share stories, transcripts of
| shell log files, email exchanges, etc., I would really appreciate them.
Translation:
I'm stealing some articles on computer security and also swiping hacker
stories to make myself some money. If you wish to sponsor me by giving me
some information that I couldn't possibly come up with on my own, I would
really appreciate it.
| Thank you for your time.
When several friends of mine told me about you, I chose to decide
for myself what kind of person you were. This post of yours showed me
clearly.
Congratulations. You have antagonized another person.
=-= [From the next round of mail...] =-=
Date: Sat, 16 Nov 1996 13:25:36 -0800 (PST)
From: route@onyx.infonexus.com
To: Carolyn Meinel
Cc: jericho@lemming.com,
Subject: Re: ethics (long) (fwd)
| Here's a quick technical note on those giant 65K datagrams to which
| Sorder alludes on that ping stuff.
There is nothing wrong with a 65k IP datagram. The field
in the IP header responsible for total datagram length is 16-bits. This
is to say that legal datagram sizes range from 20-65,515 bytes (inclusive
of the 20-byte IP header-- exclusive of options). Problems arise when
a datagram is created that would violate this 65K limit.
| (Newbie note: A datagram is the stuff inside a packet, and a packet is how
| information is packaged on, for example, the Internet and Ethernet. Ping
| is a command used to troubleshoot networks.)
You are wrong. A datagram is an IP packet (actually, a datagram
is any connectionless network-layer packet medium). Transport layer packets
are grouped into segments as they have no record boundrys, and link-layer
packets are refered to as frames (groups of bits from the physical-layer
are logically grouped into frames at the link-layer). So, Ethernet, which
is a Link-layer protocol, groups its data into frames.
Ping is used for many things besides troubleshooting... From my
paper on ICMP tunneling:
"...
Ping traffic is ubiquitous to almost every TCP/IP based network and
subnetwork. It has a standard packet format recognized by every IP-speaking
router and is used universally for network management, testing, and
measurement.
..."
| These big datagrams are what put the "killer" in that "killer ping" Sorder
| says I am so hypocritical to write about. They fragment on their way
| through routers.
|
| (Newbie note: routers tell computers on the Internet what are good ways to
| send your packets on to their final destinations.)
|
| Fragmented=harmless. But there are reports that sometimes they get
| reassembled at the other end. Now figuring out the conditions that may
Sometimes? It would appear you do not understand IP fragmentation
/reassembly? If a packet is fragmented, it WILL be reassembled at the other
end. However, If any problem is encountered in transit, (lost packet/bad
checksum/memory leaks) the whole fragment list is dropped.
| cause them to get reassembled, and patching the systems that do this --
What causes them to be reassembled? Under Net/3 code, that would
be the ip_reass() function. Briefly:
ipintr() is called whenever a datagram arrives at the IP layer. If
the datagram is found to be a fragment, it is added to the doublely linked
list of fragments. ip_reass() is then called in an attempt to reassemble
the full datagram. [Much detail is ommited]
| that is elite.
^^^^^^
NO IT'S NOT. Elite is *not* reassembling a fragmented IP datagram.
"...You keep using that word. I do not think it means, what you think it
means."
Also, it makes me quesy when you use that word.
| Not syn flooding down the Panix ISP. Not providing syn flood code to the
| masses without exercising any moral authority to dissuade its misuse.
|
| (Newbie note: syn flood means sending lots of messages saying, "Yo, victim
| computer, I want to talk with you." So victim computer sends back an
| "ack," which means, "OK, you want to talk, let's shake hands first." Now a
| normal computer would send back an ack - acknowledgment - which is the
| handshake. But the syn flood computer has been programmed to withhold its
| ack. So victim computer is sitting there thinking, "Gee, what's taking so
| long. Must be network problems. I'll be patient and wait some more."
| Meanwhile the syn flood computer keeps on sending out these syns without
| acks, over 100 per second, until victim computer is standing there in the
| dark with thousands of hands held out waiting for the handshakes that
| never come. When victim runs out of hands, no one else can talk to it.)
This is again not correct. (I need to break out the 'ole thesaurus
to find new words that mean 'wrong', 'incorrect', 'you are in error', etc
Eh, Carolyn?)
I direct curious people to read my verbose paper on the subject.
It is available all over the Internet in Phrack 48...
http://www.fc.net/phrack/files/p48/p48-13.html
| If you want to know why the syn flood vulnerability hasn't been fixed
| everywhere, this is not all a matter of laziness. There is a considerable
| amount of latency built into the Internet.
|
| (Newbie note: "Latency" means information
| does not travel as fast as physically possible, but may be stored briefly,
| or even for longer periods, during its travels.)
What? Dear god woman, NO. Latency, as pertaining to computer
networks, refers to the length of time it takes a bit of information to
travel from one end to the other. It is ultimatly limited by the speed
of light, and is more of an issue at giga-bit speeds.
| One of the casualties of the syn flood attacks was that the fix requires
| cutting off a connection if a returning ack to the syn doesn't come soon.
| This fix made it so distant hosts were often unable to communicate. True,
| fine tuning the wait time has improved things. But I would hate to see an
| Internet that excludes communication between distant hosts.
Here's a task for you Carolyn: Go and research how many other TCP
SYN-flood patches exist. Notice how they do not have that problem.
| It's the same moral issue with breaking into ISPs. Code exists on the
| hacker scene to break into and trash any ISP. This is not entirely because
| ISPs may be lazy about security. It is mostly because if they were to use
| all the security techniques available, you would find it almost impossible
| to use your ISP. So whose responsibility is it to allow us to continue to
Wrong. In 90% of the cases, security holes exist simply because
people are not concerned with security.
| Carolyn Meinel
| M/B Research -- The Technology Brokers
Here's some free advice:
Stick to something you know. Whatever it is, it's not computer
security. You are making an ASS out of yourself.