When you have a robust Plugin API that is able to completely control all aspects of your bot (in this cass class/object), is there a real danger that a malicious user might use it to steal CD Keys or account passwords? I was just thinking about this the other day and added some security checks to prevent this from happening. Anyone else have any thoughts on the subject?

Basically, I'm encrypting password/cdkey information when it's written to the settings file, and I added a check in the Bot.Password and Bot.CDKeys accessors that checks to make sure the calling assembly is the same as the executing assembly (ie, only objects inside the BattleNet.Binary.dll can retrieve password/cd key information); otherwise I throw a SecurityAccessViolation containing the file name of the offending assembly.

Am I being paranoid?

Do you hallucinate evil men with camoflauge uniforms, large automatic guns, and tanks? If so, I'd say you're paranoid.

If people want to submit plugins for my bot, my condition is that they are opensource, and that I have the right to inspect and, if I decide to, reject them.

If people want to trade them amongst themselves, then that's their risk.

Actually, I'm going to write a filter that makes sure that cdkey and password can never be sent out to battle.net in plaintext.

[quote author=iago link=board=17;threadid=8619;start=0#msg79616 date=1094864423]
If people want to submit plugins for my bot, my condition is that they are opensource, and that I have the right to respect and, if I decide to, reject them.[/quote]

and if people don't agree to let you respect their code, what option do you leave them? ;)

[quote author=Kp link=board=17;threadid=8619;start=0#msg79630 date=1094868897]
[quote author=iago link=board=17;threadid=8619;start=0#msg79616 date=1094864423]
If people want to submit plugins for my bot, my condition is that they are opensource, and that I have the right to respect and, if I decide to, reject them.[/quote]

and if people don't agree to let you respect their code, what option do you leave them? ;)
[/quote]

Typo, respect should have been inspect :(

*fixes*

[quote author=K link=board=17;threadid=8619;start=0#msg79611 date=1094863450]
When you have a robust Plugin API that is able to completely control all aspects of your bot (in this cass class/object), is there a real danger that a malicious user might use it to steal CD Keys or account passwords? I was just thinking about this the other day and added some security checks to prevent this from happening. Anyone else have any thoughts on the subject?

Basically, I'm encrypting password/cdkey information when it's written to the settings file, and I added a check in the Bot.Password and Bot.CDKeys accessors that checks to make sure the calling assembly is the same as the executing assembly (ie, only objects inside the BattleNet.Binary.dll can retrieve password/cd key information); otherwise I throw a SecurityAccessViolation containing the file name of the offending assembly.

Am I being paranoid?
[/quote]
There is always that danger if you are loading untrusted code into a program. With a native program, the most sensible idea is to not to do it. I'm not familiar with how all the .NET access controls work, so you might be able to do something secure there with only granting certain permissions to verified, untrusted assemblies. I think you will have to do some very careful reading of the .NET documentation to get it really secure, though, as it only takes one slipup to break security.

[quote author=iago link=board=17;threadid=8619;start=0#msg79616 date=1094864423]
If people want to submit plugins for my bot, my condition is that they are opensource, and that I have the right to inspect and, if I decide to, reject them.

If people want to trade them amongst themselves, then that's their risk.

Actually, I'm going to write a filter that makes sure that cdkey and password can never be sent out to battle.net in plaintext.
[/quote]
I think you are fighting a losing battle. What if the malicious code encrypts or otherwise obfuscates the CD-Key/password somehow? What if it usurps the socket from your code entirely? etc...

Well, my way would make it hard to accidently do it.

For a period, there was a .get command which returned variable, like ".get homeChannel", etc. Whoever wrote it probably didn't realize the potential problems caused by .get cdkey.

My first solution is the main one, to be able to look at the code. The second is just for accidental leakage, more. I think both should be necessary.

One of the ways I plan on restricting certain methods and properties in the final version is using the .NET security StrongNameIdentityPermissionAttribute attribute (does Kp still think that Microsoft makes ungodly-long identifiers?).

Since my settings classes have instances provided to plugins, I'll need to keep my key pairs separate, since the public key will be part of my code.

But anyway, that's what I will be doing. I haven't done anything like that yet, but this attribute is probably what I need to use.

I implemented it:

[quote][20:21:54.942] <From: te(sting> homeChannel = op e1-
[20:21:54.946] <From: iago[e65536]@Lordaeron> homeChannel = op e1-
[20:22:02.170] <iago[e1]> %getvar password
[20:22:02.617] <From: iago[e65536]@Lordaeron> password = [password removed]
[20:22:02.642] <From: te(sting> password = [password removed]
[20:22:06.312] <iago[e1]> %getvar cdkey
[20:22:06.670] <From: te(sting> cdkey = [cdkey removed]
[20:22:06.753] <From: iago[e65536]@Lordaeron> cdkey = [cdkey removed] [/quote]

;)
[img]http://www.darkvariant.com/dubbs/exception.jpg[/img]

[quote author=iago link=board=17;threadid=8619;start=0#msg79941 date=1095038588]
I implemented it:

[quote][20:21:54.942] <From: te(sting> homeChannel = op e1-
[20:21:54.946] <From: iago[e65536]@Lordaeron> homeChannel = op e1-
[20:22:02.170] <iago[e1]> %getvar password
[20:22:02.617] <From: iago[e65536]@Lordaeron> password = [password removed]
[20:22:02.642] <From: te(sting> password = [password removed]
[20:22:06.312] <iago[e1]> %getvar cdkey
[20:22:06.670] <From: te(sting> cdkey = [cdkey removed]
[20:22:06.753] <From: iago[e65536]@Lordaeron> cdkey = [cdkey removed] [/quote][/quote]

Wouldn't it be better to instead have the bot refuse to return the information at all, rather than trying to return it and having it filter its own answer? That is, have the response be something like "Cannot query that variable over battle.net".

Kp raises a good point. How does your filter work?

What if someone says, .say <insert-password-here>. Does your bot respond, "So-and-so says: [password removed]" ?

Yes, it would say that.

When a SID_CHATCOMMAND is sent out, it is checked and, if necessary, filtered.

The thought I was having is that it depends on a well chosen password to be effective, and many probably don't have a well chosen password. Maybe I'll make this optional, off by default, and just leave the cdkey one.

[quote author=iago link=board=17;threadid=8619;start=0#msg79979 date=1095078360]
Yes, it would say that.

When a SID_CHATCOMMAND is sent out, it is checked and, if necessary, filtered.

The thought I was having is that it depends on a well chosen password to be effective, and many probably don't have a well chosen password. Maybe I'll make this optional, off by default, and just leave the cdkey one.

[/quote]
Why not just restrict those two variables to only be used internally, and not be allowed to be called by any commands/plug-ins/etc?

Oh the irony. Blizzard goes to significant lengths to make sure you bot makers cannot make bots, and you defeat the mechanisms. Now you want to protect your code from hackers :)

[quote author=Grok link=board=17;threadid=8619;start=0#msg79993 date=1095094488]
Oh the irony. Blizzard goes to significant lengths to make sure you bot makers cannot make bots, and you defeat the mechanisms. Now you want to protect your code from hackers :)
[/quote]

They do? I hadn't noticed. The war3 hashing was changed to SRP which is significantly more secure (unless you're sending plaintext passwords to bnls, but that's another story), but they're basically using an open protocol to do it. Maybe at one time they tried to do that, but I find it unlikely that they do anymore. Also, my code is pure opensource, so I don't protect it from anybody. In fact, I have no idea who/what you're talking about -- have you actually read the topic? :-P

The problem with your (Soul's) suggestion is that there isn't an easy way to make those variables special. Maybe I'll build in a special way, that it would be really roundabout and yucky to do, and break a lot of OOP-ness, and I don't like it :-/

[quote author=iago link=board=17;threadid=8619;start=15#msg79995 date=1095095896]
[quote author=Grok link=board=17;threadid=8619;start=0#msg79993 date=1095094488]
Oh the irony. Blizzard goes to significant lengths to make sure you bot makers cannot make bots, and you defeat the mechanisms. Now you want to protect your code from hackers :)
[/quote]

They do? I hadn't noticed. The war3 hashing was changed to SRP which is significantly more secure (unless you're sending plaintext passwords to bnls, but that's another story), but they're basically using an open protocol to do it. Maybe at one time they tried to do that, but I find it unlikely that they do anymore. Also, my code is pure opensource, so I don't protect it from anybody. In fact, I have no idea who/what you're talking about -- have you actually read the topic? :-P

The problem with your (Soul's) suggestion is that there isn't an easy way to make those variables special. Maybe I'll build in a special way, that it would be really roundabout and yucky to do, and break a lot of OOP-ness, and I don't like it :-/
[/quote]
Actually, as you should know, their implementation has several notable flaws that likely have a negative impact on how secure it is.

[quote author=K link=board=17;threadid=8619;start=0#msg79946 date=1095040134]
;)
[img]http://www.darkvariant.com/dubbs/exception.jpg[/img]
[/quote]

How'd you do that in code, K?

[quote author=MyndFyre link=board=17;threadid=8619;start=15#msg80041 date=1095116196]
[quote author=K link=board=17;threadid=8619;start=0#msg79946 date=1095040134]
;)
[img]http://www.darkvariant.com/dubbs/exception.jpg[/img]
[/quote]

How'd you do that in code, K?
[/quote]

That wouldn't work too well on a console bot :D

[quote author=MyndFyre link=board=17;threadid=8619;start=15#msg80041 date=1095116196]
[quote author=K link=board=17;threadid=8619;start=0#msg79946 date=1095040134]
;)
[snip img]
[/quote]

How'd you do that in code, K?
[/quote]

I've played with multiple methods. What I ended up doing was comparing Assembly.GetExecutingAssembly() with Assembly.GetCallingAssembly(), and throwing an exception if they were different - ie, only the assembly containing the class can read from it, but any one can write to it.

Another option is to not have the password / cdkeys be a property, but to have set_/get_ functions and mark the get_ function internal.

Yet another option is to insantate a System.Diagnostics.StackTrace and see where the call is coming from.

[quote author=K link=board=17;threadid=8619;start=15#msg80055 date=1095120991]
I've played with multiple methods. What I ended up doing was comparing Assembly.GetExecutingAssembly() with Assembly.GetCallingAssembly(), and throwing an exception if they were different - ie, only the assembly containing the class can read from it, but any one can write to it.

Another option is to not have the password / cdkeys be a property, but to have set_/get_ functions and mark the get_ function internal.

Yet another option is to insantate a System.Diagnostics.StackTrace and see where the call is coming from.
[/quote]

As I understand it, the get_ part of a property must be as-or-more-accessible than the set_ part. That might have been changed though.

Using the above-given attribute class, I tested it out to work as expected using the SecurityAction.LinkDemand value. If the calling method isn't in an assembly with a specified key pair, then an exception is thrown.

[quote author=MyndFyre link=board=17;threadid=8619;start=15#msg80056 date=1095121574]
[quote author=K link=board=17;threadid=8619;start=15#msg80055 date=1095120991]
I've played with multiple methods. What I ended up doing was comparing Assembly.GetExecutingAssembly() with Assembly.GetCallingAssembly(), and throwing an exception if they were different - ie, only the assembly containing the class can read from it, but any one can write to it.

Another option is to [u]not[/u] have the password / cdkeys be a property, but to have set_/get_ [u]functions[/u] and mark the get_ function internal.

Yet another option is to insantate a System.Diagnostics.StackTrace and see where the call is coming from.
[/quote]

As I understand it, the get_ part of a property must be as-or-more-accessible than the set_ part. That might have been changed though.

Using the above-given attribute class, I tested it out to work as expected using the SecurityAction.LinkDemand value. If the calling method isn't in an assembly with a specified key pair, then an exception is thrown.
[/quote]

not properties :P

[quote author=iago link=board=17;threadid=8619;start=0#msg79979 date=1095078360]
Yes, it would say that.

When a SID_CHATCOMMAND is sent out, it is checked and, if necessary, filtered.

The thought I was having is that it depends on a well chosen password to be effective, and many probably don't have a well chosen password. Maybe I'll make this optional, off by default, and just leave the cdkey one.

[/quote]

Yes, with a badly chosen password and some auto-replies it might become highly ineffective at protecting the password.

Example:

User uses a word found in a dictionary as the password for the account.

Op bot with a public command such as ".msg" for leaving a message for a particular registered user.

Bot replies with "Error: User 'username' doesn't exist!" when given the command ".msg username yo, sup?" if username doesn't exist.



Do you see the danger? :P

People should use either 'e' or ' ' for their passwords. It's short, simple, and easy to make bots mistakenly filter it.

[quote author=Grok link=board=17;threadid=8619;start=0#msg79993 date=1095094488]Blizzard goes to significant lengths to make sure you bot makers cannot make bots, and you defeat the mechanisms.[/quote]They do? I would be more worried about cheating instead of programs that monitor (even abuse, in the cases of spammers and flooders) a proprietary chat system.