Response about SA-CONTRIB-2012-036

mariomaric's picture

Hi everybody!

I just want to make you aware of discussion going on about recently SA-CONTRIB-2012-036 @

It would be great if you could provide your point of view, if you find that is necessary.

Please don't take this as disrespect or judging your work - I just don't see appropriate to create picture about Drupal security team as Drupal overlords. :/



Please respond

Kars-T's picture


as I really don't understand this and Eugen is a friend of mine it would be great if you could give more information on this.

@Kars-T - I'm not sure what

greggles's picture

@Kars-T - I'm not sure what we should say?

I just tried out the module myself. There's no denying the fact that the module has a CSRF vulnerability. It creates locks that an admin can unlock, but it's possible to use CSRF to trick someone into unlocking a node using a short-link or an image like <img src="http://localhost:8082/admin/content/node/content_lock/release/9" >

There is no harm you can

AndreU's picture

There is no harm you can cause by unlocking nodes, is there?

Is this an Acquia motivated issue?

@AndreU, I was the security

mlhess's picture


I was the security team member who coordinated this SA. I do not work for Acquia. The module was flagged as unsupported because the module maintainer did not respond to emails on it asking for details on it.

I don't know what you mean by unlocking nodes.

@mlhess, "content lock"

AndreU's picture


"content lock" module is about locking and unlocking nodes. Also greggles wrote about "...CSRF to trick someone into unlocking a node..."

As far as I know the owner responded to the issue but has a but the SA resist on classify this as a security issue. That´s why I ask: "There is no harm you can cause by unlocking nodes, is there?"

Guess none of the SA team member has an answer to this, otherwise there would be not so much discussion.

"There is no harm you can

greggles's picture

"There is no harm you can cause by unlocking nodes, is there?"

If there is no harm then why does the module exist?

To ease collaboration on

AndreU's picture

To ease collaboration on platforms with lots users so that they not unintentionally edit content which is already edited by someone else. It does not make sense to trick someone to unlock nodes. You gain nothing beside less coordinated work with other users. You can also break locks with content_lock inbuilt functionality if you like - no need to trick. Its all about collaboration.


Michelle's picture

Sure you gain something: confusion and more difficulty collaborating. For a prankster, that's a motivation. This may not be a lose all your data type of issue but it's still an issue that removes the added functionality. Users install the module to get something and the exploit takes that something away.

@Michelle, it´s hard to find

AndreU's picture

@Michelle, it´s hard to find arguments for an security issues, or how can your comment be interpreted? Exploid, prankster, lost functionality, confusion, difficulty collaboration - big words without use. Anyway, keep spreading your emotions all over d.o. and ignore the facts why people using content_lock.


Michelle's picture

I really don't know how to respond to someone who thinks the only facts are their facts and no one is allowed to have emotions around here. shrug I'm out of this anyway. I've said my bit.

Michelles comment had a lot

fuzzy76's picture

Michelles comment had a lot of arguments, while your reply had none. Your point being?

@fuzzy76: please help

AndreU's picture

@fuzzy76: please help yourself by reading the whole thread.

Meanwhile Eugen posted a comment about an existing CSRF attack on Drupal core similar to the content_lock issue, which may help you understanding the issue.

No response's picture

The owner did not reply to the mails he received from the security team. He only replied after we released the SA.


Dave Reid's picture

THIS is the important fact here.

Senior Drupal Developer for Lullabot | | @davereid

Not about security

AndreU's picture

Yes, its not about security, its only about rules and procedures.

If the SA Team would be serious about security and making no exceptions, then they also have to classify the "Logout CSRF" exploit in Drupal core as a critical security issue. This exploit exists in all Drupal releases and can be used as an CSRF attack at any time on every Drupal instance.

Please talk to me @drupalcon

Kars-T's picture

Hi people I don't know why this is going so much out of hand. Yesterday Greg had to leave before we could talk and I hope we can do this today. And Michelle as I stated in some other posts I'd like to speak to you as well.

I can assure all of you that this has no deep complex motivation and is just misscommunication that we can work out.

Kars-T and I talked a bit

greggles's picture

Kars-T and I talked a bit today and I think reached a good resolution (at least for the two of us, if not the issue as a whole).

I remain hopeful that EugenMayer will continue to work on projects on

Yay! :)

mariomaric's picture

This is why I love so much Drupal (community)!!! ;)

Regarding other posts: I personally don't find constructive taking sides and reacting emotionally in this kind of conflict - it's hard to fight fire with fire. :/

Why me?

Michelle's picture

I don't have a dog in this show... I just don't like seeing people I care about get slammed. I don't use the module and don't personally care what anyone does with it. But making the security team out to be some secret police that go around kicking people off their projects pisses me off. If you folks have made up, then that's just fine.

Last on on this for me

EugenMayer's picture

I'll keep it as short as possible, promised:

<img src="">
<img src="">
<img src="">
<img src="">
img src=""

You just got logged out of drupal, groups and and even drupalcon denver.

This is an CSRF attack on every drupal installation, including You get logged out.

- the attacker gets no rights, permission, private informations or data
- the attacker can do exactly the same things on he used to
- nothing - you can log in and keep on working
the only motivation the attacker could have is: "confusion and more difficulty collaborating. For a prankster, that's a motivation.".

The Drupal core session manager is supposed to protect the users-session but he obviously does not. So core is responsible to setup the session and ensure it does not get manipulated or stolen by others.

Why this never got fixed
- because nobody could care less, due to risk is zero nothing. Its nonsense

It can be considered a bug, yes, maybe it should. But a sec issue - no way.

Absolutely all of the points above apply to content_lock. My last comment on this, so i shortly straight things up:
1. Iam 100% ok with locking down the module due i did not respond (i wrote this ten times). You can now freaking stop jumping on this point to have ANY arguments at all.
2. Iam not ok that this even removed SCM access ( accidentally, as greggles told me )

The reason i will not distribute any module on anymore is neither 1 or 2, its because i do not trust in the policy of the SA how they classify security (or not) issues and potentially act hard upon this decisions.
Just one example: DRUPAL-SA-CONTRIB-2012-042 - this issue is non critical, while absolutely serious risk exists. To compare, the content_lock issue is classified "crucial".

I did not respond to the issue because of lack of time. I saw it, saw it has is just very easy to judge on and left it to the SA team as iam absolutely sure the guys have more then enough skills to understand the core of the issue. But in this case, i bet it was not really investigated out of the same reasons i had, no time. The difference is, you act strong upon those not very well backed-off "facts". I repeat, iam fine with locking down when i did not respond, thats just a side-note.

I will not allow the community, which the SA is a part of, to lock me out of my work i given the community for free / without any expectations. If that ever should happen, it must have serious reasons based on serious facts. And in regards of content_lock, there is absolutely nothing applying to serious, except serious emotions (at least on my side and i suggest some others might be involved the same way).

oh, why you corrected my CSRF

EugenMayer's picture

oh, why you corrected my CSRF attack by placing it in code brackets? I actually wanted to show people that it is possible here and right now. So why you did that? Didnt like that?

Thats the way you deal with "security" in this point - you edit my post to remove it? Anyway, why iam even commenting on that

Paradigm shift...

mariomaric's picture

IMHO this issue should not be anymore about code & security but about acceptance, forgiveness, flexibility, openness and learning.

What's done is done, SA-CONTRIB-2012-036 is out, and I personally don't want that Drupal security team change their minds - that would mean inconsistency, and I expect from them to be serious in what they voluntarily do and to do that with great responsibility (which is de facto foundation of the security team, IMO).

So, if we want to learn from this than we could create some procedure / policy that will be applied when there is minor security issue in module e.g. stating that in module page - which will be moved only if maintainer repair security issue.

We are all here on the same side, this is something that is slipping from our minds, i guess.. :/

And also, I understand that security / best practice standards are really important, but IMHO they shouldn't be more important than people i.e. community.

create some procedure /

greggles's picture

create some procedure / policy that will be applied when there is minor security issue in module e.g. stating that in module page - which will be moved only if maintainer repair security issue.

It is always the case that the module maintainer can fix the issue and get their project back - whether the issue is extremely-critical or non-critical. Our policies are all inside of this book and if you want to propose changes to the policies we can definitely discuss them.


mariomaric's picture

Well, I read all nodes in the book, and yes, everything is A-OK.

You can write awesome policy, but at the end it all depends on interaction between people, and we are humans, we made mistakes, or, in this case communicate too late.

According to mistake made by security team member, maybe you could add one sentence at the end of Issues with contributed modules part. Something like: "When module is marked abandoned, until new maintainer is found, previous maintainer(s) will have git access."
Or there is already policy for that situation?

I agree with

izmeez's picture

I agree with @mariomaric,

this issue is ... about acceptance, forgiveness, flexibility, openness and learning.

I hope everyone can find a way. Thanks.


Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week