Shoutbox

It's a waste of potential to limit any future PlusScript capabilities, when there are plenty of ways to ensure that you know what scripts you're installing and what's in them.  There may well be ways of getting through Plus if script-kiddies try hard enough, but then it's just like any other virus, and they're already around.  Maybe scripts could be disabled by default, so those who want scripts are the ones who open up that access on Plus. I also like the idea of a 'script manager' It's then at their discretion where they get the patch from.  You only really need to use the Plus site and mess.be to find most addons worth downoading anyway.
Whatever happens, patchou will make a way for it to work.  Once he does, Plus could well be a much more major piece of software, as other more minor apps could be encoded for Plus, so no need for installing lots of programs.  I can't say I'd be surprised - the only truly great messenger addon i've seen.
and finally

quote:

---

Originally posted by dRu18
if MessengerStarted then MsgBox "Patchou" " " "Is" " " "The" " " "Best" " " "!"

---

lol maybe not though i agree.  do strings really have to be spaced like that in vbscript??

quote:

---

Do strings really have to be spaced like that in vbscript?

---

No.

"Patchou Is The Best!" would be the correct sentence.

The VB compiler (or vbScript interpreter), unlike the C preprocessor won't take concatenated strings for granted and will reject them. You can always separate strings using the ";" semicolon punctuator.

Greetz

The problems are:
*Preventing that a script affects the user's own computer.
*Wether it does or not, preventing the infected computer from affects other net users, them (the other) having no viable way of stopping it.
*Preventing the antivirus companies from having to mention Messanger Plus! in their virus descriptions.

quote:

---

Originally posted by FoboldFKY
Anyway, as for the concerns about security, that's always a problem.  I mean, what was said about OnFileRecieve would be a huge problem... but I try to look at it like this: if someone really wanted to install a trojan on your system, they wouldn't even need to use Messenger.

---

I completely agree, but a worm or trojan can use Messenger w/Plus! scripting as a transport. Once it arrives, it might install itself.

I won't like a Kitro-variant worm that works like that. The worst about the Kitro worm was that it sent you 315KB messages to your Hotmail inbox, containing the virus. If I had 1MB used up in my Inbox, it only took 3 messages to fill it up, rejecting almost any other new message, particularly if it had an attachment. If my boss wished me to send a 300K spreadsheet he simply couldn't via e-mail. I use that account for both, work and home. It is no option for me to "get another account".

I'd like to emphasize that by saying that unexperienced users just open up attachments without taking care. Once their computers get infected, they won't notice it.

quote:

---

Personally, I believe a good solution would be to implement these OnFileRecieved events, but place options in Plus! to disable them being called.

---

I like the idea. What about if used together with:

quote:

---

However, in this system, no plugin can run itself in any way; the user must explicity enable each and every plugin weather it be one that runs and then terminates (eg: displays a dialog and quits) or runs in the background (listening for events).

---

... which translates to "I believe a good solution would be to implement these OnFileRecieved events, but place options in Plus! to disable them being called, having them disabled by default."

As in the security world is said: The safest configuration out-of-the-box.

quote:

---

Of course, the capability of a script to change the program's settings so it CAN run at any time is a problem...

My opinion is to go ahead with scripting.  A little trick to make sure that scripts can't be run directly would be to XOR them against a number, just so that they can ONLY be run via Plus.

---

You make a couple of good points here being the first the most dangerous, IMHO.

As far as I can think, the second one wouldn't be so much of a problem, because if Plus isn't loaded, the script won't run, and if it is, the script should (would?) behave the same way when run from Plus or from any other process. I'm thinking on a script having no coding limits. If it wants to access the hard disk, so be it, just don't allow it to use Plus! for turning it into a worm.

I think Patchou will have several opinions from both users point of view and technical issues. This will sure help him make a good decision when the time comes. I'm glad.

Octavio.

True, I agree to most of this, BUT there is one big problem. Young people tend to be ignorent when it comes down to accepting files from people they know. And as we all know, most ordinary users don't have a clue about virusses on their computer so when they send a file to their friends, those friends will most likely accept the file, because neither of them know the file in actuality could contain a virus.

I hope I made myself clear there.

Anyway, I still believe we should have some form of integrity check of each script being send even if the user doens't agree to open or execute it. And a certificate or key would be just fine.

Greetz

quote:

---

Originally posted by PlusFan

Ok then, here's something better: A 'test team'  People who know VBscript very well and have time left (read: have no life) they could then test scripts and put it in a database viewable from the website. AND: Plus says: This Add-on is approved by the add-on testing team. It is rated xx% Or: This script is not approved by the testing team. It is not secure to download it!! Or: This script was prooved to be NOT SECURE!! do NOT download it!!

gr8 Idea right?

---

Sorry for Quoting myself, but I think this really is the best solution

hi!!!

can u do it in english or in spanish instead of perl, vb script and js????


that would be great!!!!!


LOL LOL LOL

quote:

---

Originally posted by PlusFan

quote:

---

Originally posted by PlusFan

Ok then, here's something better: A 'test team'  People who know VBscript very well and have time left (read: have no life) they could then test scripts and put it in a database viewable from the website. AND: Plus says: This Add-on is approved by the add-on testing team. It is rated xx% Or: This script is not approved by the testing team. It is not secure to download it!! Or: This script was prooved to be NOT SECURE!! do NOT download it!!

gr8 Idea right?

---

Sorry for Quoting myself, but I think this really is the best solution

---

In an ideal world, all scripts would undergo this process... unfortunetly, finding enough people with time enough to trawl through the innumerable (as I'm sure this will be a very popular feature) scripts that pop up could be a problem...

But this whole idea of script security's got me interested... I might do some reasearch into digital certificates and how they work; see if I can't get a better perspective on all this.  I was just wondering how many people reading this thread are actually programmers?

Whatever it comes down to... maybe Plus! should simply disallow script files to be sent to other users... I mean, that would solve the self-replication problem pretty quickly... (you would, of course, need to set it up so that scripts couldn't simply copy themselves to another file and then send it... perhaps place read AND write locks on the file so it can't be read BY the script itself so it can replicate, then disallow anything in your Plus\Scripts directory to be sent...)

I've been doing some poking around, and I think I know how Patchou could implement digital 'signing' on the scripts.

Note: this is very long, and possibly quite boring.  Unless you find cryptography very exciting, I'd just skip to the bottom...

The first part would be to make an actual wrapper for the scripts.  This format could include things like what engine to use (JScript, VBScript, PerlScript, BobScript ), author details, script name, and actions.  You would also store any digital certificates here.

In regards to actions, for example, a single script file could contain a method to display a list of all contacts who had logged in recently, and a method to send a message to all open IM windows.  These could be run by having some way for the script file to define menus to insert into the interface (which is relatively easy).  This means people could release script 'packs' under one file with lots of different bits of functionality.   This is also where you would set up what events your script wants to handle.

Now, for digital certificates, the way I understand it currently is that you store the various bits of information (such as Script Name, Author, Checked By, Date Checked, Safety Level, etc.) in plain, unencrypted format.  Then, you calculate the certificate's digest (using MD5, or another similar hashing algorithm), and then encrypt that digest using a private key.  This private key would be unique to, say, the group validating the scripts.  They then publish their public key on the web for people to download.  BTW: all this encryption/decryption would need to be done by a private/public algorithm like RSA or PGP.

Now, the user downloads the script from the site, and Plus! tells the user that the script is digitally signed, but it doesn't know by who...  So, the user gets onto the Plus! site, and downloads the public key.  Plus! then calculates the certificate's digest again, and uses the public key to decrypt the digest stored in the script file.  It compares them, and if they match, then it's an authentic digital certificate.  If it doesn't match, then the certificate has been modified.

Of course, this is all good and dandy for the certificate, but what about the script?  I think the best approach would be to calculate a digest (and possibly the CRC32 as well) of the actual scripts themselves, and store this in the digital certificate.

And finally, I would recommend AGAINST building this public key into Plus!  It doesn't need to be a big secret, although I believe it would be much safer if the user had to explicitly say "Yes, I trust scripts signed by this group", so that someone can't just go and make their own digital certificates.  Also, since Plus! is an internet application, it might be worth considering the following:

Instead of storing the public key ON the machine, force Plus! to download it each time it wants to validate a script, and then remove it afterwards.  The advantage of this is that a script cannot overwrite the existing public key with it's own, so that it can forge digital certificates.  The downside is how to we stop this from happening at startup EACH time?  I haven't quite worked out a secure method for that yet, but I'll post again if I get any ideas (beside, I'm sure you've had enough of me talking by now )

So what does all that mean in layman's terms?  When people on some sort of script review board check a script, and determine that it is safe to use, they digitally sign it.  Then, when the user downloads the script for the first time, they are asked by Plus! if they trust this script, which has been signed by this particular group (which CANNOT be automated or skipped).  If they answer yes, the script would be installed, and ready for use (although they may need to explicitly enable the script).  If the script has no digital certificate, they should be informed of this, and asked if they really want to authorise it.

You could even provide a link to check if there's a signed version on the Plus! site...

Anyway, hope this has been of some help to someone

About digital signature, having it implemented might make a lot of fuss around this (important, though) issue and would create confusion for the users specially unexperienced ones. All this, besides what you already said, about being difficult to actually have a group of people (comitee) checking and validating all submitted scripts as "secure". It has yet another disadvantage.

Say the comitee exists, they might overlook some issues without noticing. For example, a script auto-updating by connecting on the Internet; it would be an obvious security risk, since it might be modified, when already being digitally signed. Of course, now that I'm talking about this, someone will sure come up with a solution for this particular issue. I already have (not allowing a script to modify the digital signature). And I'm sure they [the bad dudes] will find a way to bypass it: each time the script runs, "check for an update" and run the downloaded code without saving it. But what can be the real solution to prevent the scripting system from allowing these kind of problems? Who will the users _tend_ to blame for an infection from a digitally signed, assured-as-secure script? The comitee, of course.

This would also create an intertial behavior (users tending to do something because they got used to) like when I click "No" to all the would-you-like-to-set-this-page-as-your-homepage dialogs in IE, but most likely answering yes to a would-you-like-to-authorize-this-script dialog because it would be overwhelming and they want to check out what all this marvelous script they got is about.

You proposed several other, simpler alternatives which I liked a lot more, and I consider very more effective without sacrificing a sensible versatility amount in the scripting system.

What do y'all think?

Indeed, this is the problem with ALL computer-related security, if there is a way to implement it, there is a way around it; all that needs to be done is found it.

Every time I analyze the problem, I can always think of at least one way to circumvent it.  Solve that, but there's a way to overcome that...  it's a very unpleasant loop to get caught into (do { solveProblem() } while (1).

In any case, I still believe the best solution is the simplest... that, and education.  Perhaps a simple list of 'recommended' scripts would suffice...

Ah well, it's 0:08 in the morning (), better get sleep