In the original post that started this group, it was mentioned how not everyone knows where to look for extension vulnerabilities, end user's are rarely aware of all but the largest components that expose them to issues, and there's not a great way to get this information out to 'novice' users.

Let's come up with a way to fix that.

I know of the Joomla Vulnerabilities Wiki, but it doesn't seem to be frequently updated. Even then, end-users aren't likely checking that frequently.

So starting off, how do we monitor for these vulnerabilities in the first place - Secunia, hacker forums, etc? Once found, what are ways that we can improve the system of getting the Vulnerabilities Wiki (or another site) updated? Finally, what's the best way to notify users of that extension?

Originally, I proposed a 'security' extension which can automatically fetch information about any installed extensions from a 3rd party site to report if there are known vulnerabilities (or even version updates). We have a partial system implemented for grabbing version numbers and the hardware to handle it.. but is that the best course of action?

What are your thoughts/suggestions?

Views: 28

Replies to This Discussion

Hi Alex,

I see where the problem seems to be then, I have no parameters in the extension. I see the XML file for the parameters but in the extension page I don't see any parameters.

You can see it in the annex.
Attachments:
Ahh.. there's 2 things we've realized. We'll be posting an update for the first soon:
1) The parameter isn't defaulting correctly because of a coding error (not a big deal). So the default is wrong. Saving the value to no should fix this...
2) However, for editing params in Joomla, you have to be a Super Admin. We usually get around this and shove the parameters into a view so that com_config doesn't lock users out. I'm assuming you're not a Super Admin, and therefore, can't see the Parameters button in the toolbar.

Sorry again, and thanks for the feedback.
and i just put a report in to the JED
also interesting topic http://groups.google.com/group/joomla-wg-community/browse_thread/th...

[quote]is the any way - or suggestion for making the
http://docs.joomla.org/Vulnerable_Extensions_List
replicate on the forum (and updating it) as not may look in the docs
for the V List
i have replicated this in the site feedback forum
[/quote]
Thanks for posting this idea there, I'd love to hear the Joomla, and JED team in-particular, responses.

To re-iterate my concerns, if the conversation continues there, I'd like to understand their feelings for non-GPL or other GPL extensions which aren't listed on the JED and how to handle those extensions.

I'm not a member of the group there (yet), but hopefully I will be soon and can contribute to the plan.
Just tracked it down, the suggestion for the tie in JED list was
Post subject: vulnerable list Posted: Sun Oct 11, 2009 9:20 am
http://forum.joomla.org/viewtopic.php?f=7&t=449418&p=1884922 before it moved on to the google working group list
1. A team of third party developers

2. Identify vulnerable extensions - Start with manual, maybe we can mechanize this as we go on. Using whatever sources we can find (Secunia, www.milw0rm.com, osvdb.org, etc) pay close daily attention to reports.

3. When there is a report, notify the developer and JED (and any registered directories) to have the extension removed.

4. Offer the developer peer support to patch the vulnerability, if needed.

5. When the extension has been updated (developer notifies us or we notice it on JED), we can update our list. Other directories could get information from us and send out notice to their users. That could be an RSS feed, or something fancier, like this version verification tool. (Nice.) There has been some talk already that JED could provide that security feed for users.

6. Follow up with the various security clearing houses to post the patch and get the issue closed.

Alex - I can't imagine JED or Joomla.org having any involvement with any extensions not listed on their site. As an independent third party group, I agree with you that security trumps the license talk and we should try to find and notify those developers and share a feed ourselves for other directories, such as yours, to use.
Hi Alex,
Thank you very much for your support. I am a super admin but I don't know why I still can't see parameters.
I will try to change the XML file to no and see if I ca run this tool :)

Thank you very much again for your support.
I don't know why your GPL extensions were removed. I'm not on JED. I'm not working in the project at this time. I'm not privy to those discussions.

