use PerlScript && die;

What is WSH \ PerlScript?

WSH (Windows Script Host) is a ``language-independent scripting host for ActiveX scripting engines'' [1]. It is integrated into Win98, WinMe and Win2K, and comes with VBScript and JScript (Microsoft's JavaScript implimentation)

The Windows Script host allows you to use multiple languages in one script file, run scripts from the command line, write windows components and make your HTML pages a bit more dynamic through ASP. In addition to the language-specific functions, WSH provides a number of objects, methods and properties that are always accessible regardless of which language you are using at the time.

Other software companies can write ActiveX scripting engine versions of their languages to be used within WSH. ActiveState has written PerlScript (a WSH version of Perl) which has been bundled with ActivePerl for some time. PerlScript offers almost the whole set of perl functionality. The only things that I've noticed missing or different is I/O - you can't ``print'' in PerlScript, you have to use the WSH methods for output ($Response->Write or $WScript->Echo). So, apart from ``print''ing PerlScript looks just like normal Perl. You can use Perl modules or if you want to make your code even less portable you can use some of the built-in WSH methods.

What are the security implications of this?

So far, the security implications aren't too great.

ASP runs on the remote server and is executed before the output is sent to your browser.

Command line WSH scripts and components run under your UID so as long as you know what you're executing and you don't run other people's scripts without checking them first, you should be ok.

However, one thing I haven't mentioned is that part of the WSH integration with Windows, is that it is built in to Internet Explorer too. If you are running IE 3 or higher (which you probably are if you have WSH installed) then you can run client-side scripts embedded in an HTML page. Now, there are reasons why this would be nice, but it makes me shiver to think about the consequences of running a language as powerful as Perl that is hidden in <script> tags.

Imagine the following pseudo-script hidden in an web page: (it could be MUCH worse than this)

<script language="PerlScript">
   use Win32;
   use Mail::Send;

   # get a list of files in $ENV{USERPROFILE} or $ENV{SystemRoot}
   # send me an email with files attached
   # Shutdown the machine
</script>
[download]

Thankfully in IE4 or above you can restrict clientside languages from running based on the Zone (local, Internet, trusted, etc). In IE3 it is either enabled or disabled for all zones. In fact, I don't think that the concept of zones existed in IE3.

The nitty-gritty - How bad could this be?

By default, ActiveState sets the PerlScript security setting to ``Local'' zones only. This means that if you open up an html file on your hard disk then it will allow Perlscript to run, but if you navigate IE to an external website, PerlScript will be silently ignored.

That's ok surely? NO! It's not ok. Imagine being sent an email with an attachment - it's a .html. It got through your virus scanners because they can't scan for malicious perl code and it looks just like a regular html page. It's stored locally on your hard disk before you open it in Outlook Express. You open it and BANG!

Disable PerlScript for your own safety

A lot of monks at the monastery dislike Javascript because of it's vulnerabilities and security risks. I think that PerlScript is a much more powerful language (in terms of functionality) so I recommend switching off PerlScript as well as disabling all client-side scripting in IE.

Error: Keyboard not attached. Press F1 to continue.

Comment on use PerlScript && die; Download Code

Replies are listed 'Best First'.
(tye)Re: use PerlScript && die; by tye (Sage) on Sep 04, 2001 at 22:38 UTC
Disabling PerlScript isn't as easy as it should be... until now. <html><head><title>PerlScript deactivator</title></head><body> <p>You probably don't have PerlScript installed.</p><p> <script language="PerlScript"> use strict; BEGIN { $^W= 1; } use vars qw( $window ); sub Output { $window->document->write( join "", @_ ); } my $Reg; use Win32::TieRegistry( TiedRef=>\$Reg, Delimiter=>"/", ArrayValues=>1, ":REG_" ); my $key= $Reg->{"LMachine/Software/ActiveState/"}; if( ! $key ) { Output "You don't have ActiveState software installed?? ($^E)"; } else { for my $prod ( $key->SubKeyNames() ) { Output "Found ActiveState/$prod/...<br>\n"; my $regProd= $key->{"$prod/"}; if( ! $regProd ) { Output "<p>Can't open ActiveState/$prod/: $^E</p>"; next; } for my $ver ( $regProd->SubKeyNames() ) { Output( ("&nbsp"x4)."Found version $ver...<br>\n" ); my $regVer= $regProd->{"$ver/"}; if( ! $regVer ) { Output "<p>Can't open ". "ActiveState/$prod/$ver/: $^E</p>"; next; } my $zones= $regVer->{"/EnabledZones"}; if( ! $zones ) { Output( ("&nbsp"x8)."Can't open ". ".../$ver//EnabledZones: $^E<br>" ); next; } Output( ("&nbsp"x8). "Enabled for zones: $zones->[0]<br>\n" ); if( $regVer->{"/EnabledZones"}= [ "0x0000", REG_DWORD ] ) { Output( ("&nbsp"x8)."Now disabled!<br>\n" ); } else { Output "<p>Can't disable ". "ActiveState/$prod/$ver: $^E</p>"; } } } } </script> <p>Done checking.</p> <!-- Typical output: You probably don't have PerlScript installed. Found ActiveState/ActivePerl/... Found version 616... Can't open .../616//EnabledZones: The system cannot find the f +ile specified Found ActiveState/PerlScript/... Found version 1.0... Enabled for zones: 0x00000000 Now disabled! Done checking. --> </body></html> [download] Simply hit the "d/l code" link below, save that to a file called something like "PerlScript.htm", verify your browser didn't mess it up too much, then view the saved file in IE and you should get an indication that PerlScript has been disabled. You can verify that it worked by reloading the page and seeing that only the first and last lines of text appear. - tye (but my friends call me "Tye")	[reply] [d/l]
(dws)Re: use PerlScript && die; by dws (Chancellor) on Sep 04, 2001 at 21:22 UTC
PerlScript's default security being set to "local" zones is ok surely? NO! It's not ok. Imagine being sent an email with an attachment - it's a .html. It got through your virus scanners because they can't scan for malicious perl code and it looks just like a regular html page. It's stored locally on your hard disk before you open it in Outlook Express. You open it and BANG! "Doctor, it hurts when I use Outlook Express!" Seriously, though, you raise a few good points. But as with many things in life, this is a trade-off. PerlScript enables wonderful things like ActiveState's Win32::OLE Type Library Browser. And, for those who're motivated to do so, it allows the browser to be used as a very limited UI platform. Trade this off against the probability of being attacked. Your average script-kiddie is unlikely to bother with a PerlScript-based attack, because percentages are so low. Unless they're targeting a Perl mailing list, the chance of getting hits based on a broadcast spam attack are pretty slim. I have PerlScript installed on my box at work. My work email address is generally unknown, and isn't on any mailing lists. I have no fear of attack there (except, perhaps, from my coworkers. But they phear me :-)	[reply]
Re: (dws)Re: use PerlScript && die; by $code or die (Deacon) on Sep 04, 2001 at 22:38 UTC
Yep, the Win32::OLE browser is nice. I compiled ActivePerl 629 source last week and it broke my OLE browser. I miss it and am contemplating re-installing from the MSI. Or I might just rewrite the OLE browser in Tk or Win32::GUI. If I do, I'll post it here. I also notice that the ActivePerl source doesn't have the other nice things like ppm or the html docs. But mine worked because I compiled it on top of build 628. I agree that the average script kiddie is unlikely to use PerlScript, but I think it's only a matter of time. It's just so easy to get into someone's system without them realising it. Error: Keyboard not attached. Press F1 to continue.	[reply]
Re: use PerlScript && die; by pmas (Hermit) on Sep 04, 2001 at 20:59 UTC
I read a lot about dangerous JavaScript and want to avoid it. However, I need to persuade my group, and they are not scared yet. Can you please suggest some links to nice scary "horror stories" about what can go wrong if JavaScript/PerlScript is enabled? Or some web site with this kind of info? Thanks! pmas To make errors is human. But to make million errors per second, you need a computer.	[reply]
Re(2): use PerlScript && die; by dmmiller2k (Chaplain) on Sep 10, 2001 at 17:36 UTC
For an example of Javascript that blew me away, see this. It is a Powerpoint 2000 presentation, simply saved "As a Web Page." The result was an html file named for the presentation, and a directory of files (.html, .js, .gif & .jpg), which *completely* implement the presentation using client-side (javascript) code! Perhaps it's because I rarely, if ever, need Powerpoint for anything, but I had no idea such sophistication was possible without server-side (i.e., Perl) support. This is a completely automated (read: accessible to the masses) feature. It scales the images dynamically to the available browser window size, supports on-screen controls for navigating the presentation, an outline frame and the ability to turn it off. The part that floored me was that simply by opening the root HTML file on my C: drive (repeat: no web server involvement!), the full presentation was available in my browser!. In IE 5 or better, you get a button (lower-right) that runs the slide show full screen. It puts to shame my own little concoction which I threw together for my sons' school in order to display the computer artwork produced by the class (see: Turtle Pictures, or Family Pictures). OK, so perhaps it doesn't write to the file system or do anything (apparently) malicious. But this is machine-generated canned code, untouched by programmers' hands (mine anyway). Until I saw this, I would have assumed that such a thing was only possible with CGI or its ilk (JSP, java servlets, ASP, or other server-side technologies). I shudder to think about the level of sophistication possible in skilled hands (read: spoofing unsuspecting users into providing otherwise-off-limits access to theirs files and machine). (In case you're wondering: Recently, a close friend passed away, well-loved and respected by a large group of family, friends and professional associates. A gala celebrating her life was held, at which a slide show ran showcasing pictures documenting her life. I became involved by volunteering to find a place to host it online.) dmm Just call me the Anti-Gates ...	[reply]
Re: use PerlScript && die; by John M. Dlugosz (Monsignor) on Sep 04, 2001 at 21:33 UTC
I've contemplated the idea of a command-line shell that used ActiveX scripting for it's "procs". I'd love to use Perl for that, but they can be mixed with basic, etc. Windows script Components offers a way to make a COM object in Perl. So I think Perlscript is wonderful. I'd be inclined to diable it for HTML pages, but have it around for files that are obviously meant to be programs. —John	[reply]
Re: Re: use PerlScript && die; by $code or die (Deacon) on Sep 04, 2001 at 22:32 UTC
I've contemplated the idea of a command-line shell that used ActiveX scripting for it's "procs". I'd love to use Perl for that, but they can be mixed with basic, etc. I have written Inline::WSH which allows you to use VBScript and JScript in your perl programs. It's a bit rough around the edges so I'm not going to publish it until it's a bit more robust. But then, I've also wondered whether anyone would be interested in such a beast! I wrote it mainly to have a play around with the Inline module. It's very nice, thanks Brian! Windows script Components offers a way to make a COM object in Perl. Absolutely! Its nice, flexible, cheaper and easier than PerlCtrl :) doesn't need compiling, etc. But it's not as portable. I do like Windows Script Components. So I think Perlscript is wonderful. I'd be inclined to diable it for HTML pages, but have it around for files that are obviously meant to be programs. I agree with you. PerlScript is nice, just not in a web browser. I might be wrong, but if you disable PerlScript by setting that registry key, I think it only disables it in IE. As I said, I might be wrong - I haven't tested it. Error: Keyboard not attached. Press F1 to continue.	[reply]
Re: Re: Re: use PerlScript && die; by John M. Dlugosz (Monsignor) on Sep 05, 2001 at 01:19 UTC
What is the portability difference between PerlCtrl and Perl in a WSC? They are both pretty much win32-only topics. Oh, you mean the way PerlCtrl can create a single EXE for running on a machine without Perl?	[reply]
Re: Re: Re: Re: use PerlScript && die; by $code or die (Deacon) on Sep 05, 2001 at 05:10 UTC
Re: Re: Re: Re: Re: use PerlScript && die; by John M. Dlugosz (Monsignor) on Sep 05, 2001 at 18:52 UTC
Re: use PerlScript && die; by Cine (Friar) on Sep 04, 2001 at 21:55 UTC
Its much more simple than that... Use Unix/Linux! T I M T O W T D I	[reply]
Re: Re: use PerlScript && die; by Rex(Wrecks) (Curate) on Sep 04, 2001 at 23:22 UTC
Hmmm, while I would agree that, when one has the choice, Unix/Linux would be my preferance. However, ignoring the HUGE install base that M$ has, and the fact that there are unfortunate souls like myself that are forced to use it, is in my opinion, limiting yourself. Not to mention that I quite like Win2K (with all the Unix tool ports installed). It's actually a nice OS and the best code MS has ever released. And while I appreciate the nature of your response, you must admit...it wasn't very helpful :) "Nothing is sure but death and taxes" I say combine the two and its death to all taxes!	[reply]


Perl Monk, Perl Meditation
	PerlMonks