Claimed Security Issues in Vaporware Applications
===============================-21.Nov.2001-=====

Recently, claims have been made that all MUI applications are vulnerable
to remote exploits due to a "MUI security flaw".

This statement is a gross oversimplifications of matters, and it also
puts the blame on the wrong end -- blaming the Messenger for the
Message -- so to speak. However, the impliciations are not completely
unwarranted, so I think I should try to explain why such a security hole
could possibly exist in AmigaOS applications (although not in Vaporware
apps, as I will describe later on).

There are two things playing together here:

a) APIPE: is a device which allows to start a program and read from
or write to its standard input/output stream. Unix literates will
be familiar with this, it's similiar to the popen() call as
defined by POSIX. It basically works like this:

 BPTR fh = Open( "APIPE:dir", MODE_OLDFILE )

and then the APIPE: device executes the "dir" command and allows
reading it's output from "fh".

AmiTCP, for example, shipped with such a device handler; the reasoning
being is that several of the AmiTCP tools and services were ports
of existing Unix programs, and thus needed popen()-functionality. Also,
AmiTCP's inetd "simple" mode relies on this handler.

The imminent danger in implementing this as a DOS device handler, however,
is that everything needed to execute a program on the machine is
the ability to cause an application to Open a file with
a specific filename. This becomes dangerous when the filename (or parts of it)
are taken from data received from the network.

Possible examples where this vulnerability COULD exist:

 1. an IRC client receives a DCC request. It takes the filename, and
    does a Open() on it to tell the user whether the file already 
    exists, to possible show a "Resume"-kind of dialog

 2. a web browser receives a file via a redirected download link, and does
    the same to provide a "Resume" dialog

 3. a web browser parses <IMG SRC> tag with a file:/// URL which has an
    APIPE: call included

 4. a web browser parses <SCRIPT SRC> or <EMBED SRC> tag...

etc.

The obvious "fix" to this problem is, as an application, to be very very
careful when doing such seemingly innocent operations involving file names,
and check whether an attempt is made to open APIPE:.

There are other possible solutions to this:

-- it's possible to scan the actual DOS device list whether the device name
in question is in fact a filehandler or a just a "device"

-- it's possible to "emulate" above check by doing a Lock() first,
in the hope that all APIPE: versions refuse to reply to a ACTION_LOCATE_OBJECT
packet

-- another "emulation" of this check is to do a Lock() and then a
a OpenFromLock() on this Lock (this requires support for a packet which
is known to not be implemented in several network filesystems, though;
and it's reported to not work with UAE)

Those solutions also reach the goal. They have the disadvantage, however,
of crippling functionality a bit, because not EVERY device handler is "evil"
-- it's really just APIPE:. There is nothing bad in reading HTML from,
let's say SER:, or a handler which implements a completely different
network protocol (say, SCP:), and doing any of the "device handler"
checks would prohibit this.

There is also a potential disadvantage to the pure name check -- it
IS possible to mount APIPE: with a different name, and thus circumvent
the name check protection. Practially this is, however, irrelevant; for
an attacker to make use of this, he needs a backdoor into the machine
in the first place (to mount the APIPE handler under a different name),
at which point any protection in the applications becomes useless.

Vaporware applications have done the aforementioned name check (in addition
to stripping device name & path components when they are not required)
for several years.

There is a pipe handler similiar to APIPE: called AWNPIPE:, to
which all the above also applies.


b) MUI has a very very powerful text output engine, which allows nearly
any object which uses it (buttons, texts, lists etc.) to use formatting
codes to change styles, alignment and even embed images into "text".

This is implemented by means of escape codes, which are documented
in MUI_Text.doc in the MUI developer documentation.

The embedding of images is implemented in MUI by means of datatypes;
the escape code in question allows one to specify a filename, and
MUI passes this filename down to datatypes.library in order to instantiate
an datatype image object.

And here lies the danger: Since datatypes.library will do an Open() on
the given filename, it is possible to feed an "image escape code"
with a file name including APIPE: to datatypes library by means of
MUI escape codes.

So far, so good -- the problem here lies in a fault that many Internet-related
MUI applications do: They take some network data, say, the Subject: line
of a mail message, and pass this to a MUI object, say, a list. Voila, there
goes the security hole (several mail readers are known to be subject
to this)

Other possible locations where this could happen: An IRC client showing network
received text in a listview object, a web browser showing an <A HREF> specified 
URL in a text gadget in it's status line etc.

The obvious "fix" to this problem for applications is to not feed such network
data to MUI objects without checking and stripping ALL escape codes, OR 
prepend it with the (also documented) escape code which disables 
interpretation of further escape codes.

All Vaporware applications have done this stripping/disabling of escape codes for years.


Blaming this combination of problems on MUI is, obviously, wrong.
At fault are application programmers which pass untrustworthy data (i.e.,
something received by the network) to functions without considering the
implications. With the same reasoning it would be possibly to blame
the fact that an application passes a network-received filename to
dos.library's Open() function (as described in a)) as a security
on dos.library. The way how MUI's text engine works has been described in
the aforementioned MUI_Text.doc file since the very first versions of
MUI.

The above implications are, incidentally, nothing new. Several years ago,
the "finger" daemon shipped with early versions of AmiTCP had exactly
the issue described in a) by feeding the "username" received via APIPE:
to the actual "finger" program on the machine -- by means of fabricating
a username containing backticks, it was possible to remotely execute
code on the machine in question.


I, again, point out that to the best of my knowledge, none of the Vaporware
applications are vulnerable to any exploit based on the two mechanisms described
above, because the aforementioned precautions are taken. I welcome anyone
who is claiming different to backup his claim by producing an working exploit
for such a security issue.


Olli