@x00 sorry, when I tried it, it worked in removing the original thing which is the script alert. My bad for not understanding the preg_replace fully. Thank you for pointing out the right path. I was just trying to do right by everyone to solve it on a Sunday. it's too bad this was not reported directly to the admins of the software rather than placed in the community. But once the cat is out of the bag we are all vulnerable...
Thank you also for pointing me to the right way to do things.
@x00 I get what you are saying about sanitation of output. Your skills are more battle tested, so you may see how to do that. I do know that if this vulnerability was being exploited we would have heard about it sooner. Once it's made public here, as opposed to some random exploit site, we are all at risk. So I think by protecting the inputs, at least for now, is a good thing--but unless one is certain to be clean, I guess the best bet is to disable the flag plugin.
This guy with the exploits site is a bit of a sad case from Cardiff university. He could easily have reported in a more direct way, he just wants his 5 minutes of fame.
I used to do similar stuff to this guy (you have to have some time on your hands), except I gave the company the information too. In some cases they didn't respond appropriately, one case (a well know company), the contractor tried to bribe me, this was an exploit that was open for a number of years and they were aware of it.
If a company doesn't respond appropriately, continuing to put users financial/personal information at risk, etc. then rightly you should expose it.
it's too bad this was not reported directly to the admins of the software rather than placed in the community. But once the cat is out of the bag we are all vulnerable...
If this is directed to me, I could not find any place to report security vulnerabilities directly and this has been public for a "long" time anyway. I disagree with reporting it here is getting you at risk, but rather it'd make you feel at risk. Random exploit site or not it is trivial to find and in fact came quite on top when I googled for vanilla forum exploit just to see what was out there.
@lolo999 it was not directed at you--what I meant is once its public, as opposed to being disclosed properly by the finder it makes being hacked that much easier. Thank you for noting it so we could take action
well if they want to delete my drafts they are welcome to it lol There is no mass draft delete is there ? so , come and get my drafts !!! Read them first though they have useful tips
it's too bad this was not reported directly to the admins of the software rather than placed in the community. But once the cat is out of the bag we are all vulnerable...
Sick of people ranting about how I should have reported it to the vendor first when they do not know the situation. I have a message thread with Todd, Lincoln, UnderDog dating back to June 2012 where I report all my findings to them, these vulnerabilities and MORE which I did not release publicly were reported on the 14th of May 2013 , to which he replied
"Thanks so much for this. We actually just got roughly the same report and have a fix ready for the 2.0.18 branch, but I'm still in the process of fixing it for our 2.1 branch." .
@H00j said:
I have a message thread with Todd, Lincoln, UnderDog dating back to June 2012 where I report all my findings to them, these vulnerabilities and MORE which I did not release publicly were reported on the 14th of May 2013
I Just don't get it. Why on earth would you ever want to release those vulnerabilities to the forum?
Enlighten me, educate me, because what do you gain from showing everyone these things?
First of all thanx to @H00j: I also stand with releasing vulnerabilities in the community.
I remember that Joomla had a security thread back in 200something in their forum that helped to avoid addons that weren't secure. What if a MOD would start a thread editing and updating the first post with all information gathered in the answers below.
And more importantly now... how many vulnerability issues does have the Vanilla core now on what security level. when can we apply an update from the coreteam or how could we gather all the issues and the code fixes.
VanillaAPP | iOS & Android App for Vanilla - White label app for Vanilla Forums OS
VanillaSkins | Plugins, Themes, Graphics and Custom Development for Vanilla
@H00j Thanks for clarifying that you reported the vulnerability. That's an awesome way to make a better product for everyone. I guess where I have a beef & where I still feel a rant is in order is that when the admins did not patch it in a timely manner, you then dumped the vulnerability on some random site where no one would know it ---except those who are maliciously looking to exploit our sites. Thankfully @Lolo999 found it. He is my hero because he posted it here, so we could protect our sites. With his post, the community took action, and users could either modify or disable aspects of their community (at least until official actions is taken).
I think we will have to agree to disagree on the right path. To announce security vulnerabilities in such a way, in my view, is anti-community. It's okay that you did not want to provide solutions, but how about a warning to those in the community by opening a thread publicly like this one? We all work hard on our sites. If you have knowledge of things that can ruin all our hard work, how about you let us work on the fixes too? How is it fair to leak on a site where we won't discover until we get hacked or someone here opens a thread months later.
I might get flamed on this, but it's my POV and I guess I'll stand in the minority. Now if you have other MAJOR vulnerabilities you think need to be fixed, and you have already released elsewhere, do us all a favor and let us know what they are. In this way we can at least take action. I know I have personally invested months, if not years of dev time on Vanilla Forums. I would hate to see this all be destroyed by something as preventable as you letting me know about it here.
I'm behind you 100% @adriansonline - your reasoning seems well thought out. especially the random site.
One would think posting vulnerabilities under the plugin name would be the way to go, if the intent was to help the community. If the intent is to provoke the developers of vanilla, thats a different matter. but many of the vulnerabilities that are pointed out deal with code not written by the vanilla developers, and more than likely someone will step up to the plate to provide a fix on the plugin or users will know they have the option disable until fix is provided by someone.
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
I agree @peregrine, if a plugin is at fault, either place it under the thread, or email the author of the plugin. It's also easy to use the @ symbol in the thread to advise them. The developer should then be allowed to fix-it or remove the add-on if they can't/won't.
@H00j said:
Sick of people ranting about how I should have reported it to the vendor first when they do not know the situation. I have a message thread with Todd, Lincoln, UnderDog dating back to June 2012 where I report all my findings to them, these vulnerabilities and MORE which I did not release publicly were reported on the 14th of May 2013 , to which he replied
I don't think there is any issue with this, there is issue with people who post vulnerabilities for kicks without fair warning. There is no issue with people who try to help.
I also kind of agree on putting some reasonable pressure on a vendor to close the exploit.
I want to be perfectly clear that this bug was responsibly disclosed to the core developers, we simply did not act quickly enough on this one. It is indeed best to do exactly as was done here: give us a heads up, then report to the community if we don't patch it within a couple weeks.
Once a flaw is public, for future reference, it can be filed in the GitHub issue tracker with [security] as an optional prefix.
There will be a 2.0.18.9 release to address these and a few other issues. That will mark the end of the 2.0 branch unless additional security issues crop up.
Comments
@x00 sorry, when I tried it, it worked in removing the original thing which is the script alert. My bad for not understanding the preg_replace fully. Thank you for pointing out the right path. I was just trying to do right by everyone to solve it on a Sunday. it's too bad this was not reported directly to the admins of the software rather than placed in the community. But once the cat is out of the bag we are all vulnerable...
Thank you also for pointing me to the right way to do things.
@x00 I get what you are saying about sanitation of output. Your skills are more battle tested, so you may see how to do that. I do know that if this vulnerability was being exploited we would have heard about it sooner. Once it's made public here, as opposed to some random exploit site, we are all at risk. So I think by protecting the inputs, at least for now, is a good thing--but unless one is certain to be clean, I guess the best bet is to disable the flag plugin.
No worries, thanks for being helpful.
This guy with the exploits site is a bit of a sad case from Cardiff university. He could easily have reported in a more direct way, he just wants his 5 minutes of fame.
I used to do similar stuff to this guy (you have to have some time on your hands), except I gave the company the information too. In some cases they didn't respond appropriately, one case (a well know company), the contractor tried to bribe me, this was an exploit that was open for a number of years and they were aware of it.
If a company doesn't respond appropriately, continuing to put users financial/personal information at risk, etc. then rightly you should expose it.
grep is your friend.
If this is directed to me, I could not find any place to report security vulnerabilities directly and this has been public for a "long" time anyway. I disagree with reporting it here is getting you at risk, but rather it'd make you feel at risk. Random exploit site or not it is trivial to find and in fact came quite on top when I googled for vanilla forum exploit just to see what was out there.
it wasn’t directed at you @Lolo999
grep is your friend.
The authors page http://www.henryhoggard.co.uk/ lists many vulnerabilities.
Plugin authors should take note.
There was an error rendering this rich post.
@lolo999 it was not directed at you--what I meant is once its public, as opposed to being disclosed properly by the finder it makes being hacked that much easier. Thank you for noting it so we could take action
well if they want to delete my drafts they are welcome to it lol There is no mass draft delete is there ? so , come and get my drafts !!! Read them first though they have useful tips
❌ ✊ ♥. ¸. ••. ¸♥¸. ••. ¸♥ ✊ ❌
My hotfix for draft deletion prevention caused a problem with draft auto-deletion upon the posting of a comment. Proper line is:
if ($Draft && $Draft->InsertUserID !== $Session->UserID) {
Sick of people ranting about how I should have reported it to the vendor first when they do not know the situation. I have a message thread with Todd, Lincoln, UnderDog dating back to June 2012 where I report all my findings to them, these vulnerabilities and MORE which I did not release publicly were reported on the 14th of May 2013 , to which he replied
I Just don't get it. Why on earth would you ever want to release those vulnerabilities to the forum?
Enlighten me, educate me, because what do you gain from showing everyone these things?
There was an error rendering this rich post.
I'm glad @H00j made the issues known so I could fix them right away. I'm frankly more concerned about the issues he hasn't disclosed.
Please explain, what do you not understand?
They have been disclosed to the devs, just not publically, to clarify.
First of all thanx to @H00j: I also stand with releasing vulnerabilities in the community.
I remember that Joomla had a security thread back in 200something in their forum that helped to avoid addons that weren't secure. What if a MOD would start a thread editing and updating the first post with all information gathered in the answers below.
And more importantly now... how many vulnerability issues does have the Vanilla core now on what security level. when can we apply an update from the coreteam or how could we gather all the issues and the code fixes.
@H00j Thanks for clarifying that you reported the vulnerability. That's an awesome way to make a better product for everyone. I guess where I have a beef & where I still feel a rant is in order is that when the admins did not patch it in a timely manner, you then dumped the vulnerability on some random site where no one would know it ---except those who are maliciously looking to exploit our sites. Thankfully @Lolo999 found it. He is my hero because he posted it here, so we could protect our sites. With his post, the community took action, and users could either modify or disable aspects of their community (at least until official actions is taken).
I think we will have to agree to disagree on the right path. To announce security vulnerabilities in such a way, in my view, is anti-community. It's okay that you did not want to provide solutions, but how about a warning to those in the community by opening a thread publicly like this one? We all work hard on our sites. If you have knowledge of things that can ruin all our hard work, how about you let us work on the fixes too? How is it fair to leak on a site where we won't discover until we get hacked or someone here opens a thread months later.
I might get flamed on this, but it's my POV and I guess I'll stand in the minority. Now if you have other MAJOR vulnerabilities you think need to be fixed, and you have already released elsewhere, do us all a favor and let us know what they are. In this way we can at least take action. I know I have personally invested months, if not years of dev time on Vanilla Forums. I would hate to see this all be destroyed by something as preventable as you letting me know about it here.
I'm behind you 100% @adriansonline - your reasoning seems well thought out. especially the random site.
One would think posting vulnerabilities under the plugin name would be the way to go, if the intent was to help the community. If the intent is to provoke the developers of vanilla, thats a different matter. but many of the vulnerabilities that are pointed out deal with code not written by the vanilla developers, and more than likely someone will step up to the plate to provide a fix on the plugin or users will know they have the option disable until fix is provided by someone.
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
I agree @peregrine, if a plugin is at fault, either place it under the thread, or email the author of the plugin. It's also easy to use the @ symbol in the thread to advise them. The developer should then be allowed to fix-it or remove the add-on if they can't/won't.
I don't think there is any issue with this, there is issue with people who post vulnerabilities for kicks without fair warning. There is no issue with people who try to help.
I also kind of agree on putting some reasonable pressure on a vendor to close the exploit.
grep is your friend.
I want to be perfectly clear that this bug was responsibly disclosed to the core developers, we simply did not act quickly enough on this one. It is indeed best to do exactly as was done here: give us a heads up, then report to the community if we don't patch it within a couple weeks.
Once a flaw is public, for future reference, it can be filed in the GitHub issue tracker with [security] as an optional prefix.
The correct patch for the Flagging XSS is here: https://github.com/vanillaforums/Garden/commit/e117af7c126944514749b2e01244392077d0ac5c
The drafts issue has been filed here: https://github.com/vanillaforums/Garden/issues/1672
There will be a 2.0.18.9 release to address these and a few other issues. That will mark the end of the 2.0 branch unless additional security issues crop up.