Exposing the user to harm
 

I don't know, maybe this gets deleted. I think it's valuable site feedback. When a security vulnerability is found in software, there is a specific sequence of events every commercial and open source site I've ever work with, or for, follows.

1) Fix it.
2) Post the patch.
3) Inform the users about the availability of the patch.

This is done to protect the users. Any other sequence puts the users at great risk of harm because it announces a security vulnerability before a fix is available. It actually alerts the people who might wish to do harm that a vulnerability exists and has not been patched.

Further, you don't give out specifics, such as saying it's an HTML injection issue, until after the patch has been made available. Once again, to keep that information from the hands of those that would do harm.

The policy here is backwards, and potentially damaging.

/me gives a hug to hambil !!!

/me laughs at all of the stuff going on lately

I agree, and it sounds good. Needs to go through with the plan!!

/me needs a hug too

/me wants to know if you want one from me.

/me looks at the clock and realizes its way past my bed time. Night all

The problem is though, unlike the developers you talk about, coders here may have a lack of action.

Alright guys, can we keep to the topic please :)

Chris

There is a big difference between commercial sites and here - your proposal relies on the author actually fixing it - experience shows that this is rarely the case for free modifications released here (take vbplaza, that's still not fixed, months after the holes were found and notified to the author).

We have to have a policy that suits the majority of cases here, and the one we currently have serves that purpose - and while it may not have been ideal for your case, your's is, I'm afraid, an exception, not the rule - the last few have either not been fixed, taken a while to get fixed, or in a couple of cases a staff member has eventually fixed them.

However, we will review what we do to see if it can be tweaked to suit cases where the author is known to be still active.

Of course, it won't make any difference to you since you decided to take all your mods away anyway.

If fairness, if I'm not allowed to say why I did the above, you should not be allowed to use it against me.

This is, perhaps, the crux of the current misunderstanding. I remember vbShout going unfixed forever, until Brad had to fix it. I remember other hacks that had similar issues. That is why I know what the policy used to be - notify the author asking them to change it, and only if they were unresponsive for a fair amount of time would the mod be disabled or, fixed by staff if a staff member was willing.

For such a dramatic change in policy to take place, and for an active hack author to not even know about it, is a serious flaw in the conduct of business - regardless of what you say about the rules being posted.

How about a show of 'virtual hands' for coders who had no idea a policy change had been implemented? I'm sure I'm not alone.

That aside, I still think it's a flawed policy. The email that went out to all the users stated:
This modification contains a MySQL injection vulnerability

It was also put into the thread itself in nice large red letters:
This modification contains a MySQL injection vulnerability

This puts every user of the hack at risk. It also creates a nice little searchable database for anyone who might want to start hacking VB sites. It's an all around bad idea.

Which is a good reason not to use third party hacks, imho. Learn to code, take care of your own board is what I say. Whilst I appreciate the willingness to share, I think there are too many strings attached that I'm not willing to "be strung up by" for lack of a better description. I also think there are waayyy too many over-inflated ego's on this site (nothing personal towards anyone) and it really does look petty to most.

/speech :)

The official vBulletin Modification site is a strange place to be hanging out, then.

He or she is here for the styles I think, from her signature.

/me has an inflated ego

At vBhackers, we have a system in place that staff use. If a hack has either been a complete rip of someone elses work (usually stolen from here) or contains a security vulnerability, then staff simply put the hack into a "investigation mode". This then places the thread in a moderation queue, a pm is sent to the author and a new thread is created in the staff section to inform other staff members, this is all automatic.

Maybe the vb.org staff can come up with a similar system to handle these problems.

With the amount of changes many of these skins make, I see little difference. In fact, I've had more bugs introduced from skins than mods. But, too each their own :)

I'm here for many reasons that have nothing to do with mods...as are many others ;)

Have you ever heard of a security hole being introduced from a skin?

The policy has two sides

If a security hole is found, it is up to users to uninstall the hack. It is also a good idea to not let it be downloaded and for a warning to be put up.

But then letting the author know before hand is also good. If they're not active, take it down

Thats just my opinion

Hum,...psst... HTML inserts and javascripts exploits are induced by skins... can you just be neutral when you don't know...

anyway, these discussions are completely worthless... if you are not happy with an administration, create your own and start your project... you'll be the one to deal with your problems...

While it'll probably never happen...a style release could contain some very nasty stuff if not for a small portion of php code in adminfunctions_template.php.

I didn't say it was impossible, I said have you ever heard of it happening? Please check your over-inflated ego at the door :rolleyes:

I agree. Not every coder in this site for hobbyists will want or have time to fix their mods, so the policy of removing them. Asking to be treated differently is an ego problem.

I think this is a great idea, this give the users who have installed the hack, ample time to remove the hack from their site.

If you don't keep up with the hacks on your site, that's your problem ;)

just my 2cents :D

I'm not asking to be treated differently. I'm stating that 1) Even if you accept that instantaneously removing a mod is a good thing, broadcasting specifics about the security flaw to the world before it is fixed, is not smart. 2) When a board policy undergoes a significant change, a process should be in place to make sure those affected are aware.

Hey, i paid for that ego, please give it a shot !!!

Have you heard of a board being hacked because of a security flaw in a mod? I've been doing this for years and I haven't. The few hackings that I am aware of where over flaws in vb itself.

The biggest problem facing board owners using third party software is bugs, not security flaws. And skins can, and do, introduce plenty of bugs.

This thread is about security holes. I do agree with your position about how notification takes place, however.

The email is a good idea to all installers of the hack...I certainly would prefer to receive an email to let me know!

I agree totally, but, then again, it shouldn't be an issue if the installers of the hack
disabled it, if they haven't, then its their own fault, they have been warned, Twice...

As you are aware, it only sends an email to people who have marked install. And the thread update will only reach people who have subscribed to the thread (actually not, even that, because I never got a subscription notice when the thread was updated and moved).

We are all very much aware that the installed number only represents a portion of the actual installs.

In a recent vbBux thread, the problem is referred too as a 'security exploit' which is a better way to go.

How it should be worded is always debatable, everyone has their own views.

I believe users should be told whether it's XSS or MySQL or whatever - without further details you cannot exploit it anyway.

with any detail like "sql inject" or "xss exploit", you can exploit any hack because they are not encoded... with a hack with a single sql query, it is easy to learn how the inject can be done...

if instead you contact the coder, that coder make the change in a reasonable delay, and then update his script without noting the exploit, it would be infinate the risk of a hacker trying to reproduce the exploit and profit from it...

and btw,as anybody can suggest changes to a hack to the coder, why not providing a fix yourself as you already know the exploit, so the coder simply have to update its release... this is a community of sharing after all...

I'd also recommend that as new exploits are discovered, they are given examples, along with the fix, in the private coders forum - probably in a sticky, indexed thread. This way coders can keep up on their old hacks, and avoid possible problems with their new ones.