[Date Prev][Date Next][Thread Prev][Thread Next] [Search] [Date Index] [Thread Index]

Re: [MacPerl] taint checks and CGI.pm



At 19:55 +0100 12/28/97, Karsten Meier wrote:
>UNIX and MacOS are different, so UNIX security flaw may not
>be present in the MacOS.
>But I see the following problem: If I'm on an appletalk network,
>and I have a public visible folder, someone can upload a MacPerl
>executable together with a special modified version
>of a Module like cgi.pm. If I now open my script with doubleclicking,
>the new version of MacPerl may start, because the Finder
>starts the newest version of anything, and uses the bad module.

If a document is opened, the newest version of the needed app *found on the
same volume as the document* is used.  It's much more complex if no copies
of the app are on the same volume, but it boils down to "newest, sort of,
except when it isn't".  I don't think any of this really helps in plugging
the hole...but it might lead one to think the hole isn't there when it is.

Let's see:  on the volume with the folder which can be stored into by the
public, put a small app with the MacPerl signature which isn't MacPerl and
complains about an invalid attempt to run MacPerl.  Give this little app
the modification date of the Mac clock End of Time (2/6/2040;
6:28:15)...it's now the newest on the volume with the upload folder.

Run the real MacPerl on some other volume (giving it the above date might
or might not help:  I'm not sure), and don't allow opening Perl scripts on
the volume with the upload folder (the public upload folder needs to be
write only).  I think there are still holes.

Note that eventually that 2/6/2040; 6:28:15 will cease to be the Mac End of
Time (for applications using the long date routines released at or before
System 7 time in 1991, including Finder and the Process Manager), with the
toolbox changing how the physical clock--which recycles to 0 the second
after that date--is loading into the long date (signed 64 bits).  One year
that might happen is--if memory serves--2015, which is known to be special:
it's the year <if I'm remembering the right one> that a year of "95" ceases
to mean 1995 and begins to mean 2095 when the date parsing routines are at
work.  [Similarly, the interpretation of "04" changes from 1904 to 2004 as
the clock crosses some date around 1990.]

  --John

--
John Baxter (Born before ENIAC, but not by much.)
   jwblist@olympus.net      Port Ludlow, WA, USA



***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch