Forums Feature Suggestions Registry Manipulation

Ignoring Anti-Virus advice and enabling WSH so mIRC can do $windir and $regread is moronic

Ok, you mentioned this before too, so I gotta ask: which antivirus completely disables WSH for security purposes? I have Norton Antivirus 2003 and the only related feature is Script Blocking. SB does not completely disable WSH though: it prevents (or pops up a warning before it does) script files (such as .vbs, .js etc) from being run. It doesn't even disable ALL scripts, only those with "suspicious" commands in them (such as file operations). It certainly does not interfere with the COM interface of the WSH objects, at least here.

mirc can do $windir and $regread (and even $regwrite) just fine with Norton Antivirus SB enabled. I don't know what other antivirus software do and whether they disable WSH completely, but if something sounds moronic is to disable the entire WSH (including its COM interfaces) just because of some strange belief that "it's safer".

I never stated that it disables WSH automatically. In previous versions there was an option to disable it, you were advised to disable it. I don't know about Norton 2003. But I do know that the Symantec website still recommends the same thing that you call a "strange belief":

"One preventive measure that you can take to protect yourself from viruses that come as .vbs attachments is to disable or uninstall the Windows Scripting Host. Because Windows Scripting Host is an optional part of Windows, it can be safely removed from your computer. This feature can easily be reinstalled if it is needed in the future. Remember that there are many other viruses that do not use the Windows Scripting Host, so it is critical that you continue to use Norton AntiVirus protection with the most up-to-date virus definitions. "

You have to remember not everyone uses Anti-virus software, Let alone Norton 2003. So it is indeed safer for people to follow the above advice. Basically your snippet is reliant on 2 external programs; WSH, and seeing as you now have that security risk enabled you better get Norton2003. That isn't so great.

Eep. This thread is getting out of hand. The suggestion is out there and there has been very little constructive criticism. Just because something can be done via COM or DLL support doesn't mean that it isn't a valid feature request.

Remember, this isn't a forum to debate feature ideas. It's a forum to suggest ideas. The only debating done is inside Khaled's brain (ok maybe arnie helps a bit)

-chris

I never stated that it disables WSH automatically.
I never stated nor implied that you stated such a thing.

One preventive measure that you can take to protect yourself from viruses that come as .vbs attachments is to disable or uninstall the Windows Scripting Host.
Finally, we're getting somewhere. What Norton states is that .vbs attachments can be dangerous. This is not a "strange belief", .vbs attachments are indeed responsible for the spreading of viruses. Clearly, a way to stop .vbs files from being run (or ask the user with big red exclamation marks about it) is needed. The simplest, but most naive, method is to uninstall WSH. What - it seems - you didn't realize is that there are ways to stop .vbs files from being run other than uninstalling (or completely disabling - note the bold) WSH. Norton AV does that very well: it prevents (or asks the user whether it should, something that's configurable) scripts from being run, nothing more, nothing less. This means that no .vbs, .js etc files can be run, but the COM interface of the WSH objects still works. THAT's what mirc uses in $regread/$regwrite/$windir: it communicates with the objects via COM, it doesn't run any script files. So, no running scripts = everybody's happy (mirc, Norton and the user).

Yes, you are reffering to Norton 2003. As far as I remember, the older versions of Norton just gave you an option too disable WSH. And the above advice from Norton says that it's safer to disable WSH. Your COM snippet demands that WSH is installed, and for safety you must use Norton 2003. That's 2 dependancies that I wouldn't want to impose on the users of my scripts. What if a user doesn't have Norton, and they install WSH to support my COM script, It will then be my fault when they get infected through email attachments, etc. That is a very real scenario. mIRC could implement $regread (Note, I never upheld /regwrite in the first place), and there would be no security issues attached to it.

This doesn't matter anyway, I don't wish to debate the validity of using WSH in mIRC. This feature request is good enough to stand on it's own, regardless if WSH snippets work or not.

I believe all the arguments on this topic are exhausted now. As d00d said, the feature request is here, lets leave it too Khaled to decide..

i think also $regwrite and $regread is useful,
the creation with com objects or dlls is more dangerous than an $regwrite or $regread to disable or enable.

The most of "normally" mirc User dont know

The Download an normal Addon, and than are an com objects or dlls is on it and the trojan has been installed (And there could also read/write in registry)

With reg commands to enable/disbale it, is the responsibility from the users only.
And if you could choose which scriptfile is it allowed to use $regread or $regwrite it is saftlier than uncontrolled com objects or dlls in mIRC

The other Way:
dlls now it can be disable
com objects must be the same (I couldn't disable my WSH on my complete system, only why mirc could use it...)

Everyone know this, and khaled could be add an hint if there reg commands or com objects (with wsh or any other objects) on it.

So the user knows.
if he agree, is it his problem

Prizm, you specifically mentioned keeping script values safe from users. You don't need a windows registry manipulation to do this. All you need is hash tables. In fact, that is one of the best reasons for using hash tables.

Having said that:

1) Ethics: script users should be able to tinker with the script values, or else you should not be able to set those values yourself.

2) Windows Registry Manipulation will open mIRC to another category of hacker. We all know this. I'm surprised no one has mentioned it on this thread.

3) Prizm, if you don't know how to work COM objects, how do you REALLY expect to know how to mess with the windows registry safely?

As you do talk about the regitry ediiting scripts--



*also assuming the enviornmental variable alias was added.

Are you saying that would cause a virus to open every time the computer is started?

Dude, it might even get worse than this. The DALNet hacker club has found even more exploits than the mind can fathom WITHOUT such easy access to the registry. They could possibly do a field trip with this.

* sings in his head o/` The wheels on the bus go round and round... o/`*

You do mean Field Day, right?

Personally, I dont see any valid reason why a CHAT program needs to have any kind of registry commands/identifyers. I know people will say "because it's better/easier than using "X"" to which I say, it might be better sure, but that doesnt mean it has to be there.

if uve read this thread from the very begining ud see the very reason many have been slightly opposed to this is the sole fact of having a very dangerous manipulation set built in to every mirc that could do so much more than just start a virus on your pc everytime u start ...... say some fool figures something like this is set in on all ur mircs and makes up a $decode of something for ppl to type in the wipes out thier registry
not only is that worse than a virus to some ppl ....... but add the fact that passwords to your system are stored into this ...... now the intelligent scripter can now make your system do ANYTHING he wants ..... total control of manipulating anything in your pc from a remote settup ....... and think of it like this ...... if its a registry change and not a program change how would a virus scanner find this alteration? ...... most times it wouldnt ....... ud end up with a pile of hacker enabled junk and ud be causing a horrid flood of networks simply because some immature child learned a couple commands to have an inexperianced user cut and paste ....... i personally wouldnt like mirc to end up a total joke of all programs for having this type of huge security issue just based on the fact it has alot of limited knowledge users

My God people!

Quit it! You're insane monkies!

Ok, I'm going to start off by saying that if registry read/write were enabled by default, people could create some pretty creative scripts by doing such things as scanning for reg keys of certain installed programs, then going from there.

The bad seems to far outweigh the good though. I think registry manipulation using a simple command is a terrible idea. Just think about all of the morons that listen to the "no spam" and "matrix 2" messages.. mIRC WOULD most likely become a terrifying program to use to morons, and yes, there are a LOT of morons in the world today, why do you think infomercials work so well?

When it all boils down to it, if there is no such thing as $regwrite or some similar command, then there won't be the possibility of morons and newbies running very very malicious code, but registry editing for scripters is still very easy to do by using that nice little dll or that simple little script posted somewhere inside of this thread.

You might argue, "Well what about the scripters who don't know about the DLL or the code snippet?". If they don't know how to go to this place called "google" and search for what they need, then they are probably a severe newb and shouldn't be messing with their registry in the first place.

I'm not saying the suggestion is a bad idea. In fact it would be great if such a feature could be enabled, but because of lamers who like to write dumb little $decode scripts, features like this simply should not be added.

Keep in mind guys: This is not a voting board or a debate club, arguing things till you're blue in the face isn't really worth it. You should state your opinion if it is constructive criticism, but you really shouldn't argue your point over and over.. The same goes for the person who made the suggestion to begin with. (yes, it is irritating when someone severely tries to defraud what you suggested, but I think khaled is smart enough to debate the issue for himself). Unless you have something new to add to your arguement, why argue?

-- My mIRC did not come with /run and /dll disabled. They were enabled. (just because the help file says they're disabled by default doesn't mean they are..)

-- To anyone who knows how to use COM objects: Are COM objects easy to use? If so, could perhaps a small list of useful COM objects be listed somewhere? I'd like to see what I could do with them.

very very well said you got my point acrossed more clearly than even i did