http://security.moodle.org/
Visited security.moodle.org. Don't seem to have access. The contact page requests details of "the problem." I don't have a problem, just need to know if I'm about to have one.
This one's already out there, so I'm not posting an original security exploit. It's simply a web link.
--Brian
I spotted the link after as soon as the page loaded and then clicked on the HUGE Report a security issue text and was taken to a web form. I admit I didn't submit anything as I have nothing to report. If it didn't work for you then perhaps you should send a message to martin or one of the team or post it on the bug tracker to let them know the form aint working.
You may not have posted something new but what you have done is promoted the (potential) exploit further and exploits become much more problematic when more people know about them.
--Brian
However, a) promoting FUD and b) alerting the entirety of the people who read General Developer Forum of an exploit isn't the most productive way to alert the moodle developers of a potential problem.
Moodle doesn't have a closed door security policy. Security problems are fixed and are in the changelog.
Instead of attacking the messenger, maybe a little focus on the problem at hand would be more productive...
> "promoting FUD."
Sure it does. we don't need to panic the general moodle populace, most of whom don't read exploit announcements, until we have evaluated the problem to see if it's actually a real concern.
> Instead of attacking the messenger, maybe a little focus on the
> problem at hand would be more productive...
Of course. I am no security expert and as you see, Petr has already posted a patch. As Eloy points out, only a few hours after you alerted us to it.
We were merely trying to point out that there's a place to report these things and it's security.moodle.org. I'm sure everyone is very appreciative that you took the time to alert us to it. Thanks!
Perhaps I was a little snarky in my post, I apologise. But it grates that people might think that we would brush the problem under the carpet and hope it goes away, as Moodle is very security aware and active in trying to fix problems in an open and positive way.
Today we discovered a potentially serious problem with a hidden utility script in Moodle that could allow a malicious user to delete ALL course files.
Hardly fingers on lips.
No -- not security through obscurity. We'll leave that technique for others.
security.m.o gives bit of lead time for the core developers to look at security concerns (real or perceived), and a space to discuss and plan the best way to fix the real ones, and the best way to educate on the perceive ones.
We are looking at it.
register_globals = on
magic_quotes_gpc = off
I am working on a permanent fix now.
In any case I would recommend everybody to disable register_globals.
Using my fingers to put my cigar (with its obscure smoke) between my lips... (I've to leave that bad habit soon).
Problems might be with some 3rd party extensions and mods if they are setting any variables before the inclusion of config.php... (edit: it does break mysql admin)
I would be glad if anybody suggested any better solution
Instructions: insert following code right at the beginning of lib/setup.php
function ini_get_bool2($ini_get_arg) {
$temp = ini_get($ini_get_arg); if ($temp == '1' or strtolower($temp) == 'on') {
return true; } return false; } function unregister_globals2() {
$REQUEST = $_REQUEST; $GET = $_GET; $POST = $_POST; $COOKIE = $_COOKIE; if (isset ( $_SESSION )) {
$SESSION = $_SESSION; } $FILES = $_FILES; $ENV = $_ENV; $SERVER = $_SERVER; foreach ($GLOBALS as $key => $value) {
if ( $key != 'GLOBALS' && $key != 'CFG' && $key != 'nomoodlecookie'
&& $key != 'lifetime' && $key != 'starttime') { //hacks for themes and cron unset ( $GLOBALS [ $key ] ); } } $_REQUEST = $REQUEST; $_GET = $GET; $_POST = $POST; $_COOKIE = $COOKIE; if (isset ( $SESSION )) {
$_SESSION = $SESSION; } $_FILES = $FILES; $_ENV = $ENV; $_SERVER = $SERVER; } if (!ini_get_bool2('magic_quotes_gpc') && ini_get_bool2('register_globals')) {
unregister_globals2(); }
register_globals=off
magic_quotes_gpc=on
PHP settings can be changed by editing php.ini or .htaccess file in your Moodle directory.
skodak
It ist really not the right place for such a discussion. Every thing has a place, and here i think the most users in this thread go confirm, it is not a discussion for every ones eyes.
@Skodak
What u think do Moodleusers they have no serveraccess (shared hosting), or they have run beside moodle another cms and this one need register_globals on. Some serverconfiguration did not allow .htacess
What u can learn from this discussion is, the moodleusers need information, at the right time and on the right place. Thats all i think!
Bye Andy
register_globals=on is evil. IMO no hosting company should enforce it. Please note that it is easy to emulate register_globals=on in PHP, so even old code can be made functional without much trouble.
skodak
Thanks!
Forgive me if I'm being dense here, but it this a 1.6 issue only, or does this impact 1.5 users? Thanks.
Steve
- Are you affected? Check http://yoursite/admin/phpinfo.php.
- Protection is easy - disable register_globals!
The patch above could be useful if you can not change setting in php.ini or .htaccess, but I doubt any hosting company would have such a weird configuration and would not want to change it.
Back to the reporting of security bugs. I noticed the first report at security.moodle.org around 11:30 PM just when I was shutting down my computer in order to go to bed (thanks to reporters Miles Berry and Iñaki Arenaza Nuño!!!!!!) .
Brian posted here at 10:20 PM. I did not see it, I do not read messages from forums every hour, I guest I would notice it now.
Please next time report undisclosed problems only at security.moodle.org.
Before talking about public exploits please report them at least at security.moodle.org.
I have to go earn some money now, I will continue working on this later today in my free time
skodak
A personal thanks!
--Brian
The argument works both ways...while core developers are discussing, users are left in the dark. You believe in delayed disclosure, I believe in full disclosure (except in the case of a non-published exploit). We'll just have to agree to disagree on this one...
--Brian
Agreed on that we'll have to disagree.
Now, given that we are trying to help you and all the Moodle community... would you mind helping us? Report it first to security.m.o -- as you can imagine, we monitor that more closely than General Developer Forum (which is naturally "low urgency").
And then, if you really believe in full disclosure, post it to the community as well. Be aware, however, that most of the "security advisories" out there are quite bogus... the 'security experts' pushing them out are marketing themselves on top of people's fears, and will happily forget to mention that it only affects users with X, Y and Z settings.
That's why we call that FUD, although it's a different kind of FUD than your usual product vs product FUD. It's more like the antivirus industry scaremongering.
So... it's easy to overreact and claim that the world is about to end. Keep in mind that bugtraq is 80% marketing, 20% real stuff (I have followed bugtraq for years, only unsub'd about 2 years ago.) And that you can really damage the Moodle.org community just by echoing their FUD unchecked.
And that's exactly what they want!
security.m.o has an amazing turnaround record, mostly thanks to Skodak. It's much better to break the news an hour or two later (I'm sure you can cope with that) having double checked them, and publicizing them together with a fix or workaround. Hey, the fist thing to figure out is whether the exploit for real even. Many bugtraq reports are based on misconfiguring apache or php badly, and then claiming that a web app has a problem.
Which is the very reason why I limited my query to a forum with a limited audience. A query is not FUD, especially when a developer posts such a query on a developer forum. It's simply a query.
The responses in this thread indicate that there are several misconceptions about security and about how application security should be handled. For those who really believe I've done some sort of disservice by posting a question about a published exploit, I'd suggest taking a page from the OpenBSD (widely recognized as an extremely secure OS) security philosophy, and do some real-world research to debunk some of the misguided beliefs you hold:
Like many readers of the BUGTRAQ mailing list, we believe in full disclosure of security problems. In the operating system arena, we were probably the first to embrace the concept. Many vendors, even of free software, still try to hide issues from their users.
Security information moves very fast in cracker circles. On the other
hand, our experience is that coding and releasing of proper security
fixes typically requires about an hour of work -- very fast fix
turnaround is possible. Thus we think that full disclosure helps the
people who really care about security. (http://www.openbsd.org/security.html)
--Brian
I don't get the impression anyone here is suggesting that the security flaws be hidden. I am not worried about FUD. Just that information about how to exploit them not be spread without an accompanying solution. As I said, I'm not a developer, but a user. I worry more if my system is actually insecure, NOT if it is just perceived to be insecure.
What you did do was make it easy for anyone else other than the admins to find a way to exploit Moodle sites. You have no way of knowing that a hacker wouldn't find your link and use it on a particular site before its admin was even aware of the problem. If my php settings hadn't been secure already, I would be mighty angry at you right now for having put my site at risk in this manner.
There is a more effective and less dangerous mechanism in place to notify the people who need to know about these problems. A Moodle admin signs up for notifications of such issues by email when they register their Moodle site. If you had reported this to the security course, I'm sure the developers would have fixed it just as quickly and notified only the people who we would want (and who need) to know about it-the admins-by email about a patch.
And to whoever has teacher rights in this forum, don't you think it is high time to delete the link to the exploit in Brian's original post? There are probably many admins out there totally unaware of this problem and by leaving this link their sites are put at increased risk to some hacker finding this.
Which is exactly the reason why I posted here: Minimum exposure to the problem without the appearance of spreading FUD, as a previous poster so succinctly put it.
Your assumption is incorrect. I posted this on the developer's forum for a very good reason: The audience for this forum would be, in fact, the primary source of information about the issue.
What you did do was make it easy for anyone else other than the admins to find a way to exploit Moodle sites.
If you really believe this, then you also need to take your argument up with the BUGTRAQ maintainers as well, seeing as how this exploit was published there. Do you believe BUGTRAQ does a disservice to the community by posting exploits? If not, then you're being hypocritical.
Your argument is non-sensical. Let's extend your line of argument by saying "What open source does, by exposing the underlying code, is to make it easy for anyone else other than the admins to find a way to exploit Moodle sites." Just as non-sensical. The myth of "security through obscurity" has long been debunked. You might want to do a bit of research on this topic before making such assertions.
You also seem to have missed a very important point: The exploit was already published. In fact, it was published in at least two forums known for showcasing (for good or bad -- doesn't matter) web-based exploits. Don't you think the script kiddies already know about these sites? Rest assured that they do.
Had this been an unpublished exploit, then your argument might hold some water. In fact, had this been an unpublished exploit, I would not have posted it in a public forum. Hypocritical? Hardly. They are two very different animals.
You have no way of knowing that a hacker wouldn't find your link and use it on a particular site before its admin was even aware of the problem.
Again, the exploit was already published. I don't need to know whether or not a hacker (actually, we're more concerned about the crackers here) would find my link, because the exploit was already out there.
If my php settings hadn't been secure already, I would be mighty angry at you right now for having put my site at risk in this manner.
Then your anger would have been demonstrably misdirected, because it wasn't me that cracked your site. In fact, anger in this situation is just wasted energy: There is no application that is secure from all attacks, and your energy would be better directed at ensuring an up-to-date, secure site.
There is a more effective and less dangerous mechanism in place to notify the people who need to know about these problems. A Moodle admin signs up for notifications of such issues by email when they register their Moodle site. If you had reported this to the security course, I'm sure the developers would have fixed it just as quickly and notified only the people who we would want (and who need) to know about it-the admins-by email about a patch.
You make the ungrounded assumption that in some way the question I posed was somehow "dangerous." You also make the assumption that every Moodle admin has registered their site (the last time I checked, registration was optional). Both assumptions are false. (In fact, I've registered my site, and have never received a security alert. Never.)
And to whoever has teacher rights in this forum, don't you think it is high time to delete the link to the exploit in Brian's original post? There are probably many admins out there totally unaware of this problem and by leaving this link their sites are put at increased risk to some hacker finding this.
So by obscuring the problem, it goes away? Cover your eyes, and the monster is gone? You still seem to miss the point: The problem is here and now. Censoring my post won't make the problem go away, it won't make your site or anyone else's site more secure, and it won't help the admins who are "totally unaware" of this problem.
Your diatribe is misdirected and off-base. I don't know your background, but I'd suggest some serious reading before making wild (and false) assertions.
--Brian
The practical and social aspects of vulnerability disclosures
None of the developers suggested that you should not have posted news of this exploit at all. We merely offered you a better (in my personal view, at least) alternative: submit it over at security.moodle.org instead of the general developer forum.
Of the two arguments for this, one (less exposure to potential hackers) is perhaps not too valid because, as you said, these people would have already read about it on Bugtraq. However, you might possibly bring this to the attention of a hacker faster this way and in good faith, I cannot see how this (perhaps negligible) drawback would be offset.
The second and most serious argument though, is that the people who can and want to fix this vulnerability ASAP read security.moodle.org more often than the general developer forum. Hats off to Petr Skoda and the other developers for the tireless work they are doing to keep Moodle secure, including reading the security discussions and posting patches at hours when most people are soundly asleep. They do not do that with this forum.
Finally, a few "social extensions" to this disclosure: by posting a news item such as this, a certain percentage of Moodle users will be seriously alarmed and worried. Most of them needlessly, as this exploit only works on a very uncommon PHP configuration set. And most of them because of your posting, since they don't read Bugtraq.
To better see my point, please compare the two following hypothetical statements:
A: "A critical vulnerability exists in all known versions of Moodle which allows a remote attacker to blah blah blah"
B: "A critical vulnerability has been found that affects servers running Moodle that have a certain combination of configuration settings. If you have such a server and have these settings: ... then please take the following steps immediately to secure your site"
Emphasis mine. See the difference? Nicole would definitely sleep better if B was said instead of A. And for B to be said, we need to research the problem first. Which means that the post alerting us to the vulnerability cannot be A, since then the goal of saying B is defeated. Maybe being considerate to people like Nicole isn't first on the agenda of a security researcher, but why not do it if it's a free bonus?
To sum it up: I 'm not telling you that you were spreading FUD by posting this here; but next time, if your intention really is to see the vulnerability fixed as soon as possible, please post at security.moodle.org instead. As a bonus, you will also have fewer people sleeping uncomfortably that night.
Cheers,
Jon
[edit] PS: I see now that Martin Langhoff has said practically the same things in other words a few pages above. Great minds think alike?
Re: The practical and social aspects of vulnerability disclosures
I also wanted to mention that it is important to note that full disclosure is quite controversial. I definitely don't want to replay the (otherwise really interesting) debate on full disclosure. It's been argued before, and it's still controversial. As such it pays to be respectful of both sides, and understand that both sides have good points. Wikipedia has a brief writeup and links to very good papers supporting both sides: http://en.wikipedia.org/wiki/Full_disclosure
At any rate, FD isn't the ideal approach for all the projects or software products. OpenBSD fits a particular niche where hyper-aggressive disclosure is what's expected, they welcome and encourage that. If you want to know what their userbase likes, run OpenBSD as your desktop for a week
Given that of both sides of the debate have strong points, informed people often report security bugs privately to developers, giving them a chance to study the issue, and, if it's a real bug that needs a fix, announce it together with a patch or workaround. And if the developer/vendor doesn't respond you can resort to full disclosure.
Re: The practical and social aspects of vulnerability disclosures
Re: The practical and social aspects of vulnerability disclosures
I am grateful to Brian too. And of course still more to Petra Skodak for fixing it.
We do not seem to have reached closure here. Where will we, should we exchange security reports in future?
It is nice to have a forum where security issues can be report but some people would rather be part of that forum.
The disclose / not disclose issue thus partly depends upon whether one sees the community as being divided into "developers" and "the general moodle populace."
Whether there is a select group of developers that solve the security "problems" held by the rank and fine, or rather a more homogenuis community of users that share issues, which they see as both problematic and as things to solve simulaneously.
Incidentally, Brian developed one of the most important parts of my moodle.
Thank you Brian and Skodak
Timothy
Re: The practical and social aspects of vulnerability disclosures
If you have a security concern, or have spotted something that looks like an exploit against Moodle, please report it via http://security.moodle.org . We usually have a fantastic turnaround time (mostly thanks to Skodak), and we'll have figured out whether it is for real, and what fixes and/or workarounds are needed, gotten back to you and made an announcement.
Posting things to security.moodle.org ensures that it gets to the eyes of the security team quickly (not everybody follows general developer forom closely). It also makes the work of the security team much easier, and prevents needless risks and panics.
Please, do this even if the vulnerability has already been posted somewhere on the internet. For real vulnerabilities, the actual risks during the exposure window depend a lot on how the information spreads. Ideally, it should spread fast among the developers who can help you, and we should not help its spread in, ahem, other communities
If you feel security.moodle.org does not address your concerns in a timely fashion, and trying to contact the core developers doesn't work (our email addresses are very public!), you can opt to discuss it in the forums. This is always risky -- if you find yourself in the unenviable position of having to discuss this in an open forum... be careful with what you post.
This approach is generally known as giving the 'vendor' (in this case the Moodle.org dev community) advance warning, and is what most people in the software and network security consider to be best practice.
For the record, the report to security.moodle.org was not made by Brian but by Miles Berry.
Re: The practical and social aspects of vulnerability disclosures
Thank you very much for putting your point of view very clearly.
The only thing I am not sure about are the itallics in your last line. I guess that did not refer to my post. I did not mean to suggest that Brian reported the vulnerability to your security forum.
I guess you know that when I wrote
> Incidentally, Brian developed one of the most important parts of my moodle.
I was refering to the fact that Brian Koontz designed and developed the course date managert block that I use very extensively. As such, he might be called a devoloper, and as such he might be, or might expect to be privy to the latest in security issue information.
I would like to reiterate that there is more than one way of seeing the Moodle community as being:
A) one with "vendor" (developers) that help, and the "general populace" of "users" that are helped
or
B) as being more homogenius wherein there are many people are to some extents, both users and developers, that to varying degrees, help and are helped.
The extent one exposes either (A) or (B) will also be a question of degree. And as such there is bound to be a lot of different takes on the issue. The more that one see things in terms of (A) above, the greater the advantages of mitigating full-disclosure, the greater that one sees the community in terms of (B) then the greater the chance that one would prefer full-disclosure.
Your reply seems to lean towards stance (A), which may be the truth, or largely the truth. And I may be mistaken in my interpretation. I merely wish to point out that there are other (possibly mistaken) views upon the situation.
Cheers,
Tim
Re: The practical and social aspects of vulnerability disclosures
Tim,
I like the Moodle community particularly because it has a lot of variety of skills, interests and goals. Access to information is very homogeneous and open, and that's something that I like, and want to encourage.
It's always a matter of degree, but I lean towards B myself And still, full disclosure is probably not what you want -- there's a lot of debate on the matter, and I don't want to re-hash it here, feel free to follow the Wikipedia links. The debate has settled on a range of takes on 'responsible disclosure' -- and in an open source project, where there's no single vendor to speak of, you can argue that it is a matter of trust.
If you are running Moodle, you have at least some trust in the core team (and of course you can verify it by auditing code, but trust is the social mechanism to avoid that enormously costly endeavour). So hopefully it makes sense to trust them to have a go at dealing with the problem. Of course, if they drop the ball...
If nothing else, security.moodle.org is a means of making sure the core team jumps on it immediately. I am rather lazy reading general developer forum myself.
As to whether Brian is one of the core developers, I don't know really. He's got a space in /contrib and that's the best way to get into it
Re: The practical and social aspects of vulnerability disclosures
I think that you seemed to have gotten to the point.
The issue is really that the the developers, the ones who are going to fix the problems, are asking for cooperation in knowing about the problem first through security.moodle.org. Simple enough.
As I have trusted the Security bunch to take care of problems up to now, I see no reason not to trust them with this request.
Why the resistance?
Fuzzy, Non-dual, Advaita, Communities and Security Forums
Dear Martin
> It's always a matter of degree, but I lean towards B myself.
> And still, full disclosure is probably not what you want
I agree with you .
BTW I came to this thread because I was looking for the url of the security forum. Being incapable of curing security issues myself I am more than happy to have a "post your problems here" box. (Thanks again).
But bearing in mind the nature of the community, vectors such such as those between "core"/perifery, "trusted"/un-trusted, helpers/"helped", "developer"/"user", "vendor"/"user", "general-populace"/Penny*, should be of a level of fuzziness, non-duality, advaita to reflects the homogeneity that we agree exists.
Concretely, perhaps you might consider extending membership of the security forum to a wider subset of Moodle users?
Tim
*I am joking, and see Penny as definately 'non-general-populace'.
Re: The practical and social aspects of vulnerability disclosures
Instead, each of you who took such great offense to my posting should instead consider the ramifications of trying to force the Moodle community to view Moodle through rose-colored glasses. "Nicole" might very well be quite upset should she learn that her Moodle installation was hacked, with not one mention of said threat having yet to appear in the Moodle forums.
So here we all are, in one big impasse. I believe I did nothing wrong. Some of you believe I'm guilty of fear-mongering and hysteria. So in the spirit of compromise, I'd like to offer a few suggestions of my own in an effort to break the impasse:
1. Create a forum on moodle.org dedicated to security alerts. Don't hide it away behind its own domain, hoping that those with the "need to know" are the only ones who happen upon it. It's my belief that every person who is involved in working with Moodle has a "need to know."
2. Stop jumping up and down if a security exploit that has already made the rounds on the Internet is brought up for discussion. Discussion is good. Don't insult the collective intelligence of Moodlers by trying to control what they see and hear about Moodle. If there's an exploit that's already been disclosed, better to discuss it here than have people learn about it the hard way.
3. Prominently post the link to report security issues on moodle.org. Acting like Moodle has no security issues is just setting up Moodle users who might not know better for a bigger fall. It all gives the appearance of being proactive about security, rather than reactive and secretive.
--Brian
Re: The practical and social aspects of vulnerability disclosures
Whether the code is out there already or not is not the point. The more places it is available, the more likely it is to be found. By posting a link to it here, you ensure that it will get into Google's database faster. You ensure that it will have a higher ranking in Google's search engine. There are small scale hackers out there who may not know all of the sites to get such codes from yet.
Some sensible reading is here. Especially the section on Full Disclosure and Resposibilty.
Re: The practical and social aspects of vulnerability disclosures
At any rate, no one is speaking for you, least of all me. You and others are the ones who made the decision to make a federal case out of this. You support your arguments with false assumptions and assertions that simply are not backed up by reliable evidence. You state that "by posting a link to it here, you ensure that it will get into Google's database faster." Yet you in no way attempt to substantiate this claim to be true. You state "[I] ensure that it will have a higher ranking in Google's search engine." Pardon me? What proof do you have that Moodle's forums somehow rank higher than, say, Bugtraq postings?
I'll say it again: Your anger is misdirected. If anything, please read the link you yourself posted. Please read it carefully. I think you'll find, if you really reflect on the issue, that Schneier's position about full disclosure is in line with my original post that started this thread.
If there is any FUD being spread about, it's irresponsible assertions like the ones you have made which will cause people to think twice about discussing security issues (whether here or elsewhere). Stifling open discussion of security concerns is a far greater crime than posting an exploit that has already been released "in the wild."
--Brian
Re: The practical and social aspects of vulnerability disclosures
If anything, please read the link you yourself posted. Please read it carefully. I think you'll find, if you really reflect on the issue, that Schneier's position about full disclosure is in line with my original post that started this thread.
Hmmm. I think you are reading Schneier with some preconceptions. As I mentioned earlier, the FD debate is complex, deep and mature. As such, any interesting and well explained position will support both sides: disclosure and non-disclosure. So yes, Bruce supports Nicole, and he supports your position too. But don't feel a winner just yet. He actually ends up arguing that the only sane thing to do is "responsible disclosure" (he doesn't use that term, though).
That's why it's an interesting debate, one that you have to read with both eyes open.
If you read Bruce's discussions on the window if exposure, it depends a lot on the flow of information -- who gets it and when. That is why we definitely prefer to get the information early in the hands of the developers who you trust and can help you -- even if it's been published somewhere. And then get out of their hair while they figure out whether the thread is real and provide a fix if needed.
That's all -- plain and simple.
Everything else is noise and gets in the way.
Re: The practical and social aspects of vulnerability disclosures
It's too bad you and your inner circle view open discussion about Moodle security as "noise." It's on par with the extremely patronizing attitude that's been on display here, that I've been an errant little schoolboy who needs to be taken to task for speaking my mind in class.
You have effectively insulted not only me, but also that segment of the Moodle community with the technical background capable of sustaining open dialog about security issues. You and your group have certainly generated enough static in this discussion to have effectively masked any intelligent conversation about what type of security policies best suit the various interests of the Moodle community. The party line has been made crystal clear to me and others: We are to blindly put our faith and trust in your hands, and question nothing.
And that's a real shame, because it's obvious that all of us can learn quite a bit from one another.
Re: The practical and social aspects of vulnerability disclosures
You have effectively insulted not only me, but also that segment of the Moodle community with the technical background capable of sustaining open dialog about security issues.
Patronizing? Reread the way you responded to me...
You can engage in all of the dialog you want about the merits and drawbacks of full disclosure and what is done at other open source projects, and whether the developers should be patting eachother on the back or at eachother's throats. But at the end of the day, this shouldn't be about debating theory. What really is important to the actual users and the viability of Moodle itself is that our Moodle installations are secure. Frankly, I don't care who wins the debate in this thread or if anyone wins at all, I just want my site to be secure. Programmers and developers should serve their customers' needs, not their own egos and need to be right. And as a customer, I feel that the process that the developers have outlined for submitting reports on security matters is what serves us customers best.
Re: The practical and social aspects of vulnerability disclosures
Disclosing the vulnerability in some forum (moodle's or other) where developers in charge of moodle's security are not going to find it (because you don't know if they read it or not) isn't going to buy you anything useful, specially given that the exploit is already out there.
I'm all for full disclosure, but I'm even more for responsible full disclosure (as described in the URL linked to by N Hansen).
Saludos. Iñaki.
P.S. I agree with you that security.moodle.org is not widely known, and is not mentioned in the front page of moodle.org. I think this should be "fixed".
Re: The practical and social aspects of vulnerability disclosures
I read this post with great interest. Security is a great issue in todays arena.
I would have to give to Kudos to Martin D for replying to my email with in hours of my ticket asking for help with this possible issue.
I wish I could get that kind of service with all providers...
I would have to say that the bigger Moodle gets the larger a target they become for hackers...
Kudos to Martin, Moodle and all of YOU who make this constructivist conversation possible.
Rob
Martin has already thanked everyone for reporting the "bug":
http://security.moodle.org/mod/forum/discuss.php?d=186
(and he has lamented that he wasn't told directly by the "bug's discoverer")
I'm sure we all have learned a lot from this thread, but can we relax and get back to Moodling?
Thanks to all for helping make this software and community the best on the planet
If for some reason this existing process seems not to be working then please feel free to pursue other means of getting answers.