Attacks using Pure Text (Was: Re: Results, not Resolutions)

Bill Stewart bill.stewart at pobox.com
Mon Jan 28 01:45:22 EST 2002


At 10:17 PM 01/26/2002 -0800, Bill Frantz wrote:
>At 7:42 PM -0800 1/25/02, R. A. Hettinga quoted Schneier and Shostack:
> >Here's one example: Originally, e-mail was text only, and e-mail viruses
> >were impossible. ...
>
>Well, the line between code and data is fuzzier than that.  That 7 bit
>ASCII email is properly thought of as a series of instructions for a text
>rendering engine which is implemented in software on modern machines.  If
>there is a bug in that rendering software, then it may be possible to
>design a sequence of text which executes arbitrary code on the receiving 
>machine.

Email viruses were not impossible with text-only email.
ASCII text is probably much safer today than it was 20 years ago,
because there are far more systems that try to render it,
and almost all of them do less interpretation than they did back then,
when we usually read email on "dumb terminals", preferably the
smartest dumb terminals we could find.  Before everything standardized on ANSI,
lots of terminals, particularly the HP 262x series and the DEC VT100s,
had features that would let you hand escape sequences to the terminal
that would not only change fonts, move the cursor, clear the screen, etc.,
but could also program function keys and execute function keys.
So it was possible to send somebody email that would cause their terminal
to transmit a limited number of characters to the computer as if the
user had typed them, which opened a variety of security holes.
Also, one of the "talk" programs would write directly to another user's
terminal if the permissions were set to the default world-writable.

There was an article in the SF Chron or Oakland Trib in spring 1979
saying that "hackers at Berkeley" had broken the security of
"the Unix, a computer made by DEC", which was really about one of these
escape-sequence exploits, probably for VT100s.  It was tough to do much,
but if you guessed what mail reader the person was using,
you could fake keystrokes for "exit mail, run something dangerous",
especially if you first sent the victim a file using UUCP.
I don't think anybody built a virus this way, since we weren't
really virus-aware at the time, but some people probably sent
password-stealers this way.

And it was easy to do a "shut down or hose up the victim's terminal" attack.
Unfortunately, the escape sequence for bold-face on one popular terminal
would hose up another popular terminal, so it wasn't always deliberate -
there were often flames on Usenet about people posting formatted articles
(commonly recipes on rec.cooking) with dangerous escape sequences in them.

A much cruder denial-of-service attack was to send +++ or other
modem-control characters, which could disconnect a Hayes-style modem.

These days, almost all of the terminal emulation programs
either just run totally dumb text, or run some subset implementation
of ANSI or the very similar DEC VT100, and most of those emulators
haven't bothered implementing the fancier features.

Another text-only attack was magic sequences for text editors like vi
(and perhaps emacs?) which would look for option-setting commands
in the beginning or end lines of files.  The purpose was to allow
comments in C code that would turn on C-related editor options,
comments in Lisp code that would turn on lisp-related options, etc.
This was eventually realized to be a security risk, so
"nomodelines" became the default in vi.

Of course, the most successful text-only attack was the "Good Times" virus,
which worked by infecting the wetware of the operator :-)

>There is really no substitute for limiting the authority of code which
>processes potentially hostile input, such as email and web pages, so that
>the consequences of flaws are limited.  One way to limit authority in
>current systems is to use an operating system that provides a measure of
>real security between users, and then have an account which is only used
>for email, web surfing etc.

Yup.  Designing code for hostile and bogus input was about the
third lesson in CS100, after "Comment everything" and "The One True Indent 
Style",
and well before anything fancier than arrays and loops.
But enough code doesn't do that that it's important to use
operating system protections as well.







---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com




More information about the cryptography mailing list