TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to
[EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any problems!
----------------------------------------------------------------------------
All!
This is kind of long. My appologies. I just want to try to
update everyone on a list problem I've been investigating so that the
ones who were suffering from it know what happened and why. I also want
to make sure people bring problems like this to my attention ASAP.
This probably went on longer than it should have.
It came to my attention that a small percentage of list
subscribers (several dozen out of the several thousand subscribers on
this list) have been receiving duplicates of one particular recent
message about "Internet Scanner: Estimating time required to complete
a scan" dated April 27.
For everybody:
Please!
When experiencing problems with message deliveries such as
duplicate messages, please forward copies of the dupicates to me,
preferrably to [EMAIL PROTECTED] I need message headers
including "Received:", "Message-Id:", and "Delivered-To:" in order to
track down most problems (I got extremely lucky, this time). The
message headers are the audit trail which tells me how a message was
processed. They are not normally displayed with a message by there
is, normally, a way to display them and forward them, even with Windows
based E-Mail clients.
I personally maintain three accounts subscribed to this list to
monitor the traffic and detect problems. Often, if you report a problem
like this to me, I will have the data in one of those accounts as well.
That was not the case, this time. None of my monitoring accounts were
experiencing this problem.
For the people experiencing the recent duplicates:
I've analyzed this problem and stumbled over something "amusing".
It's amusing from my point of view (largely because I'm an OLD FART with
first hand experience with this particular problem). I'm sure it's not
so amusing from the point of view of those suffering from the problem.
What I stumbled onto is an old OLD problem. I'm sure that it could be
even LESS amusing if someone were to take advantage of the problem and
mount a denial of service attack against vulnerable spots. Consequently,
I am not revealing any information about who may or may not be having
this problem. I'm only going to detail out what the problem is.
The problem turns out to be an old modem problem called "TIES"
or "Time Independent Escape Sequence". One poster posted a message that
included a line in his signature that began with three plus signs
and ended with three plus signs. Three plus signs (optionally bracketed
with a return) is the default escape sequence to cause TIES based modems
to escape into command mode. This would eventually cause the network
connection to break. Because it was at the very end of the message,
apparently some mail systems were delivering the message anyways.
Our system began reporting this error:
"status=deferred (conversation with ************ timed out while
sending end of data -- message may be sent more than once"
So a message with three pluses on the very last line of the message
was apparently causing some modem along the way to the recipients mail
server to jump into command mode and time out the connection. Our system
deferred the delivery for later while the recepients system obligingly
delivered it.
The offending message has been removed from the mail queue and the
original poster was informed about what triggered the problem. That
eliminates the current round of duplicates but does not solve the problem
(the vulnerable modems out there). But, of course, there should be nothing
wrong with what he posted and nothing is stopping anyone else from
posting something similar (please don't). The real problem still exists
for several dozen people, that there may be an AT-style TIES modem device
in their network path that may be vulnerable to "TIES Bombing".
A little history:
TIES was an effort by a number of modem manufacturers to avoid the
Hayes / Haywood (maybe it was Hayward - I never remember quite right from
THAT long ago) patent on the <delay>+ + +<delay> escape to command mode
for AT command set modems. The key to the patent was the <delay>. TIES
manufacturers eliminated the delay and, thus, did NOT have to pay royalties
on the patent. It also mean that, given the right conditions, their
modems would jump into command mode when receiving a simple "+ + +" in
the data stream. For some manufacturers, it was a "\r+ + +" while some
required a "+ + +\r", the message in question hit both.
(Note: I'm spacing out the pluses just to be sure I don't trip
over some REALLY lame TIES modem. :-) )
During the TIES wars, many years ago, some Hayes employees were
known to include "+ + +ATH0" on a separate line (providing both leading and
trailing newlines) in all of their USENET mail postings and E-Mail messages.
Needless to say, this caused widespread random mayhem and didn't enhance
the reputation of either Hayes nor the modem manufactures one bit.
Now... Here is why I'm subjecting everyone to this little
history lession...
I recently (about 6 months ago) had an incident with some chumps
"TIES bombing" an entire ISP. They were flood pinging his netblock with
ICMP echo packets containing "\r+ + +ATH0\r" in the payload. What would
happen was that, when a customer would connect in and get an IP address,
the first ping would cause the ISP's (the outbound) modem to jump into
command mode and then hang up the phone (they could create even MORE
mayhem by issuing dial commands in the payload - think about it). The
ISP was at a total loss trying to figure out why all his PPP dialins
where hanging up within seconds of connecting till I suggested looking at
this old problem. That was it. All of their banks of modems were TIES
modems. They had to set the escape character to 255 or 127 to disable the
escape. But that only fixed SOME of the connections. Some customers were
still broken! The answer was simple! The echo packet was getting through
and being echoed back. Then the customer's modem (transmitting back to the
ISP) would see the + + +ATH0 and jump into command mode and hang up the
phone. Both ends of the link had to be fixed to prevent TIES bombing.
Even some high speed devices, such as ISDN modems, may be
vulnerable to this problem.
Everyone who was experiencing the duplicate message problem may
be vulnerable to exactly this style of TIES bombing! This can turn into
a real annoying denial of service attack that is real difficult to track
down and trouble shoot. I can not tell from here, where the faulty
modems are. They are out there, though.
If you can identify the modems (they may be yours, the ISP you
connect to, or some other link) here are some recommendations to
implement or pass along...
Disable the TIES escape recognition by setting the TIES escape
character (S2 register) to the "disabled" value (127 for most modems,
255 for some modems). This value can then be written out to the NVRAM
of the modem.
To guard against modems being reset back to the factory defaults
(which would include setting S2=43, the '+' character) any software which
manipulates the modem at the "AT" command level should also included the
string "S2=127" or "S2=255", as appropriate for the modem, in the
initialization sequence. This should be done for dial in initialization
as well as dial out initialization.
The Time Independent Escape Sequence (TIES) was developed as a way
around patents held by Hayes Microcomputer Products back in the days when
dominant connections were interactive and little binary data was being
passed over the modems.
TIES is a old technology which is intrinsicly incompatible with
modern IP connected links with binary data, compressed data, or encryted
data. It's subject to a variety of failures due to hostile action or
just plain bad luck. All TIES modems, at both ends of IP dial-in connections
need to have the TIES sequence disabled. Unfortunately, too many modern
modems still support and operate with TIES.
Sorry for the problem that some of you have been experiencing and
sorry for inflicting this little off-topic history lesson on everyone.
Back to your regularly scheduled programming... :-)
Regards,
Mike
ISS Forum Moderator
--
Michael H. Warfield, | Voice: (404)236-2807
Senior Researcher - X-Force | Main: (404)236-2600
Internet Security Systems, Inc. | E-Mail: [EMAIL PROTECTED] [EMAIL PROTECTED]
6303 Barfield Road | http://www.iss.net/
Atlanta, Georgia 30328 | http://www.wittsend.com/mhw/
| PGP Key: 0xDF1DD471