If I were to guess - I assume your GPL Extensions were linked to the CMS Market Repository? If so, it wouldn't surprise me if JED removed all the listings linking to that resource. It's not a matter of liking you or not liking you, but rather supporting the developers/Extensions that do not violate their license. CMS Market lists non-GPL compliant extensions so in providing a direct path to that archive there would be a link to an archive they are trying to move away from. You can't really blame them -- if they wanted to continue promoting that work, they wouldn't have removed it.

Have you considered putting your GPL extensions on Joomlacode? If you used that resource, and a listing that wasn't CMS Market, I'd guess you could list them.

If you want to add me on Skype AmyStephen, we could talk, if you want.
Hi Amy,

I would suggest us to create a stock answer (like a template) to be used for contacting developers.
This stock answer should include what kind of bug/issue it has and what the developer needs to do to fix it. Example (if it is a SQL Injection then we should provide him with the appropriate links where he can find the useful information to fix his issue.
I don't know if there is a best practices Joomla extensions development page, if not, it would be great if we could create one and include this page in our stock answer.
We would include the most common issues and then personalize it according the extension issue. By doing so, all our communication keeps consistency and accuracy, not to forget the amount of time it would save us since, I imagine, there will be a lot of communication between us, JED, developers and website (Secunia, www.milw0rm.com, osvdb.org, etc).

This stock answer would cover point 3 and 4.

We should also create a stock answer for point 6 since we will be more than one person (I guess) manually scanning trough the different websites that will need to contact the website after the extension has been fixed.

These stock answer will also allow this project not to rely only on the person who is doing this task, if for whatever reason this person quit the project some one else can take over his job without a lot of pain.

For point 5, I would suggest developers to contact us otherwise it might make our work harder since we'll have to scan JED for updates which is time consuming. I think either Thomas idea or Alex tool are great solutions, unless some one else as a better one :)

We will need to find a way to avoid doing the same work more than once. I don't know yet what we need to do but I think we should think on that. Maybe one person per website.
BTW - that wiki resource is from the security "burn" a few years ago. It really has not been maintained and should be removed. Currently, reporting of vulnerable 3rd party extensions is sporadic. JED removes the extension if it's reported and notifies the developer. When a new release comes, the extension is published again.

What's missing is an activist group that looks for these vulnerabilities and contacts the developer and JED.

The other piece that is missing is the RSS feed from JED that only has security patches. That could be subscribed to by users for security fixes. Yes, they would get more than needed, but it's a start.
Like your ideas. To add - maybe our first step is identifying all of the various security sites - and then figuring out how to get an RSS feed for our Joomla extensions.

Example, Secunia Advisory and Vulnerability Database - search for joomla. If we could get these in an RSS feed - or some type of feed - we could pull it into a database and then automate updates every day, isolating the new reports.

We should track back through these old reports because many will likely still need patches. Plus, we should clean up those old reports if they were patched.

I like the idea of a stock answer - with suggested solutions for typical security problems - implemented in Joomla!. That's a great idea.

The problem I have with suggesting the developers contact us is that JED is *the* place. I don't want use to slow down this flow in any way. What we might want to do is contact the developer every day to see how it's going and to see if we can help. (To speed it along, if possible.)

Agree about the need to nail down workflow.

If we could create automation and your stock answer ideas, it could be good to share that code with JED, or other directories, and possible not have an ongoing role here.

Just thinking out loud. Like your ideas Helio. Need to look around - find those security locations - see if there are RSS feeds - and see if we can pull it into a database.
There are plenty of GPL extensions in the JED, which then link to a page which heavily promotes other non-GPL and even encrypted extensions. However, this isn't the place for that argument, and I didn't mean to start it here.

My main point is that this is about how to get security information out to the public in the best way, and I still have my reservations that making it JED centric can be a bad move. In light of saying that, I fully agree that Joomla.org should be involved in whatever solution is agreed upon, and I like your ideas (in another post here) that other directories should be involved in the process. I'll respond directly to that post though.

RSS

Badge

Loading…

© 2012   Created by Amy Stephen.

Badges  |  Report an Issue  |  Terms of Service