Think there's a security problem in your module? Here's what to do.
Perhaps the docs are too detailed, confusing, hard to find, or obscure. I'd like to try in short, plain english to explain what to do when you think you've found a security problem in your module: a) Either you think you find a potential security problem in your module or a user reports a vulnerability to you. b) You *immediately* send email to security@drupal.org about it to let us know. c) You try to analyze the vulnerability to the best of your abilities, and if possible produce a patch that fixes it. d) DO NOT COMMIT YOUR PATCH YET. e) DO NOT MAKE A RELEASE YET. f) DO NOT MARK YOUR RELEASE AS A "SECURITY UPDATE" YET. g) Send your patch to security@drupal.org. h) Wait for the security team to reply. i) Do what the security team advises you to do. j) If/when the security team thinks your vulnerability is real, the fix is complete, and a security announcement (SA) is ready to go out, we'll tell you. k) Only once an SA is ready for your vulnerability and the security team is ready to coordinate a release, THEN (and only then) do you commit your patch to all relevant branches, tag new releases, create release nodes, and mark them as "Security update" releases. l) The security team can then publish your release nodes (which doesn't happen automatically if they're flagged as a "Security update") and send out the SA, at which point your users will know they need to upgrade (both via the security announcement email lists and RSS feeds, and via the update_status module). Make sense? Do you really understand the process? Should I explain why any of these steps are like this? What else could be done, either via docs or project* UI, to make this clear? Relevant issue: http://drupal.org/node/210497 "add extra validation to release node form for security update releases" Relevant handbook docs: http://drupal.org/security-team Thanks, -Derek (dww)
I get why you have to wait to create a security node. But why do you have to wait to commit code? I assume there is a point I am missing because we do use a VERSION control system. On 1/16/08, Derek Wright <drupal@dwwright.net> wrote:
Perhaps the docs are too detailed, confusing, hard to find, or obscure. I'd like to try in short, plain english to explain what to do when you think you've found a security problem in your module:
a) Either you think you find a potential security problem in your module or a user reports a vulnerability to you.
b) You *immediately* send email to security@drupal.org about it to let us know.
c) You try to analyze the vulnerability to the best of your abilities, and if possible produce a patch that fixes it.
d) DO NOT COMMIT YOUR PATCH YET.
e) DO NOT MAKE A RELEASE YET.
f) DO NOT MARK YOUR RELEASE AS A "SECURITY UPDATE" YET.
g) Send your patch to security@drupal.org.
h) Wait for the security team to reply.
i) Do what the security team advises you to do.
j) If/when the security team thinks your vulnerability is real, the fix is complete, and a security announcement (SA) is ready to go out, we'll tell you.
k) Only once an SA is ready for your vulnerability and the security team is ready to coordinate a release, THEN (and only then) do you commit your patch to all relevant branches, tag new releases, create release nodes, and mark them as "Security update" releases.
l) The security team can then publish your release nodes (which doesn't happen automatically if they're flagged as a "Security update") and send out the SA, at which point your users will know they need to upgrade (both via the security announcement email lists and RSS feeds, and via the update_status module).
Make sense? Do you really understand the process? Should I explain why any of these steps are like this? What else could be done, either via docs or project* UI, to make this clear?
Relevant issue: http://drupal.org/node/210497 "add extra validation to release node form for security update releases"
Relevant handbook docs: http://drupal.org/security-team
Thanks, -Derek (dww)
-- Alan Doucette Koi Technology, LLC www.KoiTech.net
As soon as you commit code you have publicly published the vulnerability and put non-upgraded sites at risk. On Jan 15, 2008 11:58 PM, DragonWize <dragonwize@gmail.com> wrote:
I get why you have to wait to create a security node. But why do you have to wait to commit code? I assume there is a point I am missing because we do use a VERSION control system.
On 1/16/08, Derek Wright <drupal@dwwright.net> wrote:
Perhaps the docs are too detailed, confusing, hard to find, or obscure. I'd like to try in short, plain english to explain what to do when you think you've found a security problem in your module:
a) Either you think you find a potential security problem in your module or a user reports a vulnerability to you.
b) You *immediately* send email to security@drupal.org about it to let us know.
c) You try to analyze the vulnerability to the best of your abilities, and if possible produce a patch that fixes it.
d) DO NOT COMMIT YOUR PATCH YET.
e) DO NOT MAKE A RELEASE YET.
f) DO NOT MARK YOUR RELEASE AS A "SECURITY UPDATE" YET.
g) Send your patch to security@drupal.org.
h) Wait for the security team to reply.
i) Do what the security team advises you to do.
j) If/when the security team thinks your vulnerability is real, the fix is complete, and a security announcement (SA) is ready to go out, we'll tell you.
k) Only once an SA is ready for your vulnerability and the security team is ready to coordinate a release, THEN (and only then) do you commit your patch to all relevant branches, tag new releases, create release nodes, and mark them as "Security update" releases.
l) The security team can then publish your release nodes (which doesn't happen automatically if they're flagged as a "Security update") and send out the SA, at which point your users will know they need to upgrade (both via the security announcement email lists and RSS feeds, and via the update_status module).
Make sense? Do you really understand the process? Should I explain why any of these steps are like this? What else could be done, either via docs or project* UI, to make this clear?
Relevant issue: http://drupal.org/node/210497 "add extra validation to release node form for security update releases"
Relevant handbook docs: http://drupal.org/security-team
Thanks, -Derek (dww)
-- Alan Doucette Koi Technology, LLC www.KoiTech.net
-- Neil Drumm http://delocalizedham.com
1. non-upgraded sites are at risk otherwise there would be need to change. 2. making commit doesn't advertise anything unless you put a description saying what the security flaw is and how to exploit it. hopefully it is obvious to not ever do that, no matter when you commit it. 3. Unless you quietly found the hole by yourself it probably has been published somewhere (issue queue, etc). 4. committing code give you and others the chance to fix the issue with out publishing the code. Given this, I think I am still missing the point. On 1/16/08, Neil Drumm <drumm@delocalizedham.com> wrote:
As soon as you commit code you have publicly published the vulnerability and put non-upgraded sites at risk.
On Jan 15, 2008 11:58 PM, DragonWize <dragonwize@gmail.com> wrote:
I get why you have to wait to create a security node. But why do you have to wait to commit code? I assume there is a point I am missing because we do use a VERSION control system.
On 1/16/08, Derek Wright <drupal@dwwright.net> wrote:
Perhaps the docs are too detailed, confusing, hard to find, or obscure. I'd like to try in short, plain english to explain what to do when you think you've found a security problem in your module:
a) Either you think you find a potential security problem in your module or a user reports a vulnerability to you.
b) You *immediately* send email to security@drupal.org about it to let us know.
c) You try to analyze the vulnerability to the best of your abilities, and if possible produce a patch that fixes it.
d) DO NOT COMMIT YOUR PATCH YET.
e) DO NOT MAKE A RELEASE YET.
f) DO NOT MARK YOUR RELEASE AS A "SECURITY UPDATE" YET.
g) Send your patch to security@drupal.org.
h) Wait for the security team to reply.
i) Do what the security team advises you to do.
j) If/when the security team thinks your vulnerability is real, the fix is complete, and a security announcement (SA) is ready to go out, we'll tell you.
k) Only once an SA is ready for your vulnerability and the security team is ready to coordinate a release, THEN (and only then) do you commit your patch to all relevant branches, tag new releases, create release nodes, and mark them as "Security update" releases.
l) The security team can then publish your release nodes (which doesn't happen automatically if they're flagged as a "Security update") and send out the SA, at which point your users will know they need to upgrade (both via the security announcement email lists and RSS feeds, and via the update_status module).
Make sense? Do you really understand the process? Should I explain why any of these steps are like this? What else could be done, either via docs or project* UI, to make this clear?
Relevant issue: http://drupal.org/node/210497 "add extra validation to release node form for security update releases"
Relevant handbook docs: http://drupal.org/security-team
Thanks, -Derek (dww)
-- Alan Doucette Koi Technology, LLC www.KoiTech.net
-- Neil Drumm http://delocalizedham.com
-- Alan Doucette Koi Technology, LLC www.KoiTech.net
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 DragonWize schrieb:
1. non-upgraded sites are at risk otherwise there would be need to change.
2. making commit doesn't advertise anything unless you put a description saying what the security flaw is and how to exploit it. hopefully it is obvious to not ever do that, no matter when you commit it.
Every halfwit with a bit of php knowledge can see why a particular commit with a strange commit message would be a security fix. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHjkzIfg6TFvELooQRAq6GAJ9lweU+hyy5PbAOuEVRWSiySuFvogCbBjjf Qk6mnYthpxCg9SykEg3xVNM= =a596 -----END PGP SIGNATURE-----
I guess I am less than a halfwit even though I have a good amount of PHP knowledge. If I commit code, lets say I commit 10 files in my commit and one of those files fixed a security flaw, whether the flaw was known to me or not, I say upgrades to and fixes to v5 as usual. I don't see how I am going to put a red sign on distinguishing it from any other of the thousands of commits made. In addition, if anyone wanted to do harm they would actively seek out security flaws. You would find them much faster than waiting and hoping that someone slips up in a commit message. And lastly, it doesn't change the situation when you wait and commit it later. That commit is made and no site is upgraded still. So I believe I am still missing the point. I think it would be very helpful if someone could give me a concrete realistic example of the problem not committing will fix. Thank you, Alan On 1/16/08, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
DragonWize schrieb:
1. non-upgraded sites are at risk otherwise there would be need to change.
2. making commit doesn't advertise anything unless you put a description saying what the security flaw is and how to exploit it. hopefully it is obvious to not ever do that, no matter when you commit it.
Every halfwit with a bit of php knowledge can see why a particular commit with a strange commit message would be a security fix.
Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHjkzIfg6TFvELooQRAq6GAJ9lweU+hyy5PbAOuEVRWSiySuFvogCbBjjf Qk6mnYthpxCg9SykEg3xVNM= =a596 -----END PGP SIGNATURE-----
-- Alan Doucette Koi Technology, LLC www.KoiTech.net
On Jan 16, 2008 12:13 PM, DragonWize <dragonwize@gmail.com> wrote:
1. non-upgraded sites are at risk otherwise there would be need to change.
2. making commit doesn't advertise anything unless you put a description saying what the security flaw is and how to exploit it. hopefully it is obvious to not ever do that, no matter when you commit it.
3. Unless you quietly found the hole by yourself it probably has been published somewhere (issue queue, etc).
4. committing code give you and others the chance to fix the issue with out publishing the code.
Given this, I think I am still missing the point.
On 1/16/08, Neil Drumm <drumm@delocalizedham.com> wrote:
As soon as you commit code you have publicly published the vulnerability and put non-upgraded sites at risk.
On Jan 15, 2008 11:58 PM, DragonWize <dragonwize@gmail.com> wrote:
I get why you have to wait to create a security node. But why do you have to wait to commit code? I assume there is a point I am missing because we do use a VERSION control system.
On 1/16/08, Derek Wright <drupal@dwwright.net> wrote:
Perhaps the docs are too detailed, confusing, hard to find, or obscure. I'd like to try in short, plain english to explain what to do when you think you've found a security problem in your module:
a) Either you think you find a potential security problem in your module or a user reports a vulnerability to you.
b) You *immediately* send email to security@drupal.org about it to let us know.
c) You try to analyze the vulnerability to the best of your abilities, and if possible produce a patch that fixes it.
d) DO NOT COMMIT YOUR PATCH YET.
e) DO NOT MAKE A RELEASE YET.
f) DO NOT MARK YOUR RELEASE AS A "SECURITY UPDATE" YET.
g) Send your patch to security@drupal.org.
h) Wait for the security team to reply.
i) Do what the security team advises you to do.
j) If/when the security team thinks your vulnerability is real, the fix is complete, and a security announcement (SA) is ready to go out, we'll tell you.
k) Only once an SA is ready for your vulnerability and the security team is ready to coordinate a release, THEN (and only then) do you commit your patch to all relevant branches, tag new releases, create release nodes, and mark them as "Security update" releases.
l) The security team can then publish your release nodes (which doesn't happen automatically if they're flagged as a "Security update") and send out the SA, at which point your users will know they need to upgrade (both via the security announcement email lists and RSS feeds, and via the update_status module).
Make sense? Do you really understand the process? Should I explain why any of these steps are like this? What else could be done, either via docs or project* UI, to make this clear?
Relevant issue: http://drupal.org/node/210497 "add extra validation to release node form for security update releases"
Relevant handbook docs: http://drupal.org/security-team
Thanks, -Derek (dww)
-- Alan Doucette Koi Technology, LLC www.KoiTech.net
-- Neil Drumm http://delocalizedham.com
-- Alan Doucette Koi Technology, LLC www.KoiTech.net
Alan There is an RSS feed here http://drupal.org/cvs It has all the commits that went to the repository. Also cvs.drupal.org has all the info too. You can bet that black hat hackers are monitoring this (and other popular projects) for exploits. If you are a maintainer for a project and commit something here saying: "Fixed large SQL injection hole in module", with no announcement or release for it, then it is an invitation for an exploit. This is why it has to be coordinated with the SA. Yes, not all sites will upgrade the minute the release comes out, but there is nothing that can be done about that beyond the responsible disclosure process we are doing. -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting.
Khalid said: "If you are a maintainer for a project and commit something here saying: "Fixed large SQL injection hole in module", with no announcement or release for it, then it is an invitation for an exploit. " This is completely my point: 2. making commit doesn't advertise anything unless you put a description saying what the security flaw is and how to exploit it. hopefully it is obvious to not ever do that, no matter when you commit it. Even after the SA has been released you should never commit a message saying you fixed a security hole. That would be like putting the line # of the hole in the SA. You don't say what the hole is, where it is, or how to exploit it. This goes true for any commit you ever do. Because then they have to find, which they had to find it anyway so there is no difference between committing and not committing. In fact if you coordinate the commit with the SA you are just making it that much easier for them to find it. I am sorry Khalid. I am not trying to be difficult or argumentative. I truly don't see what change is made be not committing. Alan On 1/16/08, Khalid Baheyeldin <kb@2bits.com> wrote:
On Jan 16, 2008 12:13 PM, DragonWize <dragonwize@gmail.com> wrote:
1. non-upgraded sites are at risk otherwise there would be need to change.
2. making commit doesn't advertise anything unless you put a description saying what the security flaw is and how to exploit it. hopefully it is obvious to not ever do that, no matter when you commit it.
3. Unless you quietly found the hole by yourself it probably has been published somewhere (issue queue, etc).
4. committing code give you and others the chance to fix the issue with out publishing the code.
Given this, I think I am still missing the point.
On 1/16/08, Neil Drumm <drumm@delocalizedham.com > wrote:
As soon as you commit code you have publicly published the vulnerability and put non-upgraded sites at risk.
On Jan 15, 2008 11:58 PM, DragonWize < dragonwize@gmail.com> wrote:
I get why you have to wait to create a security node. But why do you have to wait to commit code? I assume there is a point I am missing because we do use a VERSION control system.
On 1/16/08, Derek Wright <drupal@dwwright.net> wrote:
Perhaps the docs are too detailed, confusing, hard to find, or obscure. I'd like to try in short, plain english to explain what to do when you think you've found a security problem in your module:
a) Either you think you find a potential security problem in your module or a user reports a vulnerability to you.
b) You *immediately* send email to security@drupal.org about it to let us know.
c) You try to analyze the vulnerability to the best of your abilities, and if possible produce a patch that fixes it.
d) DO NOT COMMIT YOUR PATCH YET.
e) DO NOT MAKE A RELEASE YET.
f) DO NOT MARK YOUR RELEASE AS A "SECURITY UPDATE" YET.
g) Send your patch to security@drupal.org.
h) Wait for the security team to reply.
i) Do what the security team advises you to do.
j) If/when the security team thinks your vulnerability is real, the fix is complete, and a security announcement (SA) is ready to go out, we'll tell you.
k) Only once an SA is ready for your vulnerability and the security team is ready to coordinate a release, THEN (and only then) do you commit your patch to all relevant branches, tag new releases, create release nodes, and mark them as "Security update" releases.
l) The security team can then publish your release nodes (which doesn't happen automatically if they're flagged as a "Security update") and send out the SA, at which point your users will know they need to upgrade (both via the security announcement email lists and RSS feeds, and via the update_status module).
Make sense? Do you really understand the process? Should I explain why any of these steps are like this? What else could be done, either via docs or project* UI, to make this clear?
Relevant issue: http://drupal.org/node/210497 "add extra validation to release node form for security update releases"
Relevant handbook docs: http://drupal.org/security-team
Thanks, -Derek (dww)
-- Alan Doucette Koi Technology, LLC www.KoiTech.net
-- Neil Drumm http://delocalizedham.com
--
Alan Doucette Koi Technology, LLC www.KoiTech.net
Alan
There is an RSS feed here http://drupal.org/cvs
It has all the commits that went to the repository. Also cvs.drupal.org has all the info too.
You can bet that black hat hackers are monitoring this (and other popular projects) for exploits.
If you are a maintainer for a project and commit something here saying: "Fixed large SQL injection hole in module", with no announcement or release for it, then it is an invitation for an exploit.
This is why it has to be coordinated with the SA.
Yes, not all sites will upgrade the minute the release comes out, but there is nothing that can be done about that beyond the responsible disclosure process we are doing. -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting.
-- Alan Doucette Koi Technology, LLC www.KoiTech.net
DragonWize wrote:
2. making commit doesn't advertise anything unless you put a description saying what the security flaw is and how to exploit it. hopefully it is obvious to not ever do that, no matter when you commit it.
Even after the SA has been released you should never commit a message saying you fixed a security hole. That would be like putting the line # of the hole in the SA. You don't say what the hole is, where it is, or how to exploit it. This goes true for any commit you ever do. Because then they have to find, which they had to find it anyway so there is no difference between committing and not committing. In fact if you coordinate the commit with the SA you are just making it that much easier for them to find it.
Security through obscurity does not work. It just makes it harder to tell when it doesn't work. If the author fixed a security bug, and black hat hackers are monitoring this, they *are* reading the code, and they *know* what they're looking for, and they are NOT going to share that data. It doesn't matter if the author annotated the fix in the CVS log or not.
My point is that it is not obscurity. It is the norm. I am not saying to obscure anything I am say to do what you normally do. If you commit an NON security commit it is no different than if you did. Changing that just makes their job easier. If they know what they are looking for, they will look for it. NOT wait for it. If you know what you are looking for the easiest way to find holes is by downloading the code anonymously and greping it. That would yield a million times better results in seconds rather than waiting days, weeks, or years for something to come through the cvs commits. And to find holes that are being created the only way a black hat hacker would do it is to write a script that greps his working copy on update everyday. Because looking through thousands of lines of code everyday is not an effective means to their end. If it is, that means they are very determined and there is nothing you can do to stop them because they know the hole long before this security process ever started and are already exploiting it. On 1/16/08, Earl Miles <merlin@logrus.com> wrote:
DragonWize wrote:
2. making commit doesn't advertise anything unless you put a description saying what the security flaw is and how to exploit it. hopefully it is obvious to not ever do that, no matter when you commit it.
Even after the SA has been released you should never commit a message saying you fixed a security hole. That would be like putting the line # of the hole in the SA. You don't say what the hole is, where it is, or how to exploit it. This goes true for any commit you ever do. Because then they have to find, which they had to find it anyway so there is no difference between committing and not committing. In fact if you coordinate the commit with the SA you are just making it that much easier for them to find it.
Security through obscurity does not work. It just makes it harder to tell when it doesn't work.
If the author fixed a security bug, and black hat hackers are monitoring this, they *are* reading the code, and they *know* what they're looking for, and they are NOT going to share that data. It doesn't matter if the author annotated the fix in the CVS log or not.
-- Alan Doucette Koi Technology, LLC www.KoiTech.net
On Jan 16, 2008 4:59 PM, DragonWize <dragonwize@gmail.com> wrote:
2. making commit doesn't advertise anything unless you put a description saying what the security flaw is and how to exploit it. hopefully it is obvious to not ever do that, no matter when you commit it.
This is a false assumption and several people have tried to point it out to you. Continuing to assume otherwise doesn't make it true. Making the commit does advertise a lot. The important thing is not the amount of time that the security hole is in the code. The most important thing is the amount of time between general knowledge of the hole and the upgrade of all sites that are running that code. So, what can we do to make that timespan small?
From the end of process to beginning -Make it really easy to perform the upgrade - aside from hosted services I think we've done about as much as we can here -Make it hard for users to be ignorant of the released fix (update_status.module, security maililng list and RSS) -Fix the security bug
So, if we fix the bug in CVS and then have to wait (any amount of time) before making the announcement then that's not helpful to end users and it introduces the possibility that someone will figure out what the commit meant. Fixing a hole in cvs is only the very beginning of running a secure project. We do run this process in a very standard way. If nothing else is convincing to you about why the process is this way, the fact that it is industry best practice should help. Regards, Greg -- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg
On Jan 16, 2008 6:13 PM, DragonWize <dragonwize@gmail.com> wrote:
2. making commit doesn't advertise anything unless you put a description saying what the security flaw is and how to exploit it. hopefully it is obvious to not ever do that, no matter when you commit it.
DragonWize: there is an infrastructure to let Drupal maintainers know about security fix releases. So when a module commits a security fix, it does release a security update, which is clearly marked as such, so that Drupal users are informed that they should update their modules. If a commit followed by a security release is not a clear indication of the previous commit being a security fix, then what is it? You advocate not marking updates as security updates, so users would not know whether the latest module version is a security update or not and they would need to update with each new version that comes out? With the current process, the security team coordinates releases, so the same security fix comes out in all supported core releases, and contributed module updates come out at the same time. So you don't need to fear that in any moment, you need to put all your work away, and update, because there was a security update for one of the modules you use. The security team tries to make Drupal site maintainer's life easier by doing coordinated releases, so you can make sure everything is fine all at once. That might not be the best solution ever, I am just pointing out the reasons behind the system. The point is that we are trying to make Drupal installs easier to keep secure with the notification on security updates and the coordinated timing of security updates. Gabor
DragonWize: there is an infrastructure to let Drupal maintainers know about security fix releases. So when a module commits a security fix, it does release a security update, which is clearly marked as such, so that Drupal users are informed that they should update their modules. If a commit followed by a security release is not a clear indication of the previous commit being a security fix, then what is it?
That is my point if you do the commit and release at the same time it is even easier.
You advocate not marking updates as security updates, so users would not know whether the latest module version is a security update or not and they would need to update with each new version that comes out?
I advocate not marking cvc commits as security. You are speaking of publishing a node as a security which I totally agree with.
With the current process, the security team coordinates releases, so the same security fix comes out in all supported core releases, and contributed module updates come out at the same time. So you don't need to fear that in any moment, you need to put all your work away, and update, because there was a security update for one of the modules you use. The security team tries to make Drupal site maintainer's life easier by doing coordinated releases, so you can make sure everything is fine all at once.
Agreed but that is for publishing the node not a lines of code. I appreciate everyone trying patiently trying to explain this to me and as everyone thinks that I am the only person to ever question this, I will not continue the thread any further. I was only responding to Derek's ask for unclear parts of the process. For all of our sake's, I hope that no one else has the issue of this being unclear. -- Alan Doucette Koi Technology, LLC www.KoiTech.net
Alan You have a point about not making it easy in the commit message. But even if we do that, what is the solution to notifying legitimate users (via RSS, email list), but not the black hats? We still have to tag releases as security, and issue SAs. There is no way we can hide that AND inform legitimate users WITHOUT the black hats knowing.
On Jan 16, 2008, at 11:47 AM, DragonWize wrote:
I appreciate everyone trying patiently trying to explain this to me and as everyone thinks that I am the only person to ever question this, I will not continue the thread any further.
No one assumes you're the only one who questions this.
I was only responding to Derek's ask for unclear parts of the process.
I'm *SO* glad you did. It means my thread wasn't in vain, since it produced some more awareness and interest in the process. Hopefully the thread will lead to some clarification of the reasons, or perhaps changes in the process itself. No matter what, I hope this thread encourages some aspiring contributor to help improve the documentation about the process in the d.o handbooks.
For all of our sake's, I hope that no one else has the issue of this being unclear.
Of course other people have the issue of this being unclear. ;) Ultimately, I think the debate in this thread boils down to 3 things: 1) Clarity on the threats this process is trying to protect us from. I think Greg's email best summed it up. We're worried about potential hackers finding out about security vulnerabilities before Drupal site maintainers have a way to plug the holes. It's one of the few downsides of a fully open source project -- everyone, friend or foe, can see what's happening with the source all the time. 2) Disagreement on how actively hackers monitor Drupal's CVS repository. We have no way to know this for sure, only speculation (on all sides). Given that we're operating completely in the dark on this, in the interest of caution/safety, we should probably assume that hackers are paying more attention here, not less. Certainly, they're going to be sad hackers if all they do is wait around for commits that are patching vulnerabilities. Presumably, they're doing other things: their own audits, automated tests/tools, whatever. However, for the sake of argument, let's assume they're *also* watching the commits at some level. Agreed? 3) Disagreement about how much it helps to obfuscate the commit message regarding security patches. DragonWize, you're not being consistent here: On Jan 16, 2008, at 11:34 AM, DragonWize wrote:
My point is that it is not obscurity.
On Jan 16, 2008, at 11:47 AM, DragonWize wrote:
I advocate not marking cvc commits as security.
Which is it? ;) Either you grant that hackers are potentially watching commits (in which case you claim it's better to obscure the reason behind the commit), or they're not (in which case it's not security through obscurity at all). In both cases, I think you're wrong. :) The problem is not whether the commit says it's a vulnerability or not. As killes eloquently pointed out "any halfwit" can figure it out (side note: he wasn't calling you a halfwit, he was calling the potential hackers halfwits, so don't take it personally). No matter if the commit happened minutes or weeks before the release goes out, any hacker with the faintest clue about what they're doing would do "cvs diff -r DRUPAL-5--1-2 -r DRUPAL-5--1-3" and see all the changes that happened between version 5.x-1.2 and 5.x-1.3 to narrow down their search for what vulnerability was fixed in 5.x-1.3. Really, your claims about "not putting a line number for the exploit in the SA" boil down to security through obscurity. The problem is that if the fix goes into CVS days or weeks before an official release goes out and a security announcement is published, that interested readers (hackers) will (potentially) know about the problem long before users can defend themselves against it. The security team's goal with this policy can be summarized as: "Try not to disclose *anything* about a vulnerability until there's an official release available that fixes it." Committing a fix to CVS days or weeks before the releases + SA go out violates this goal. Note: our goal is specifically *not*: "try to fool hackers so they can't figure out what the vulnerability is even once it's been disclosed." That's pure folly. Really, the only point of the obfuscated commit message is to attempt this foolery, and I think it's a joke. So long as the commit is happening basically simultaneously with the release being tagged and the SA being published, I'd *rather* the commit message explains what it's for. Obscurity doesn't help us here at all (hackers will see right through it), and in fact, some legitimate users of the module might actually see the commit faster (and realize they need to update) that way than waiting for the SA emails to go out, etc. Really, once the SA happens, it's just a race to try to get everyone to upgrade before hackers have much of a chance to exploit it. All we can do to help that race is try to make sure everyone's on the security announcement list, everyone's running update_status.module, everyone's subscribed to the security RSS feed, and make it easier and easier for people to upgrade their site. The point is when does the clock start ticking for both parties in the race? We'd rather start everyone at the same time and give them a fair chance, than ever give the hackers a head start in any way. Can I get an 'amen'? ;) Anyway, thanks for keeping an important thread alive... I don't claim to have all the answers here, and certainly myself and the rest of the security team welcome feedback on this process. However, I think we have pretty reasonable justifications for the current policy, even if everything isn't as clearly explained and documented as it could be. Cheers, -Derek (dww) p.s. Note: no one on the security team has any illusions that this process, alone, leads to complete security for all of Drupal. Of course there are many vulnerabilities in contrib, and probably still some in core, and it's entirely likely that hackers know about these and we don't. That's a completely separate question from the situation of how we handle it when we *do* find out about a vulnerability. The solutions to the former problem are getting more security experts involved on the security team, better automated tools/tests for our side, more general awareness and concern about security in the Drupal community (both users and developers), etc, etc. All of that is worthy, and on-going, and we always need more help. But, that's off topic from the point of this particular thread.
Just somw thoughts.. - Everyone "watching/monitoring" cvs for security holes doesn't wait for a "security" release to be published. It happends in a coordinated release as the SA flow, or in not really coordinated releases. - Doing a coordinate release will close the time window for those monitoring only drupal security releases, what is good in any case. The people doing extensive monitoring will not be stopped even in a coordinated release, as not every people can update their sites, nor even know about the security release tags. - Note: despite about hackers looking for site ownage.. there's already paying services to simply get as stealthly as possible a list of real live email addresses. This is a more real worry than a "hacker" trying to do a php worm to deface any drupal site. It happends also in joomla, wordpress and any other web application, where the more close to a community is the application, bigger is the fee.. Some email addresses can be sold for $1 each if they deserve. Drupal users/administrators should be encouraged to know about the security relevant information of drupal, I don't know, maybe while they wait the download process to finish. I know a few people hearing how good drupal is, downloading, testing, and using their site.. after a year they realized they did nothing about site security, or module updates. Some of this sites are still published as they were installed.
I think Greg's email best summed it up. We're worried about potential hackers finding out about security vulnerabilities before Drupal site maintainers have a way to plug the holes. It's one of the few downsides of a fully open source project -- everyone, friend or foe, can see what's happening with the source all the time.
For sure I can tell you this is happening outsite of drupal scope.
We have no way to know this for sure, only speculation (on all sides). Given that we're operating completely in the dark on this, in the interest of caution/safety, we should probably assume that hackers are paying more attention here, not less. Certainly, they're going to be sad hackers if all they do is wait around for commits that are patching vulnerabilities.
These hackers do not have to be sad people.. everybody is free to have it's own hobby.. IT's true also, that some scripts can do almost 90% of the job in automated vulnerabilities finding, and more than 90% if the scope of code is well defined: for example, drupal scope including drupal API.
Presumably, they're doing other things: their own audits, automated tests/tools, whatever. However, for the sake of argument, let's assume they're *also* watching the commits at some level. Agreed?
The cvs is already being monitored, I know (I'm not saying they are friends in any case) some people doing it, not only in drupal, but in many many cvs svn or even websites. I myself have spent sometime monitoring www.debian.org website. In the front page of that site, new security updates about debian packages are being published. It's one of many resources being used to track and pick vulns. Also, the tools they use to program, these named "automated test/tools" are of course, tools to better find vulns in cvs diffs, between others..
3) Disagreement about how much it helps to obfuscate the commit message regarding security patches. DragonWize, you're not being consistent here:
Tagging a release only "security", and including only the security patch code makes finding the vuln very very easy. Here DragonWize has some kind of reason.. Even if you tag the update as security, just to keep update_status tracking the new release, the diff of the two versions can make a little difficult to really find the security code before many sites could be patched.
Really, your claims about "not putting a line number for the exploit in the SA" boil down to security through obscurity. The problem is that if the fix goes into CVS days or weeks before an official release goes out and a security announcement is published, that interested readers (hackers) will (potentially) know about the problem long before users can defend themselves against it.
I agree with Derek here. If fix a security bug, you probably comment the code with the security information, or update an issue post. This may advise a group of "monitoring" people about the flaw, even if others may have found it time ago. The security tag should go close to the release of the SA from drupal.
Really, once the SA happens, it's just a race to try to get everyone to upgrade before hackers have much of a chance to exploit it. All we can do to help that race is try to make sure everyone's on the security announcement list, everyone's running update_status.module, everyone's subscribed to the security RSS feed, and make it easier and easier for people to upgrade their site. The point is when does the clock start ticking for both parties in the race? We'd rather start everyone at the same time and give them a fair chance, than ever give the hackers a head start in any way.
The only way to get this working is doing a coordinated release.
p.s. Note: no one on the security team has any illusions that this process, alone, leads to complete security for all of Drupal. Of course there are many vulnerabilities in contrib, and probably still some in core, and it's entirely likely that hackers know about these and we don't. That's a completely separate question from the situation of how we handle it when we *do* find out about a vulnerability. The solutions to the former problem are getting more security experts involved on the security team, better automated tools/tests for our side, more general awareness and concern about security in the Drupal community (both users and developers), etc, etc. All of that is worthy, and on-going, and we always need more help. But, that's off topic from the point of this particular thread.
The cvs server is a powerfull tool, and can help to automate many process on commit, as check some security basic tests on each file, or even launch audit processes.. I agree again here. If drupal sec team is (or feels) in somehow resposible of the contribs module's security status, should start monitoring them as others do. Sorry if I bother you, it's just an oppinion :)
On Jan 16, 2008, at 9:13 AM, DragonWize wrote:
3. Unless you quietly found the hole by yourself it probably has been published somewhere (issue queue, etc).
If everyone was following instructions, they'd report the hole to security@drupal.org, not the issue queue. Whenever we find security problems reported publicly in the issue queue (which sucks, but it does happen), we try to immediately unpublish the issue and move discussion back into the security team's issue tracker. Of course, it's often too late at that point (people already got emails about it if they're subscribed to the queue, someone might have already seen it, etc, but we do the best we can...
4. committing code give you and others the chance to fix the issue with out publishing the code.
I can't parse what you mean here. I'm not sure it matters, since it smells like security through obscurity to me, but perhaps you could clarify your point? How is committing the code not "publishing the code"? Oh, and one more good reason not to just go off and commit your patch as soon as you think you fixed the problem... The security team carefully reviews your patch, and usually audits the rest of your module at the same time. Maybe you fixed 1 hole, but missed 3 others. Maybe your "fix" is still vulnerable to some case you're not thinking of. Maybe your "fix" introduces a bug or otherwise makes life miserable for users trying to upgrade. Who knows. Point is, you want to wait for the security team to review your patch, audit your code, and propose improvements to your solution (if there are any to be made). All of this should happen privately, between you and the security team, not publicly via a stream of CVS commits. Make sense? Thanks, -Derek (dww)
Thank you Derek for your explanations. You have said a lot but let me focus on the area where I think we are diverging. I agree with most of what you are doing and understand you explanations. I just don't fully agree with some of them. Lets say for the sake of understanding that everything you say is 100% correct. Lets assume to be on the safe side that every hacker reads every line of code that comes through the cvs log. That hacker will know long before a fix is committed because he will know when the hole was committed. So not committing the fix does nothing to help this doomsday scenario. This is the part that I don't understand. Either way whether code is committed I don't see the benefit you describe in the race to ensure sites are secure. The race is definitely important, I do not deny that, I just don't understand how your method helps that race. I see 3 possible out comes: 1. The hacker already knows when the SA is sent. No benefit gained. 2. The hacker doesn't know when the SA is sent but we have already told him exactly where the hole is by saying we commit at the same time. Yes they could find it extremely easily with out this but we just made it slightly easier. 3. The hacker doesn't know when the SA is sent but we haven't made a policy about when exactly the code is committed. Can they very easily find it anyway? For sure they can, I don't deny that. I also am not sugesting remove this step in your short simple guide because it provides better security. I am saying that I don't see better in security by including it so why make the process harder to understand and remember if it doesn't provide a benefit. Thank you for your time, Alan On 1/16/08, Derek Wright <drupal@dwwright.net> wrote:
On Jan 16, 2008, at 9:13 AM, DragonWize wrote:
3. Unless you quietly found the hole by yourself it probably has been published somewhere (issue queue, etc).
If everyone was following instructions, they'd report the hole to security@drupal.org, not the issue queue. Whenever we find security problems reported publicly in the issue queue (which sucks, but it does happen), we try to immediately unpublish the issue and move discussion back into the security team's issue tracker. Of course, it's often too late at that point (people already got emails about it if they're subscribed to the queue, someone might have already seen it, etc, but we do the best we can...
4. committing code give you and others the chance to fix the issue with out publishing the code.
I can't parse what you mean here. I'm not sure it matters, since it smells like security through obscurity to me, but perhaps you could clarify your point? How is committing the code not "publishing the code"?
Oh, and one more good reason not to just go off and commit your patch as soon as you think you fixed the problem...
The security team carefully reviews your patch, and usually audits the rest of your module at the same time. Maybe you fixed 1 hole, but missed 3 others. Maybe your "fix" is still vulnerable to some case you're not thinking of. Maybe your "fix" introduces a bug or otherwise makes life miserable for users trying to upgrade. Who knows. Point is, you want to wait for the security team to review your patch, audit your code, and propose improvements to your solution (if there are any to be made). All of this should happen privately, between you and the security team, not publicly via a stream of CVS commits.
Make sense?
Thanks, -Derek (dww)
-- Alan Doucette Koi Technology, LLC www.KoiTech.net
I think the worry is not how much does the SA help the hackers, but just how much the security team helps the drupal administrators. right? so..
1. The hacker already knows when the SA is sent. No benefit gained.
1. The drupal administrator has a fixed version to download and receives the SA.
2. The hacker doesn't know when the SA is sent but we have already told him exactly where the hole is by saying we commit at the same time. Yes they could find it extremely easily with out this but we just made it slightly easier.
2. The drupal administrator has a fixed version to download and receives the SA. Clock is ticking for both.
3. The hacker doesn't know when the SA is sent but we haven't made a policy about when exactly the code is committed. Can they very easily find it anyway? For sure they can, I don't deny that. I also am not sugesting remove this step in your short simple guide because it provides better security. I am saying that I don't see better in security by including it so why make the process harder to understand and remember if it doesn't provide a benefit.
3. The drupal administrator has a fixed version to download and receives the SA. Clock is ticking for both as in 2. But I understand that the SA process only works if every drupal administrator know about the security updates, releases and advisories, and all contributors follow the guidelines..
Thank you for your time, Alan
Note: I think the way you do Alan, but we should agree not every module contributor would follow basic security steps (just a look to some modules would clarify this), and the security team is trying to do it's best to not let drupal administrators alone.
On 1/16/08, Derek Wright <drupal@dwwright.net> wrote:
On Jan 16, 2008, at 9:13 AM, DragonWize wrote:
3. Unless you quietly found the hole by yourself it probably has been published somewhere (issue queue, etc).
If everyone was following instructions, they'd report the hole to security@drupal.org, not the issue queue. Whenever we find security problems reported publicly in the issue queue (which sucks, but it does happen), we try to immediately unpublish the issue and move discussion back into the security team's issue tracker. Of course, it's often too late at that point (people already got emails about it if they're subscribed to the queue, someone might have already seen it, etc, but we do the best we can...
4. committing code give you and others the chance to fix the issue with out publishing the code.
I can't parse what you mean here. I'm not sure it matters, since it smells like security through obscurity to me, but perhaps you could clarify your point? How is committing the code not "publishing the code"?
Oh, and one more good reason not to just go off and commit your patch as soon as you think you fixed the problem...
The security team carefully reviews your patch, and usually audits the rest of your module at the same time. Maybe you fixed 1 hole, but missed 3 others. Maybe your "fix" is still vulnerable to some case you're not thinking of. Maybe your "fix" introduces a bug or otherwise makes life miserable for users trying to upgrade. Who knows. Point is, you want to wait for the security team to review your patch, audit your code, and propose improvements to your solution (if there are any to be made). All of this should happen privately, between you and the security team, not publicly via a stream of CVS commits.
Make sense?
Thanks, -Derek (dww)
--
Alan Doucette Koi Technology, LLC www.KoiTech.net
Not that it will matter in the long scheme of things but in case the security team is interested in feedback , I'm generally in agreement with DragonWize here. I'm not in favor of holding up commits to code. The only benefit is predicated on the fact that you can tell a security vulnerability from a bug fix based on the code that you see fly by. I hope my security bugs aren't all that obvious, and as Derek says, this is all conjecture. We don't actually know wether they'd discover it from the commt logs. The drawback from my perspective is two fold: 1. It definitely increases the amount of time the vulnerability is out there. Vulnerabilities will be patched more slowly when they ONLY can be commited by the security team, who is a finite group of volunteer bodies. Who may or may not have the expertise to properly review the code, but are put in the process as if they are. This is not a criticism of the dedication or expertise of this wonderful group of people, but just a reflection of the diversity and complexity of all the contrib modules out there. For example, I maintain a CAS single sign-on module. Do I have to wait for a security team member to ramp up on what CAS is so that they can perform the review tasks that are inherent there to do a decent job of reviewing the code? 2. It seems to take the RTBC decision out of the contrib module owners hands. When is the patch tested enough? Who decides this? All of the handshaking and discussion regarding this with the security team adds to the time that the vulnerability is in circulation. When I discovered a vulnerability in my CAS module, I was in discussion with other maintainers, off-line of course, and not with the security team who had other more productive tasks to be engaged in. We were the best people to make the decision about when the code was RTBC. And whether other bug fixes should be included in the Release for the purposes of stability. Other bug fixes were included with the relaase that we made. I also agree with DragonWize's assessment that decoupling the SA/RA from the commit will make it harder (especially if you factor in other bug fixes that might be included in that release)for you to theoretically detect a vulnerability by sniffing commit logs. Anyway, won't harp, but wanted others to know that it's more than just DragonWize that sees this perspective. On Jan 16, 2008, at 1:36 PM, DragonWize wrote:
Thank you Derek for your explanations. You have said a lot but let me focus on the area where I think we are diverging. I agree with most of what you are doing and understand you explanations. I just don't fully agree with some of them.
Lets say for the sake of understanding that everything you say is 100% correct. Lets assume to be on the safe side that every hacker reads every line of code that comes through the cvs log. That hacker will know long before a fix is committed because he will know when the hole was committed. So not committing the fix does nothing to help this doomsday scenario. This is the part that I don't understand.
Either way whether code is committed I don't see the benefit you describe in the race to ensure sites are secure. The race is definitely important, I do not deny that, I just don't understand how your method helps that race. I see 3 possible out comes:
1. The hacker already knows when the SA is sent. No benefit gained.
2. The hacker doesn't know when the SA is sent but we have already told him exactly where the hole is by saying we commit at the same time. Yes they could find it extremely easily with out this but we just made it slightly easier.
3. The hacker doesn't know when the SA is sent but we haven't made a policy about when exactly the code is committed. Can they very easily find it anyway? For sure they can, I don't deny that. I also am not sugesting remove this step in your short simple guide because it provides better security. I am saying that I don't see better in security by including it so why make the process harder to understand and remember if it doesn't provide a benefit.
Thank you for your time, Alan
On 1/16/08, Derek Wright <drupal@dwwright.net> wrote:
On Jan 16, 2008, at 9:13 AM, DragonWize wrote:
3. Unless you quietly found the hole by yourself it probably has been published somewhere (issue queue, etc).
If everyone was following instructions, they'd report the hole to security@drupal.org, not the issue queue. Whenever we find security problems reported publicly in the issue queue (which sucks, but it does happen), we try to immediately unpublish the issue and move discussion back into the security team's issue tracker. Of course, it's often too late at that point (people already got emails about it if they're subscribed to the queue, someone might have already seen it, etc, but we do the best we can...
4. committing code give you and others the chance to fix the issue with out publishing the code.
I can't parse what you mean here. I'm not sure it matters, since it smells like security through obscurity to me, but perhaps you could clarify your point? How is committing the code not "publishing the code"?
Oh, and one more good reason not to just go off and commit your patch as soon as you think you fixed the problem...
The security team carefully reviews your patch, and usually audits the rest of your module at the same time. Maybe you fixed 1 hole, but missed 3 others. Maybe your "fix" is still vulnerable to some case you're not thinking of. Maybe your "fix" introduces a bug or otherwise makes life miserable for users trying to upgrade. Who knows. Point is, you want to wait for the security team to review your patch, audit your code, and propose improvements to your solution (if there are any to be made). All of this should happen privately, between you and the security team, not publicly via a stream of CVS commits.
Make sense?
Thanks, -Derek (dww)
-- Alan Doucette Koi Technology, LLC www.KoiTech.net
On Jan 16, 2008 9:08 PM, David Metzler <metzlerd@metzlerd.com> wrote:
2. It seems to take the RTBC decision out of the contrib module owners hands. When is the patch tested enough? Who decides this? All of the handshaking and discussion regarding this with the security team adds to the time that the vulnerability is in circulation.
Not at all, they don't write the patch for you, you and your co-maintainers come up with the fix. You RTBC it... As for any secondary reviews by the security team extending the vulnerability window, they've been very prompt when I've dealt with them and I appreciated the second set of eyes. I'd feel really dumb posting a security fix that didn't actually fix the bug but brought it to everyone's attention.
When I discovered a vulnerability in my CAS module, I was in discussion with other maintainers, off-line of course, and not with the security team who had other more productive tasks to be engaged in. We were the best people to make the decision about when the code was RTBC. And whether other bug fixes should be included in the Release for the purposes of stability. Other bug fixes were included with the relaase that we made.
You seem concerned about loosing control of your module to the security team. I can tell you that this fear is unfounded. The security team is here to help, not tie your hands. And as for more productive tasks... this is exactly what they're here for. I don't have the energy to get into a discussion on mixing security and bug fixes in a release so I'll just say that I think it's a bad idea. The best practice would be to get the minimum patch out to fix the security hole and then then follow it up with additional fixes in a later release. andrew andrew
When I discovered a vulnerability in my CAS module, I was in discussion with other maintainers, off-line of course, and not with the security team who had other more productive tasks to be engaged in. We were the best people to make the decision about when the code was RTBC. And whether other bug fixes should be included in the Release for the purposes of stability. Other bug fixes were included with the relaase that we made.
I don't have the energy to get into a discussion on mixing security and bug fixes in a release so I'll just say that I think it's a bad idea. The best practice would be to get the minimum patch out to fix the security hole and then then follow it up with additional fixes in a later release.
andrew
Regarding mixing of unrelevant bug with security fixes: Please bear in mind that there might also be users of your module that needed to make customizations. If they are not able to understand and fix the security issue only, they perhaps won't fix it at all. Daniel
On Jan 17, 2008, at 2:37 AM, andrew morton wrote:
On Jan 16, 2008 9:08 PM, David Metzler <metzlerd@metzlerd.com> wrote:
2. It seems to take the RTBC decision out of the contrib module...
Not at all, they don't write the patch for you, you and your co-maintainers come up with the fix. You RTBC it... As for any secondary reviews by the security team extending the vulnerability window, they've been very prompt when I've dealt with them and I appreciated the second set of eyes. I'd feel really dumb posting a security fix that didn't actually fix the bug but brought it to everyone's attention.
I'm not doubting the intentions of the security team, nor the need for quality code review, just the assumption that the fastest way to get a release into the hands of the users is always done by single threading this through the security team. FYI: I also got a quick answer when I asked them the best way to patch my bug (I did consult with them after all), and I was appreciative of the info. but they didn't offer to review my code, and they didn't try to manage my patch process at the time. Maybe the next time it will be different....
When I discovered a vulnerability in my CAS module,....
You seem concerned about loosing control of your module to the security team. I can tell you that this fear is unfounded. The security team is here to help, not tie your hands. And as for more productive tasks... this is exactly what they're here for.
I don't have the energy to get into a discussion on mixing security and bug fixes in a release so I'll just say that I think it's a bad idea. The best practice would be to get the minimum patch out to fix the security hole and then then follow it up with additional fixes in a later release.
I don't either, so lets just agree that I don't run releases the way the security team wants me to. Oh well. I'd love to debate that over a beer sometime :) I'm not worried that the security team will take over my module. But I am concerned that if I am authoring a module that deals with a single sign-on protocol that the security team is not versed in and isn't really used by that many of the drupal users (which I am), that when it comes down to it, my modules "audit" as derek describes it, will not (and I believe rightly so) be at the top of the priority list of the security team. Meanwhile, I'm instructed to not commit or release the fix. This is again predicated on the fact that someone might be able to recognize the vulnerability based on the source code that expresses the fix. I can't verify the patch/commit process, or independently install and verify the vulnerability is fixed in a dev or beta release until the security team puts out an announcement saying the patch is ready for download. Doing testing of committed code is my practice regardless of whether its a security related patch or not. Given our distro system, if we're really worried about hackers sniffing commit logs, I would rather remove anonymous CVS access. That way you stop the vulnerability sniffing all together. Like I said I know I'm in the minority here and don't really expect to change your mind on this one. I been involved with enough volunteer organizations to know that it's always an uphill battle to manage workload. I don't begrudge that, but I try and keep my expectations tempered. I really hope no-one on the security team is offended. I mean no such offense. I really do respect and appreciate the service that they provide and yes, I do consult with them when I do my security related fixes.
andrew
andrew
On Jan 17, 2008 6:51 PM, David Metzler <metzlerd@metzlerd.com> wrote:
On Jan 17, 2008, at 2:37 AM, andrew morton wrote:
On Jan 16, 2008 9:08 PM, David Metzler <metzlerd@metzlerd.com> wrote:
2. It seems to take the RTBC decision out of the contrib module...
Not at all, they don't write the patch for you, you and your co-maintainers come up with the fix. You RTBC it... As for any secondary reviews by the security team extending the vulnerability window, they've been very prompt when I've dealt with them and I appreciated the second set of eyes. I'd feel really dumb posting a security fix that didn't actually fix the bug but brought it to everyone's attention.
I'm not doubting the intentions of the security team, nor the need for quality code review, just the assumption that the fastest way to get a release into the hands of the users is always done by single threading this through the security team.
We simultaneously send a security announcement (SA) to the 13k subscribers. We can't give module maintainers permission to do that, mailing lists of that size have to be treated with care. It does add extra time to the module's release cycle, we do a batch of security releases twice a month. We do our best to make sure everyone, from back hats to non-technical webmasters, know about the vulnerability at the same time. -- Neil Drumm http://delocalizedham.com
Given our distro system, if we're really worried about hackers sniffing commit logs, I would rather remove anonymous CVS access.
We can't do that. Many users rely on cvs access to deploy sites. We can in theory shut that down. But what about http://drupal.org/cvs? That way you stop the vulnerability sniffing all together. Like I
said I know I'm in the minority here and don't really expect to change your mind on this one.
If we shut down both, then it is no longer an open source project. Didn't see any major project shut down like that.
I been involved with enough volunteer organizations to know that it's always an uphill battle to manage workload. I don't begrudge that, but I try and keep my expectations tempered.
I really hope no-one on the security team is offended. I mean no such offense. I really do respect and appreciate the service that they provide and yes, I do consult with them when I do my security related fixes.
No offense taken at all, from you or from others. We are always open to suggestions (and even recruiting for the security team!) -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting.
On Jan 17, 2008 3:08 AM, David Metzler <metzlerd@metzlerd.com> wrote:
The drawback from my perspective is two fold:
1. It definitely increases the amount of time the vulnerability is out there.
"Out there" is not important. "Generally known without the fix installed on people's sites" is important. You need to coordinate with the Security team, among other reasons, because the Security team has their finger on the button for 1) Newsletter emails 2) RSS feed, 3) Update_status. If the module owner commits the patch and announces it on the module home page the result is that basically nobody will know. Once the security team uses those three methods to alert people, there are at least 15,000 people who know (mailing list subscribers) and probably several times that number in terms of RSS and Update Status users.
Vulnerabilities will be patched more slowly when they ONLY can be commited by the security team, who is a finite group of volunteer bodies. Who may or may not have the expertise to properly review the code, but are put in the process as if they are. This is not a criticism of the dedication or expertise of this wonderful group of people, but just a reflection of the diversity and complexity of all the contrib modules out there.
Sure, the insertion of the security team slows down the "commit" part of the process, but that is not the important part of the process. Most of the waiting that happens is due to the fact that we make security releases in bundles. This policy of bundling patches was instituted to make it easier for site admins to update their site. I know that it has made my life easier, but we are certainly open to feedback on this point and others.
For example, I maintain a CAS single sign-on module. Do I have to wait for a security team member to ramp up on what CAS is so that they can perform the review tasks that are inherent there to do a decent job of reviewing the code?
Well, in fact there is no way for the security team to prevent people from committing code to CVS that fixes security holes - that's part of why we're sticking with this thread to convince people that it is a bad practice that unnecessarily puts their end users at risk.
2. It seems to take the RTBC decision out of the contrib module owners hands. When is the patch tested enough? Who decides this? All of the handshaking and discussion regarding this with the security team adds to the time that the vulnerability is in circulation.
In practice this process is quite friendly. Most of the time the module author says "here is a patch that I think is ready" and the security team says "yeah, looks great to us to." We rely on the module authors to ensure functionality of the patch and are mostly looking to see that their fix actually closes the hole and that there are no other holes.
When I discovered a vulnerability in my CAS module, I was in discussion with other maintainers, off-line of course, and not with the security team who had other more productive tasks to be engaged in. We were the best people to make the decision about when the code was RTBC. And whether other bug fixes should be included in the Release for the purposes of stability. Other bug fixes were included with the relaase that we made.
I see - this was your release: http://drupal.org/node/153707 Which never got an SA, right? This module is in a somewhat abnormal place in terms of policy because I don't imagine it is used on thousands of sites, but the fact that it didn't have an Email/RSS announcement means that relatively few people know about it. There could be someone who is using this module who signed up to the security newsletter to hear about updates and is still assuming that this module is totally secure because they never got an SA. I think that's a good example of why the security team needs to be involved.
I also agree with DragonWize's assessment that decoupling the SA/RA from the commit will make it harder (especially if you factor in other bug fixes that might be included in that release)for you to theoretically detect a vulnerability by sniffing commit logs.
As Drewish points out, jamming a bunch of things into a release at the last minute is probably not a good idea in terms of stability. It's also considered best practice (discussed on this list either one year ago or two years ago) to make sure your commits contain one change each. This makes it easier to review/roll-back later. And again, the most important thing is that we put site admins on equal footing with the hackers in the race to update sites before an exploit/worm is created. The best way to do that is to be very very quiet about the fix right up until it's done and then tell the whole world about it as loudly as possible at the same time. Now, what about an alternate workflow. I've been insisting that "because the security team has the ability to send the SA email/feed that the security team needs to be involved in the process." What if we had contrib authors publish their own SAs and what if we gave them the ability to create releases that were tagged with "security" that got published immediately. Would this help or hurt the process? Frankly, it would remove a lot of work from the security team. We could say "the security team can help you with this process if you want." Thoughts? Greg -- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg
Revisiting the original issue. On 1/16/08, Derek Wright <drupal@dwwright.net> wrote:
Perhaps the docs are too detailed, confusing, hard to find, or obscure. I'd like to try in short, plain english to explain what to do when you think you've found a security problem in your module:
It is apparent through Derek's plea here that module developers are not following the security teams protocol. I see 2 main reasons why: 1. Education. This will always be a challenge but helps if you have a marketable version of the information you are trying to get out to everyone. 2. Getting module developers on board with the process. As it has been pointed out several times, the point of the process is to get out important updates and announcements to Site Admins in the best and safest way possible. Well let me point out that if you make the process difficult, that will be a deterrent for developers to follow the process. While security is very important, you have to be willing to see the end value and not just the perceived value of the process. If you have an super secure process but developers don't follow it, where does that leave the Site Admins? In a much worse position than if the process was simpler and provided slightly less security proccess. It is much better to have a 90% secure process that is followed than a 100% secure process that is NOT followed. With that in mind I would like to revisit the process:
a) Either you think you find a potential security problem in your module or a user reports a vulnerability to you.
This is a description and doesn't help the marketability of the process.
b) You *immediately* send email to security@drupal.org about it to let us know.
Agreed. This easy to understand, perform and educate. Maybe also have other ways for developers & users alike to the security team that doesn't make them have to remember the email address. The more ways to contact them with important information the better.
c) You try to analyze the vulnerability to the best of your abilities, and if possible produce a patch that fixes it.
More added descriptions that doesn't help the marketability.
d) DO NOT COMMIT YOUR PATCH YET.
This stops all development and is not friendly to the developer. We have shown this step provides little to no benefit or possible harm. I think that no matter what your position on the subject is, this is an easy step to remove to make the process better.
e) DO NOT MAKE A RELEASE YET.
This too I think is going over board. I will describe more about what I propose below.
f) DO NOT MARK YOUR RELEASE AS A "SECURITY UPDATE" YET.
I think that marking something as a security release should be taken out of the hands of the developers. Only the security team should be able to do this. More info below.
g) Send your patch to security@drupal.org.
This is more work for the developer that can easily be removed by having the security team use our version control system.
h) Wait for the security team to reply.
More description.
i) Do what the security team advises you to do.
More description and slightly unfriendly in the fact is makes you feel like the security team is your boss. While I know that the security team is a great bunch of people and this is not true about the process or how they work with people, this step gives the wrong impression to those that do not know that.
j) If/when the security team thinks your vulnerability is real, the fix is complete, and a security announcement (SA) is ready to go out, we'll tell you.
This is a security team process not needed for the developer process.
k) Only once an SA is ready for your vulnerability and the security team is ready to coordinate a release, THEN (and only then) do you commit your patch to all relevant branches, tag new releases, create release nodes, and mark them as "Security update" releases.
Again, I think that this should be a security team step not a developer. See below.
l) The security team can then publish your release nodes (which doesn't happen automatically if they're flagged as a "Security update") and send out the SA, at which point your users will know they need to upgrade (both via the security announcement email lists and RSS feeds, and via the update_status module).
Agreed. Now let me propose a modified process: Developers Process: 1. Contact the security team with information about security holes. 2. Do NOT post security vulnerabilities. The Security team will take care of that. That is a very marketable process. In the handbooks and other places we can elaborate with more information if needed. Security Team Process: 1. Coordinate with the developer to evaluate the hole and fix. 2. Coordinate with the developer on which revision # is safe to publish as an Official security release. 3. Publish or mark a release as security update and send out the announcements. Let me explain these proposed processes a little. Getting knowledge into the security teams hands is the first and most important thing. Once the security team has that knowledge they can communicate with the developer on the problem and fix. The developer should go about his normal work flow except we need to educate them that only the security team should announce security holes or updates. This is to help the security race. The security team should then coordinate with the developer on what revision # is safe to mark as a security release. This could be an already published release or a revision # of one of the branches. The security team would then, at their discretion, mark or publish a release as a security release and send out announcements. I realize that many people may find that this approach is lacking in certain areas but I honestly believe the final result would be much more secure even if the the process is not as secure. We would then educate developers and users by creating a security report form and linking to it from all appropriate places. On this form page make it clear to not advertise the security hole or the fix because the security team will do a coordinated security release and announcement. It is also very easy to educate developers by just saying: "Contact the security team". Which is much easier than having grok man pages and long processes. This also makes it very easy for the security team to change their policies or procedures without having to re-educate all developers. Just my 2 cents. Thoughts? -- Alan Doucette Koi Technology, LLC www.KoiTech.net
One thing that could certainly make things simpler would be to have a "security" issue type, for which issues would only be visible to the author and members of the security team. Security issues could then be issued just like normal issues: it would maintain consistency, instead of introducing a specific behaviour for people wishing to report security issues. However, I'm not sure project* will easily support this ? ----- Original Message ----- From: "DragonWize" <dragonwize@gmail.com> To: <development@drupal.org> Sent: Thursday, January 17, 2008 8:00 PM Subject: Re: [development] Think there's a security problem in your module?Here's what to do. [...]
b) You *immediately* send email to security@drupal.org about it to let us know.
Agreed. This easy to understand, perform and educate. Maybe also have other ways for developers & users alike to the security team that doesn't make them have to remember the email address. The more ways to contact them with important information the better. [...]
@DragonWize: as I said before, your input on this thread is very welcome. I still disagree that reviewing and further improving the patches for security issues should be done directly under public version control. Seems like there's a little bit of an impasse here, and I'm not sure what to do to further convince you why I think it's a bad idea. I think I've been pretty clear about what I'm sure of and what we can't possibly know. All you've done in reply is assert that you don't think our concerns are valid (without evidence, which neither side has) and assert that you think maintainers would feel more comfortable doing it your way (which doesn't address the security team's concerns and just further adds to the list of things we don't know -- are maintainers actually more comfortable doing it your way or not?). I'll make my own assertion to add to the mix: the reason so many developers aren't following this process isn't because it's so burdensome and difficult for them that they willingly chose to ignore it, it's because so few people actually know this is the process the security team wants people to follow, given a basically complete lack of detailed documentation or awareness about it. That said, there have definitely been some good ideas about possible changes to the procedure here. Furthermore, this thread has sparked a big discussion about the process and generated a lot more awareness, which already made the thread incredibly valuable. On Jan 17, 2008, at 11:00 AM, DragonWize wrote:
This will always be a challenge but helps if you have a marketable version of the information you are trying to get out to everyone.
I was *not* trying to "market" the process. ;) I was trying to explain it, step by step, in developer-speak, not "marketing-speak". In starting this thread, I acted on my own, not as an official representative of the security team (or the "education group" within the security team). This was not meant to be the final word, nor the only documented version of the process. There *is no* documented version of this process in as much detail, so I just wanted to write a first draft to spark discussion and raise awareness. I have succeeded on both counts. Now, the point is to either a) get everyone to agree this is the right process and carefully document it in the d.o handbooks (which anyone who wants to contribute could do, not necessarily the over- taxed security team itself), or b) make whatever modifications to the process we all think are worth making for the overall goal of a more secure Drupal ecosystem, and write up *that* process in the same way. Cheers, -Derek (dww) p.s. The security team is also discussing creating a mandatory announcement-only list for all users with a CVS account, so that we can more effectively "get developers on board" about this and other topics, without relying on the devel list.
@Derek: On 1/17/08, Derek Wright <drupal@dwwright.net> wrote:
@DragonWize: as I said before, your input on this thread is very welcome. Thank you.
I still disagree that reviewing and further improving the patches for security issues should be done directly under public version control. Seems like there's a little bit of an impasse here, and I'm not sure what to do to further convince you why I think it's a bad idea. I think I've been pretty clear about what I'm sure of and what we can't possibly know. All you've done in reply is assert that you don't think our concerns are valid (without evidence, which neither side has) and assert that you think maintainers would feel more comfortable doing it your way (which doesn't address the security team's concerns and just further adds to the list of things we don't know -- are maintainers actually more comfortable doing it your way or not?).
I have asserted my concerns are valid and you have asserted my concerns are valid but I have not said that everyone agrees with them ever. We don't know and I definitely am not the end source. So what do you if you do not know? You look at the possibilities and their outcomes and try to make an educated guess. Which is what I have done. I have showed both possible possibilities of committing code and not committing code in my view to further help us make that educated guess. The only reason given in this thread to date for waiting to commit the code is because hackers watch the cvs log. And I have made as clear as I can that if they are watching the logs (which they most likely are, to what is extent is debatable) then they know when the security hole is committed which is long before the fix is committed. I can not make it any clearer that, IMHO, that reason is full of false hope. If you have another concrete reason why not committing code is beneficial please enlighten me (if you have already mentioned it , I am sorry for missing it)
I'll make my own assertion to add to the mix: the reason so many developers aren't following this process isn't because it's so burdensome and difficult for them that they willingly chose to ignore it, it's because so few people actually know this is the process the security team wants people to follow, given a basically complete lack of detailed documentation or awareness about it.
Agreed as I noted in my last email. But I also believe that when you are trying to educate a large group of people that it is much more effective to teach them and for them to remember a simple 1 or 2 step process than a 12 step process riddled with a lot of dos and don'ts.
I was *not* trying to "market" the process. ;) I was trying to explain it, step by step, in developer-speak, not "marketing-speak".
This is a matter of vocabulary. Marketing or advertising something is a form of education. This is the way in which I have used the term. In that manner you were marketing it.
Now, the point is to either a) get everyone to agree this is the right process and carefully document it in the d.o handbooks (which anyone who wants to contribute could do, not necessarily the over- taxed security team itself), or b) make whatever modifications to the process we all think are worth making for the overall goal of a more secure Drupal ecosystem, and write up *that* process in the same way.
Again another form of education or marketing if you will. Education is definitely needed in many forms. In that respect I think there needs to be a simple more marketable form that we can easily disseminate to contributers every where they are found in addition to d.o handbook pages with full descriptions of the the process and FAQ. Thank you for your time, -- Alan Doucette Koi Technology, LLC www.KoiTech.net
On Jan 17, 2008, at 1:07 PM, DragonWize wrote:
if they are watching the logs (which they most likely are, to what is extent is debatable) then they know when the security hole is committed which is long before the fix is committed. I can not make it any clearer that, IMHO, that reason is full of false hope.
There's a *huge* volume of existing code. New hackers are coming around all the time, but I doubt they're going to be able to immediately audit everything all at once. I suspect (but have no proof) that many are looking at changes, and starting to methodically search for problems, but haven't yet completely grokked the entire existing codebase. Maybe I'm just being overly optimistic about this bit of security by obscurity. ;) I'm guessing that in the cost/ benefit analysis of a hacker, it's better to really focus on the most popular contribs first, since exploits you might find will have a better "payoff". It does far more good to watch views, cck, pathauto, etc, with everything you've got, than to wade through the vast swamp of modules that are only used by dozens, not thousands of sites. Either way, I maintain it still does *not* hurt to avoid calling any public attention at all to a known vulnerability, until there's an official release that fixes it which all of your users could immediately upgrade to as soon as they're notified. The "good" users can't upgrade anyway, and if nothing else, it means sites are only vulnerable to the sophisticated, rich hackers, not the "half-wit" script-kiddies that are trying to exploit lower hanging fruit as it streams by their RSS readers. If the security team had many more resources and a lot more automated/ streamlined process (which I think webchick's proposal gets us much closer to), we could potentially move to a weekly rhythm for security updates. Every wednesday would become security day, and anything fixed in the previous week would be disclosed and released. Drupal site maintainers would get used to running "drush pm update"[1] for all their sites a few times throughout near the end of the day on wednesday. :) Most people could just setup cron jobs to do that, if they really wanted (though module maintainers would have to become even more aware and careful about how they handle release management for their contributions, and conquer the (in the end, relatively simple) art of making sure you commit the right patches to the right branch(es) at the right time in the right order. -Derek (dww)
Just my 2 cents. Thoughts?
Just throwing this out there... I don't even know if this is technically feasible, but is an attempt to bridge concerns of the two parties, since both of them have a point. I think it's clear that the end goals of the security team are: * Don't let the bad guys know about security bugs before the good guys. * Coordinate security releases on predictable schedules so that site admins don't need to carry a beeper. * Ensure all security-related problems are dealt with in the proper way: accompanying SAs, etc. And the concerns of some of the developers in this thread are: * I want to use the same process to fix these types of bugs that I do any other types of bugs. * I have no way to test my module to ensure that it works with the security patch applied. * I know my module better than the security team does. So let's try this: The Security Team sets up a cvs-security.drupal.org. All security members are given checkout/commit access to it, and no one else (by default). There are two directories: drupal/ : for core (constantly mirrored) modules/ : for contributed modules Additionally, the node_access module @ security.drupal.org is tweaked so that it can allow access to specific issues for individual users. Workflow is: 1. Developer discovers security hole in their module. 2. Developer notifies security@drupal.org. 3. Security team takes a copy of the currently vulnerable code and checks it into cvs-security.drupal.org at modules/foobar. Creates a CVS account for developer and gives them access to their module's directory only. 4. Security team creates a user for them at security.drupal.org, and an issue that only the developer and the rest of the security team have access to, in order to act as the central place to test/discuss patches to fix the issue. 5. Developer and security team use the normal contributed workflow to get the patch created, reviewed, applied, and tested. 6. Once fix is deemed acceptable, the normal SA process ensues. This approach brings several benefits: * Anonymous users (including blackhats) can't see the security-related commits flinging back and forth, nor read the discussion leading up to the fixes. * The security team can work in a transparent way, and increase education/mentorship of developers, while not giving blackhats any hints about what's going on. * Developers can use the same processes that they're familiar with. * Developers can test exactly what code will be downloaded by their end users. No nasty surprises like Drupal 5.4->5.5. We can even increase the number of security team members to include those who /just/ do QA testing on a release before it's pushed out. * Releases can continue to be pushed out twice a month on predictable, regular intervals, making site admin lives much easier. Seems to satisfy all concerns. Thoughts? -Angie
On Jan 17, 2008, at 7:41 PM, Angela Byron wrote:
I don't even know if this is technically feasible
Completely.
The Security Team sets up a cvs-security.drupal.org.
<bikeshed> cvs.security.drupal.org? </bikeshed>
Additionally, the node_access module @ security.drupal.org is tweaked so that it can allow access to specific issues for individual users.
project_issue can do this itself. ;) 'access own issues'.
1. Developer discovers security hole in their module. 2. Developer notifies security@drupal.org.
or creates an issue @ security.drupal.org.
3. Security team takes a copy of the currently vulnerable code and checks it into cvs-security.drupal.org at modules/foobar. Creates a CVS account for developer and gives them access to their module's directory only.
Easy. We already have separate projects on sec.d.o for all modules that have had security issues. Could use the same CVS access for cvs- sec.d.o -> sec.d.o as we do with cvs.d.o -> d.o. In fact, we could automate that each cvs account holder on d.o has an account in a separate CVS repo on cvs.sec.d.o. The CVS access tab on project nodes would be used to generate accounts in the CVSROOT/passwd files for each private repo.
4. Security team creates a user for them at security.drupal.org, and an issue that only the developer and the rest of the security team have access to, in order to act as the central place to test/ discuss patches to fix the issue.
Trivial. We could ensure that all users with CVS accounts on d.o also have limited access user accounts on sec.d.o that can at least submit issues for their own projects and access to their own projects CVS repos. We could have an automated solution to keep the project nodes in sync between the 2 sites.
5. Developer and security team use the normal contributed workflow to get the patch created, reviewed, applied, and tested. 6. Once fix is deemed acceptable, the normal SA process ensues.
Sounds great.
Seems to satisfy all concerns. Thoughts?
I love it! All the benefits you list are true, and there are others...
We can even increase the number of security team members to include those who /just/ do QA testing on a release before it's pushed out.
Additionally, we could: * Setup the automated simpletest infrastructure that's integrated with project_issue. * Pound more contributed modules with regression tests. * Start to incorporate generation of simpletests into the security review/fix workflow. * Try to write generic simpletests that would work against any (or at least different classes of). For example, write tests that generate both random and specifically malicious content that all output filtering modules are fed. Not only is it all technically feasible, it wouldn't even be *that* much work to setup the initial proposal you described, and at least the automated simpletests for the core repo on cvs.sec.d.o. Any objections? Any volunteers? Thanks! -Derek
Not only is it all technically feasible, it wouldn't even be *that* much work to setup the initial proposal you described, and at least the automated simpletests for the core repo on cvs.sec.d.o.
Oh, wow! That was totally not the "ARE YOU ON *CRACK*??" response I was expecting. :) Ok, so. New and improved workflow! 1. Security hole found! OMG! 2. Head to security.drupal.org and login (same as d.o credentials) 3. Post an issue informing the security team about the bug (they're emailed automatically on new issues). This issue is private to only you and the security team members. 4. Work with the Security Team in the issue to come up with/test a patch that fixes the bug. 5. Once a consensus is reached, commit it to your module on cvs.security.drupal.org. Run through your normal testing procedures and make sure things look good. 6. Follow the Security Team's instructions on how to go about creating/announcing the release. Sound about right? Looks like, implementation-wise, we need: 1. Script to sync up non-security team, CVS account-holding d.o users and make them s.d.o users with only basic privileges (create issues/access own issues) 2. Script (or something) to sync CVS / CVS users between cvs.drupal.org and cvs.security.drupal.org. 3. Script to sync d.o projects / owners / maintainers with s.d.o projects / owners / maintainers. So.. lots of synching. But in the end, I think this actually *saves* the Security Team tons of time, both at the outset (the developer is the one who initiates the process) and also in ongoing education (the team is no longer a "black box" where the developer is waiting for information but instead feeding out useful information to developers as the reviewing process is happening). Huge +1 to the automated testing stuff too, but probably best to start simple first. :)
Any objections? Any volunteers?
I'm willing to work with you (or someone) to do this synching stuff. I don't think I have the time/knowledge to do it alone. -Angie
On Jan 17, 2008, at 11:49 PM, Angela Byron wrote:
New and improved workflow! ... Sound about right?
Yes, sounds great. Almost incorporates all of fgm's concerns/input about using the same tools for a maintainer's usual workflow, without it all happening publicly. Seems like it should satisfy DragonWize and David Metzler's concerns about easy collaboration with other project maintainers, transparency, using revision control, beta testers, and having familiar tools. Certainly satisfies me, and I'm pretty sure the rest of the security team would agree.
Looks like, implementation-wise, we need:
1. Script to sync up non-security team, CVS account-holding d.o users and make them s.d.o users with only basic privileges (create issues/access own issues)
Right. New role on sec.d.o, and a script to sync all users in the "CVS users" role on d.o over to sec.d.o.
2. Script (or something) to sync CVS / CVS users between cvs.drupal.org and cvs.security.drupal.org.
The script to sync CVS could just be a fine grained, manually triggered, 1 way rsync from different directories in cvs.d.o to the different private repos on cvs.sec.d.o. Users would just be to dump the CVS access tab for each project on sec.d.o into the CVSROOT/passwd file for that project's private repo on cvs.sec.d.o.
3. Script to sync d.o projects / owners / maintainers with s.d.o projects / owners / maintainers.
Seems like pretty trivial stuff here. I don't even care about all the fields. Title, shortname, owner, cvs access tab, and perhaps body would do. The rest is fluff as far as sec.d.o is concerned.
So.. lots of synching. But in the end, I think this actually *saves* the Security Team tons of time, both at the outset (the developer is the one who initiates the process) and also in ongoing education (the team is no longer a "black box" where the developer is waiting for information but instead feeding out useful information to developers as the reviewing process is happening).
Yes. After the initial work to setup the new system, I think this will hugely ease the job of the sec team, and will significantly aid in the education aspects of our work. We can even try to get the module maintainers to write the first drafts of the SAs for a change, and be more directly involved in editing/reviewing those, too. ;)
Huge +1 to the automated testing stuff too, but probably best to start simple first. :)
Agreed. One step at a time, but that's definitely low hanging fruit as soon as the basics are up, working, and documented.
I'm willing to work with you (or someone) to do this synching stuff. I don't think I have the time/knowledge to do it alone.
As always, webchick, I'd love to work with you on this. I'd just be thrilled to see some other hands show up. You and I end up working together on a lot of improvements to Drupal on our own (in spite of our nearly constant efforts to try to get others involved)... Cheers, -Derek (dww)
On Friday, 18. January 2008, Derek Wright wrote:
On Jan 17, 2008, at 11:49 PM, Angela Byron wrote:
2. Script (or something) to sync CVS / CVS users between cvs.drupal.org and cvs.security.drupal.org.
The script to sync CVS could just be a fine grained, manually triggered, 1 way rsync from different directories in cvs.d.o to the different private repos on cvs.sec.d.o.
Oh, wow. I didn't expect distributed VCS methodologies to get into Drupal this fast... expected different repositories for each project more like in three years or so :P
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jakob Petsovits schrieb:
On Friday, 18. January 2008, Derek Wright wrote:
On Jan 17, 2008, at 11:49 PM, Angela Byron wrote:
2. Script (or something) to sync CVS / CVS users between cvs.drupal.org and cvs.security.drupal.org. The script to sync CVS could just be a fine grained, manually triggered, 1 way rsync from different directories in cvs.d.o to the different private repos on cvs.sec.d.o.
Oh, wow. I didn't expect distributed VCS methodologies to get into Drupal this fast... expected different repositories for each project more like in three years or so :P
Yeah, I am quite overwhelmed too. I think this is cannons on sparrows. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHkI9nfg6TFvELooQRAgF+AKCmjiU5a6FIyO9W73b1nP9YIv+ktwCcDFah KLC83ZgtQGY+4ANL9oWWFuU= =JSY9 -----END PGP SIGNATURE-----
On Jan 18, 2008, at 3:25 AM, Jakob Petsovits wrote:
Oh, wow. I didn't expect distributed VCS methodologies to get into Drupal this fast... expected different repositories for each project more like in three years or so :P
On Jan 18, 2008, at 3:37 AM, Gerhard Killesreiter wrote:
Yeah, I am quite overwhelmed too. I think this is cannons on sparrows.
*sigh* I guess neither of you actually read what I wrote. Lemme quote the part you seem to have skimmed, and I'll add emphasis for clarity: On Jan 18, 2008, at 1:08 AM, Derek Wright wrote:
IF we wanted to get REALLY CRAZY, we COULD START to EXPERIMENT with distributed revision control ... to help manage private repos for _SOME_ of the projects on SEC.d.o. ...
Could work great ... but that would depend at the very least on people helping to complete the to-do list here:
http://groups.drupal.org/node/8102
and then implementing other versioncontrol API backend modules for whatever tool(s) they wanted to be able to use for this.
This could certainly take 3 years or so, depending on who has this itch and is willing/able to scratch it. Forget I even mentioned this. It was an off-the-cuff comment about "someday how it could all work". If you haven't learned by now, I tend to get big dreams, write them all up into the Grand Plan, then figure out what's realistic, and start finding a way to make it happen, at least the parts of the Grand Plan I personally care about. This particular detail of how I've been fleshing in webchick's proposal is at the very bottom of the list of things I care about, so don't expect me to work on it anytime soon, if ever. CVS + rsync + patches in the private issue queues are all I care about for now. It's so reassuring to know that people will always focus on the least important aspects of what I write and bend them all out of shape and proportion. ;) Cheers, -Derek (dww)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Derek Wright schrieb:
On Jan 18, 2008, at 3:37 AM, Gerhard Killesreiter wrote:
Yeah, I am quite overwhelmed too. I think this is cannons on sparrows.
*sigh* I guess neither of you actually read what I wrote. Lemme quote the part you seem to have skimmed, and I'll add emphasis for clarity:
On Jan 18, 2008, at 1:08 AM, Derek Wright wrote:
IF we wanted to get REALLY CRAZY, we COULD START to EXPERIMENT with distributed revision control ... to help manage private repos for _SOME_ of the projects on SEC.d.o. ...
Could work great ... but that would depend at the very least on people helping to complete the to-do list here:
http://groups.drupal.org/node/8102
and then implementing other versioncontrol API backend modules for whatever tool(s) they wanted to be able to use for this.
This could certainly take 3 years or so, depending on who has this itch and is willing/able to scratch it.
Forget I even mentioned this. It was an off-the-cuff comment about "someday how it could all work". If you haven't learned by now, I tend to get big dreams, write them all up into the Grand Plan, then figure out what's realistic, and start finding a way to make it happen, at least the parts of the Grand Plan I personally care about.
Maybe you shouldn't post that Grand Plan to a public mailing list and make people expecting things. This will just make the current situation look much worse to them than it really is.
This particular detail of how I've been fleshing in webchick's proposal is at the very bottom of the list of things I care about, so don't expect me to work on it anytime soon, if ever. CVS + rsync + patches in the private issue queues are all I care about for now.
I am also referring to this as "cannons on sparrows". We shouldn't just start to invest a great deal of time into something because a single person refuses to understand security concepts. I fully agree that your proposal has merit and would improve the workflow. But would the amount of time that needs to be poured into justify the degree of improvement? You probably guess where I deem your time better spent...
It's so reassuring to know that people will always focus on the least important aspects of what I write and bend them all out of shape and proportion. ;)
That's why mailing lists are mailing lists... Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHkJgffg6TFvELooQRAseaAJ9DSXypt0zpSsyrxF6DU09v8LUYFACgr6qJ oY3bGz2lIFNn2piB9+BfFOQ= =4HaR -----END PGP SIGNATURE-----
On Jan 18, 2008, at 4:14 AM, Gerhard Killesreiter wrote:
Maybe you shouldn't post that Grand Plan to a public mailing list and make people expecting things.
It's an open source project. Once in a while, people respond to my publicly available grand plans and offer to help. Occasionally, they even follow through with those offers and actually do something productive. After close to 2 years of struggling, I'm finally getting more people involved in working on project*, CVS, infrastructure, etc.
We shouldn't just start to invest a great deal of time into something because a single person refuses to understand security concepts.
While we might disagree with some of their points, DragonWize and David Metzler (note: N>1) clearly understand security concepts. They (and probably others) just question some aspects of our workflow that neither side can prove conclusively. No offense, but the "just because a lone renegade refuses to understand why I'm clearly right" attitude is utterly unhelpful in this discussion, especially since (until now), everyone participating has been basically reasonable and respectful. That aside, the system proposed by webchick and elaborated by me would have a large number of improvements over the workflow we have now. I predict it will save significant time and resources in the near future (no more manually creating project nodes on sec.d.o, much less frequently creating the issues themselves, less often drafting the SAs, easier time managing and testing patches, less time tracking communication with the module authors since we won't have to manually paste emails into issues on sec.d.o, automated QA testing of core security patches, etc), regardless of whether or not the people who have disagreed with certain aspects of our current workflow will be more happy with it.
I fully agree that your proposal has merit and would improve the workflow. But would the amount of time that needs to be poured into justify the degree of improvement?
I think the benefits are huge, and the initial time that needs to be poured in is actually relatively small. Most of the tools already exist, support what we need them to do, and are well understood. It just depends on who volunteers to help to write some of the glue to tie it all together.
You probably guess where I deem your time better spent...
a) Feel free to help raise money for what you'd rather I was working on. b) Again, it seems you didn't read my message: On Jan 18, 2008, at 1:08 AM, Derek Wright wrote:
As always, webchick, I'd love to work with you on this. I'd just be thrilled to see some other hands show up. You and I end up working together on a lot of improvements to Drupal on our own (in spite of our nearly constant efforts to try to get others involved)...
Cheers, -Derek
On 18.Jan.2008, at 07:14, Gerhard Killesreiter wrote:
But would the amount of time that needs to be poured into justify the degree of improvement?
If it creates a secure workflow process for reviewing security issues, then yes. And BTW Gerard, this
We shouldn't just start to invest a great deal of time into something because a single person refuses to understand security concepts.
Was completely unnecessary. This thread is not about Derek's or Alan's lack of security knowledge. They are questioning the workflow and that's why Angela's proposal is valuable. /liza
On Friday, 18. January 2008, Derek Wright wrote:
On Jan 18, 2008, at 3:25 AM, Jakob Petsovits wrote:
Oh, wow. I didn't expect distributed VCS methodologies to get into Drupal this fast... expected different repositories for each project more like in three years or so :P
On Jan 18, 2008, at 3:37 AM, Gerhard Killesreiter wrote:
Yeah, I am quite overwhelmed too. I think this is cannons on sparrows.
*sigh* I guess neither of you actually read what I wrote.
I didn't say "using a distributed VCS". I said "using distributed VCS methodologies", using CVS in this case. I'll try to be more silent next time.
On Jan 18, 2008, at 4:56 AM, Jakob Petsovits wrote:
I didn't say "using a distributed VCS". I said "using distributed VCS methodologies", using CVS in this case.
My mistake. Please accept my apology. Your enthusiasm and optimism should be encouraged.
I'll try to be more silent next time.
Please no. ;) I'm very sorry to have directly addressed you with parts of my last message. When I pointed to the todo list to get the versioncontrol API SoC project ready to deploy on d.o, it's surprisingly small given the huge task you completed. At your previous rate of progress, you'd easily be able to finish that list and add backends for the major RCSs in probably 3 months, not 3 years. That '3 year' comment was not directed at you, but a symptom of my at times embattled feelings when it seems few are responding to my pleas for help. But those feelings only come when I lose sight of the tremendous efforts that yourself, hunmonk, aclight, webchick, drewish, and a growing list of many others are already pouring into project* + CVS/RCS*. After witnessing the countless hours wasted on pointless flamewars about switching RCSs for Drupal, I'm incredibly grateful that you got the community within reach, instead of adding to the choir of complaints. Please continue to contribute to these and other efforts, and by all means, don't be silent. My sincere apologies and thanks, -Derek (dww)
On Saturday, 19. January 2008, Derek Wright wrote:
On Jan 18, 2008, at 4:56 AM, Jakob Petsovits wrote:
I'll try to be more silent next time.
[snip] Please continue to contribute to these and other efforts, and by all means, don't be silent.
Mmkay! :) Thanks to *you* and your immense contributions, j
As some pointed out, the one who reports a security issue and the module maintainer(s) should be more involved in the fixing process: 1- better communication and transparency between reporters, maintainers and sec team 2- less work for the sec team if the workflow is automated 3- leads to a quicker initial feedback from the sec team telling the reporter what to do, and preventing her from posting and advertising a fix in the issue queue or project page if she doesn't get a reply from security@drupal.org within the next hours... all of that of course is restricted to the sec team and ppl involved in each security issue. count me in too, but like DragonWize, not being able to lead. but if one can break things into smaller tasks, it'll be easier to give a hand. scor. On Jan 20, 2008 4:15 PM, Jakob Petsovits <jpetso@gmx.at> wrote:
On Saturday, 19. January 2008, Derek Wright wrote:
On Jan 18, 2008, at 4:56 AM, Jakob Petsovits wrote:
I'll try to be more silent next time.
[snip] Please continue to contribute to these and other efforts, and by all means, don't be silent.
Mmkay! :)
Thanks to *you* and your immense contributions, j
On Wed, 23 Jan 2008 11:47:34 +0000 "Stephane Corlosquet" <scorlosquet@gmail.com> wrote:
As some pointed out, the one who reports a security issue and the module maintainer(s) should be more involved in the fixing process: 1- better communication and transparency between reporters, maintainers and sec team
This sentence got my attention. Recently I had to deal with the sec team and the experience was not that satisfying. I'm very sorry to be missing the time for superior diplomacy because I'm very short on time so I'll go straight to the point. I'm referring to http://drupal.org/node/198162 My experience... There may be a bit difference in details to what actually happened, without changing the substance of the experience, I've no time to go through email and IRC logs to make a precise chronological report. - I tried to intercept people on IRC asking what to do. - nobody was able to point me to guideline to how to report a security issue, I had the impression no one was responsible for sec issues. - people even laughed at me when I said the problem may be deep into core - when I said that I thought that SQL injection could be exploited just on Postgresql, I received even more laugh. Later Heine[1] found a way to do privilege escalation with MySQL too. - even if I submitted a quick patch nearly contextually to the sec report there was a long lag between the public SA - security@drupal.org doesn't even send an automatic reply. That's terrible... I had to go to IRC to ask if the message was received. - after the sec team was informed I didn't get any news back, I had to insist to get an idea about when a SA was going to be issued, how they were planning to deal with the vulnerability etc... - missing transparency, having a patch ready it was really uncomfortable to decide if it was the right moment to disclose the problem autonomously or wait for an official response I tend to be forgiving in things related to personal character of people. I don't mind people to be opinionated or even rude, just as things get done the proper way. I tried to play nice even when I had to deal with these issues and behave the best I could considering the information I had. Insisting that the vulnerability was important (several high profile sites exposed) and trying to sync with sec team even if there was no official response. I even did some further autonomous research to see if other module could be involved. Some of the people I had to deal with absolutely didn't deal with the issue in a way that promoted responsible disclosure. I may had behaved like an asshole (I don't think so) but still, as I calmed down and manage the stuff at my best passing over "personal" opinions so I'd expect the same from the people on the other side. Transparency and a honest communication channel are vital to this kind of issues. It may had been a chance, bad luck, I don't want to point fingers to anyone. I'd just like to point to problems so that things may get better... and this should also say something about serious Postgresql support and DB knowledge. As a side note I think that due to the success of Drupal and its larger community of developers this policy is not anymore suitable for the project: The Drupal philosophy - Escape or filter when appropriate http://drupal.org/node/101495 on a larger and larger code base, with many newcomers "when appropriate" is a slimy concept and relying on db_query didn't show to be a "catch all" solution (not to mention XSS and other kind of niceness. Drupal API is its most valuable asset. Encapsulation makes an API more valuable. If people have to discover "when it is appropriate" the API becomes less valuable. If people can't understand when it is appropriate, it is risky [2]. [1] Heine did a great job and I hope he understood I really didn't enjoy to put pressure on him, but he was the only reasonable communication point I had with sec, and I had to communicate through his personal email address since nothing ever came back from security@ I couldn't even think if he was replying in the name of the sec team or not. [2] waiting for prepared statement since I love to pass nulls to the DB -- Ivan Sergio Borgonovo http://www.webthatworks.it
I blogged about unsatisfactory release processes for a patch I committed. Kieran took time to address my grievances and I unpublished my blog post so they would have an opportunity to put changes in place and wipe the egg away. Greg followed up by IRC and we agreed the whole thing could have gone differently if the security team had just thanked me and given me a date for the next round of SA notices. I think that's a good first step. Ivan Sergio Borgonovo wrote:
On Wed, 23 Jan 2008 11:47:34 +0000 "Stephane Corlosquet" <scorlosquet@gmail.com> wrote:
As some pointed out, the one who reports a security issue and the module maintainer(s) should be more involved in the fixing process: 1- better communication and transparency between reporters, maintainers and sec team
This sentence got my attention.
Recently I had to deal with the sec team and the experience was not that satisfying.
I'm very sorry to be missing the time for superior diplomacy because I'm very short on time so I'll go straight to the point.
I'm referring to http://drupal.org/node/198162
My experience... There may be a bit difference in details to what actually happened, without changing the substance of the experience, I've no time to go through email and IRC logs to make a precise chronological report.
- I tried to intercept people on IRC asking what to do. - nobody was able to point me to guideline to how to report a security issue, I had the impression no one was responsible for sec issues. - people even laughed at me when I said the problem may be deep into core - when I said that I thought that SQL injection could be exploited just on Postgresql, I received even more laugh. Later Heine[1] found a way to do privilege escalation with MySQL too. - even if I submitted a quick patch nearly contextually to the sec report there was a long lag between the public SA - security@drupal.org doesn't even send an automatic reply. That's terrible... I had to go to IRC to ask if the message was received. - after the sec team was informed I didn't get any news back, I had to insist to get an idea about when a SA was going to be issued, how they were planning to deal with the vulnerability etc... - missing transparency, having a patch ready it was really uncomfortable to decide if it was the right moment to disclose the problem autonomously or wait for an official response
I tend to be forgiving in things related to personal character of people. I don't mind people to be opinionated or even rude, just as things get done the proper way.
I tried to play nice even when I had to deal with these issues and behave the best I could considering the information I had. Insisting that the vulnerability was important (several high profile sites exposed) and trying to sync with sec team even if there was no official response. I even did some further autonomous research to see if other module could be involved. Some of the people I had to deal with absolutely didn't deal with the issue in a way that promoted responsible disclosure.
I may had behaved like an asshole (I don't think so) but still, as I calmed down and manage the stuff at my best passing over "personal" opinions so I'd expect the same from the people on the other side.
Transparency and a honest communication channel are vital to this kind of issues.
It may had been a chance, bad luck, I don't want to point fingers to anyone. I'd just like to point to problems so that things may get better... and this should also say something about serious Postgresql support and DB knowledge.
As a side note I think that due to the success of Drupal and its larger community of developers this policy is not anymore suitable for the project: The Drupal philosophy - Escape or filter when appropriate http://drupal.org/node/101495 on a larger and larger code base, with many newcomers "when appropriate" is a slimy concept and relying on db_query didn't show to be a "catch all" solution (not to mention XSS and other kind of niceness. Drupal API is its most valuable asset. Encapsulation makes an API more valuable. If people have to discover "when it is appropriate" the API becomes less valuable. If people can't understand when it is appropriate, it is risky [2].
[1] Heine did a great job and I hope he understood I really didn't enjoy to put pressure on him, but he was the only reasonable communication point I had with sec, and I had to communicate through his personal email address since nothing ever came back from security@ I couldn't even think if he was replying in the name of the sec team or not.
[2] waiting for prepared statement since I love to pass nulls to the DB
On Jan 23, 2008 12:33 PM, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
On Wed, 23 Jan 2008 11:47:34 +0000 "Stephane Corlosquet" <scorlosquet@gmail.com> wrote:
As some pointed out, the one who reports a security issue and the module maintainer(s) should be more involved in the fixing process: 1- better communication and transparency between reporters, maintainers and sec team
This sentence got my attention.
Recently I had to deal with the sec team and the experience was not that satisfying.
A simple +1 to Stephane's comment wold have sufficed. He-said/she-said is rarely beneficial to either party. The message is clear: the security team needs to scale better and have better communication with the issue reporters and module owners. It would be nice if you could respond with some feedback about Webchick/Dww's proposed process. They've laid out a process to help get improve the communcation and the security team is taking steps to evaluate, improve, and implement it.
As a side note I think that due to the success of Drupal and its larger community of developers this policy is not anymore suitable for the project: The Drupal philosophy - Escape or filter when appropriate http://drupal.org/node/101495 on a larger and larger code base, with many newcomers "when appropriate" is a slimy concept and relying on db_query didn't show to be a "catch all" solution (not to mention XSS and other kind of niceness. Drupal API is its most valuable asset. Encapsulation makes an API more valuable. If people have to discover "when it is appropriate" the API becomes less valuable. If people can't understand when it is appropriate, it is risky [2].
I'm not sure I understand this criticism. The problem you reported was specific to contrib modules which passed in raw data even though the API docs say to pass in an array of integers. Heine made the call to fix this inside the API so that it was liberal in accepting any data and would do the filtering to prevent the holes as much as possible. That sounds like it does what you want. Can you state in a positive manner what change you would like to see? Do you feel that prepared statements will be the solution to this problem? As much as possible the Drupal project has used so far is to have security as a side effect of proper use of the API: i.e. if you use the DatabaseAPI, the Localization system, or FAPI you also also happen to have SQL Injection, XSS, and CSRF protection for free. It's quite genius in my opinion and I have a hard time of thinking how to make it better. We still have two major areas of weakness, IMO. First is in displaying data from and node/user/comment and in theming where confusion about $node->field_something[0][value] vs. $node->field_something[0][view] can lead to unintended security holes. The second major area of weakness, is in education about the existence of the APIs and the _proper_ way to use them. Thanks, Greg -- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg
On Wed, 23 Jan 2008 15:04:56 -0200 "Greg Knaddison - GVS" <Greg@GrowingVentureSolutions.com> wrote:
call to fix this inside the API so that it was liberal in accepting any data and would do the filtering to prevent the holes as much as possible. That sounds like it does what you want.
Can you state in a positive manner what change you would like to see? Do you feel that prepared statements will be the solution to this problem?
It is just a db_query on steroids. If you still compose the prepared statement dynamically... you still get the chance to inject code but you don't cast in php, you should be able to use NULL (great once you start to use pk/fk) and you make the code of db_query much simpler making it easier to make it smarter. Improving the abstraction of the DB layer should avoid most chances to get into trouble since queries will be built with prepackaged static parts and parameters, not anymore assembling strings in the modules.
As much as possible the Drupal project has used so far is to have security as a side effect of proper use of the API: i.e. if you use
[snip]
holes. The second major area of weakness, is in education about the existence of the APIs and the _proper_ way to use them.
People make errors and if they have to take care about what is the proper way to use the API they will make more errors. If it is clearer what they can rely on it makes stuff easier and simpler, if the things they can rely on are more than the one with a red button with "self destruction" written on it would be even better. function A accept int may mean: a) function a will work just with int, explode in errors otherwise b) function a will break silently with anything but int c) if you let rubbish get in you may be exposed to a SQL injection I think a) is better than b) and may be a way to avoid c) earlier; at least things will reach the log and you've a chance to fix stuff. Or maybe it is just a matter of making the input type parameters in the docs <blink>. As for a positive contribution to the sec process and for the people asking if anything was really screwed I'd suggest: - kill the security@drupal.org email if you can't guarantee it is a reliable channel (spam/whatever) - open a web form (I know there is one) and make it send an autoreply with instructions and greetings immediately. The point is: offer just things you know will work. Reply promptly with no effort. Lower the chances people don't know what to do next. - just offer *official* reply through official channels, so that personality don't kick in. - be aware that once you decide to do voluntary job and be part of a community you take the responsibilities that come with *your choice*. Being part of the sec team of a successful project as Drupal is like volunteering as a paramedic. Projects do get judged by their security response too, it is also a matter of image. Image is important for getting more dev involved. - keep the reporter informed [1] - Establish a code of conduit for sec team communications: You're dealing with someone you don't know that is aware of a security problem. You don't know his personality, you don't know his skills, you want information and hopefully collaboration: guide and pamper the reporter. The consequences of an unexpected behaviour may have a high cost in terms of sec and image. A code of conduit may make dealing politely with the issue nearly automatic, reducing the chances of frictions and the time required to formulate answers and make easier to delegate responsibility to reply if the one in charge is busy and the one left don't have the gift of diplomacy. Thanks to Derek who gave me just one more kick in my ass and woke me up from my dream, giving me one more opportunity to test if finding the positive side of all negative experiences is a rewarding hobby and unconsciously reminding me that computers are used by people and taking care of the human factor in security is a big slice of the equation and it is worth to insist on it. [1] this should address also the problems related to how to manage disclosures and how to fix the issues in a more elastic way even if you still may have a "preferred" or "suggested" way to deal with security -- Ivan Sergio Borgonovo http://www.webthatworks.it
On Jan 23, 2008 9:27 PM, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
On Wed, 23 Jan 2008 15:04:56 -0200 "Greg Knaddison - GVS" <Greg@GrowingVentureSolutions.com> wrote:
call to fix this inside the API so that it was liberal in accepting any data and would do the filtering to prevent the holes as much as possible. That sounds like it does what you want.
Can you state in a positive manner what change you would like to see? Do you feel that prepared statements will be the solution to this problem?
It is just a db_query on steroids. If you still compose the prepared statement dynamically... you still get the chance to inject code but you don't cast in php, you should be able to use NULL (great once you start to use pk/fk) and you make the code of db_query much simpler making it easier to make it smarter.
Improving the abstraction of the DB layer should avoid most chances to get into trouble since queries will be built with prepackaged static parts and parameters, not anymore assembling strings in the modules.
This will not happen until the DB layer is abstracted via PDO or some other means. Talk to Crell (Larry Garfield) about his efforts in that direction (not before Drupal 7).
People make errors and if they have to take care about what is the proper way to use the API they will make more errors.
Have you checked this page and the child pages under it? http://drupal.org/writing-secure-code If they need improvement, please chip in.
As for a positive contribution to the sec process and for the people asking if anything was really screwed I'd suggest:
- kill the security@drupal.org email if you can't guarantee it is a reliable channel (spam/whatever)
It is reliable, but moderated. The team does not get anything from it unless someone check the queue and moderate it. Again, we are short of hands. - open a web form (I know there is one) and make it send an autoreply
with instructions and greetings immediately. The point is: offer just things you know will work. Reply promptly with no effort. Lower the chances people don't know what to do next.
Good suggestion. Copying the security list.
- just offer *official* reply through official channels, so that personality don't kick in.
At present all replies are written by humans. But an auto-reply is an idea worth considering. - be aware that once you decide to do voluntary job and be part of
a community you take the responsibilities that come with *your choice*. Being part of the sec team of a successful project as Drupal is like volunteering as a paramedic. Projects do get judged by their security response too, it is also a matter of image. Image is important for getting more dev involved. - keep the reporter informed [1] - Establish a code of conduit for sec team communications: You're dealing with someone you don't know that is aware of a security problem. You don't know his personality, you don't know his skills, you want information and hopefully collaboration: guide and pamper the reporter. The consequences of an unexpected behaviour may have a high cost in terms of sec and image. A code of conduit may make dealing politely with the issue nearly automatic, reducing the chances of frictions and the time required to formulate answers and make easier to delegate responsibility to reply if the one in charge is busy and the one left don't have the gift of diplomacy.
One more thing, for you and everyone else out there: Many of the queries we get are "my site was hacked into, please help". In 90% of the cases, it is not a Drupal problem at all, but many other attack vectors (writable directories to the web server, an intrusion via FTP or ssh, other applications installed, other accounts on the server, ...etc.) We are drafting a FAQ page for this, so as to decrease the load, and point the people to it via a URL. If you can help with this, email me off list. -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting.
On Wed, 23 Jan 2008 21:56:07 -0500 "Khalid Baheyeldin" <kb@2bits.com> wrote:
People make errors and if they have to take care about what is the proper way to use the API they will make more errors.
Have you checked this page and the child pages under it?
If they need improvement, please chip in.
Pointing out that API should be used in the "proper way" was inspirational for me too. They look mostly a general guide. What I can read in the documents sounds like "you've to be careful and the places where you *may* have to be careful are a, b and c". People don't read docs, if you're lucky enough they read docs they want things that are easy to understand and remember. They read docs just when they strictly need them and there are more chances they will consult the api reference rather than a general guide about making code secure. Lacking a clear boundary between safe and unsafe functions people have to think. The few people that really enjoy to think, prefer to think tackling the problem they chose, not the "marginal stuff". Now make it more clear that if in the docs of the function you wrote array of int *it is up to the module writer* to pass an array of int. duck typing doesn't make it easy to make things explode in errors ASAP before it is too late without putting extra code down the path. Once you've to put extra code down the path to "explode in errors", just put extra code that filter at the cost of duplication. But still if there is a chance in API to write stuff that will explode in errors if input is not in the right format in spite of passing it down, it would be better. If a function filter input by its own make it clear, if some parameter disable filtering in a way it could be dangerous for security, make it clear. http://api.drupal.org/api/function/l/5 The risk is you're offering a map of functions that don't offer filtering, people will just download contrib and grep through it looking for the functions marked "not safe". I do not have any stats on this. Similar thread about disclosure just passed. If this is not acceptable write in the front page of the api that developers should look twice at the input parameters of functions. That's for simple types and SQL injection. For XSS I'd make more explicit that some functions filter some do not.
As for a positive contribution to the sec process and for the people asking if anything was really screwed I'd suggest:
- kill the security@drupal.org email if you can't guarantee it is a reliable channel (spam/whatever)
It is reliable, but moderated. The team does not get anything from it unless someone check the queue and moderate it.
Again, we are short of hands.
A form can offer advantages a mailing list does not. Including a way to filter spam and all requests for assistance in security issues that don't pertain to the sec team. Add some drop down, put a text around it saying it is not the right place etc... You can turn it into a private issue queue/ticketing system easier and no private email and such... the reply will be the one of the sec team, no matter who is in charge. A form can offer immediate feedback if everything went OK. Email can get lost, even your autoreply. Still send the autoreply, people prefer to read emails and they can keep a copy of the instructions.
- open a web form (I know there is one) and make it send an autoreply
with instructions and greetings immediately. The point is: offer just things you know will work. Reply promptly with no effort. Lower the chances people don't know what to do next.
Good suggestion. Copying the security list.
- just offer *official* reply through official channels, so that personality don't kick in.
At present all replies are written by humans. But an auto-reply is an idea worth considering.
Not only an autoreply... but some forms to be filled by sec team to keep the poster informed. eg. - someone did really read what you wrote - we couldn't replicate the problem - we confirm the problem - please, send a POC - we are going to address the problem: fixing the module, fixing core,... - we expect a fix to get in, be published in.... This will have a lot of good side effects including:
- Establish a code of conduit for sec team communications: You're dealing with someone you don't know that is aware of a security problem. You don't know his personality, you don't know his skills, you want information and hopefully collaboration: guide and pamper the reporter. The consequences of an unexpected behaviour may have a high cost in terms of sec and image. A code of conduit may make dealing politely with the issue nearly automatic, reducing the chances of frictions and the time required to formulate answers and make easier to delegate responsibility to reply if the one in charge is busy and the one left don't have the gift of diplomacy.
You can build up 4 or 5 prepared forms for replying... I think you'd have more experience in what people are asking to get a list of prepared forms. I think one of the FAQ is when are you going to release a SA, the other 2 more frequent should be: did you get my message?, do you confirm there is a sec problem? Just speculating... and these things could have prepackaged answers. Plus you're halfway to have a workflow.
One more thing, for you and everyone else out there:
Many of the queries we get are "my site was hacked into, please help". In 90% of the cases, it is not a Drupal problem at all, but many other attack vectors (writable directories to the web server, an intrusion via FTP or ssh, other applications installed, other accounts on the server, ...etc.)
We are drafting a FAQ page for this, so as to decrease the load, and point the people to it via a URL.
Unless there are things that are strictly related about how drupal is done I'd point to all the good material out there about general security. You'd generally point to better material than what you could generally write by yourself and you save the time to write it and keep it updated. Other than stuff related to coding for dev and how to set writing permissions on /files and settings.php and some advice if you've to deal with web designer accessing templates I can't think of anything that is suited to administrators and it is peculiar to drupal. The first good advice that doesn't require too much culture to be managed and decide upon is put down the site if you can, change the passwords (even if this is not going to save your ass for long), backup, watch the logs. Everything else is going to take too deep understanding, it offers too many options etc... People that have a clue will go further without any extra help. People that don't have a clue can't build up a culture on forensic, incident management... when it is too late and anyway it is stuff that goes beyond drupal. There is a lot of docs that somehow hides what's peculiar to drupal even eg. for cvs stuff and patch. -- Ivan Sergio Borgonovo http://www.webthatworks.it
On Jan 18, 2008 5:49 AM, Angela Byron <drupal-devel@webchick.net> wrote:
Not only is it all technically feasible, it wouldn't even be *that* much work to setup the initial proposal you described, and at least the automated simpletests for the core repo on cvs.sec.d.o.
Oh, wow! That was totally not the "ARE YOU ON *CRACK*??" response I was expecting. :)
Ok, so. New and improved workflow!
1. Security hole found! OMG! 2. Head to security.drupal.org and login (same as d.o credentials) 3. Post an issue informing the security team about the bug (they're emailed automatically on new issues). This issue is private to only you and the security team members. 4. Work with the Security Team in the issue to come up with/test a patch that fixes the bug.
I like the process up to here. It helps the contrib maintainers to understand the process. It would need serious testing to make sure that we don't accidentally leak more information than necessary.
5. Once a consensus is reached, commit it to your module on cvs.security.drupal.org. Run through your normal testing procedures and make sure things look good.
I don't see how this adds much more value over: wget http://example.com/path_to_patch patch -p0 < security_patch_revision_3.patch But, if you and dww both really like this and want to work on it I certainly won't stand in the way. It seems lower value to me but I am not in charge of your schedules.
6. Follow the Security Team's instructions on how to go about creating/announcing the release.
Yes, please. Regards, Greg -- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg
Greg Knaddison - GVS wrote:
5. Once a consensus is reached, commit it to your module on cvs.security.drupal.org. Run through your normal testing procedures and make sure things look good.
I don't see how this adds much more value over:
wget http://example.com/path_to_patch patch -p0 < security_patch_revision_3.patch
But, if you and dww both really like this and want to work on it I certainly won't stand in the way. It seems lower value to me but I am not in charge of your schedules.
I'm definitely not married to it... This was just an attempt to address the criticism that it's hard to test *exactly* what the end users would be downloading once the security release is created. But you're right that patch -p0 certainly does the trick. :) Removing this step would eliminate one sync script that needs to be written, the overhead required for management of a separate CVS repository, and doesn't detract at all from the benefits of an open dialog with developer participation in fixing the actual issue itself. I'm +1 to its removal, but defer to dww since he knows a lot better than me (or probably most of us ;)) what would be involved here, and how much work it would actually cost/save. -Angie
On Jan 18, 2008, at 12:14 PM, Angela Byron wrote:
I'm +1 to its removal, but defer to dww since he knows a lot better than me (or probably most of us ;)) what would be involved here, and how much work it would actually cost/save.
I don't care. Certainly for phase 1 we can live without. I think everyone understands patches in the issue queue, and many of the benefits (including PIFT ("project issue file testing" -- the automated sending of .patch and .diff files to a simpletest server)) would still work without it. It doesn't let us do automated testing *all* of the security-related patches for a given release of core *at the same time*, to make sure they don't break each other in any interesting and unexpected ways. But, we've made it this far without such automated tests, we can live longer without them (though, sadly, the track record on the recent core security releases has been pretty bad in terms of QA, and we've had to rev "whoops, sorry we broke that" releases a lot more often than I think anyone would like). That said, if I wasn't spending my time defending my ideas on this list, I could probably whip up the CVS rsync code in a few hours. The code to dump a CVSROOT/passwd file based on the data in the cvs access tab is also a few hour job at most, that one's actually more like 1 hour. So, it's not like it would have to take weeks of work to get the per-project private CVS repos working. Regardless, I can't answer the "how much work would it actually save" question. It basically boils down to how likely is it that developers would use it, how much additional confusion/potential for mistakes would it introduce, and how helpful for QA would it be. If people won't use it, it's obviously not worth doing. -Derek (dww)
First, Thanks for the willingess to consider changes. I appreciate it. I'm on board too. I'd agree in starting small. Having an issue queue where code could be posted shared and tested does go a long way to alleviating my concerns. I could probably get by with the testing of an applied patch, or whole module file. We should factor in some way of bringing in the user that reported the problem. Particularly if they are doing so because they've been exploited. This has never happened to me yet, but seems like the prudent thing to do. I'm sure accommodations for bringing others into the issue queue can be made on a case by case basis at the security teams discretion. I think I would probably use the custom CVS repository, but I know that I'm different enough in my use of CVS, and deployment strategies, that it may not be worth the effort to develop just for me. Let's wait till we here more requests. Thanks again for listening. Dave On Jan 18, 2008, at 1:32 PM, Derek Wright wrote:
On Jan 18, 2008, at 12:14 PM, Angela Byron wrote:
I'm +1 to its removal, but defer to dww since he knows a lot better than me (or probably most of us ;)) what would be involved here, and how much work it would actually cost/save.
On Jan 18, 2008, at 8:44 PM, David Metzler wrote:
Thanks for the willingess to consider changes.
Gladly.
I'd agree in starting small.
Completely. These grand plan threads always turn into lists of issues, and often just implementing the first few go a long way in fixing the problem.
Having an issue queue where code could be posted shared and tested does go a long way to alleviating my concerns. I could probably get by with the testing of an applied patch, or whole module file.
Great.
We should factor in some way of bringing in the user that reported the problem. Particularly if they are doing so because they've been exploited. This has never happened to me yet, but seems like the prudent thing to do. I'm sure accommodations for bringing others into the issue queue can be made on a case by case basis at the security teams discretion.
Yup, all good. An obvious solution here is make every project an OG (closed/invite-only), which would solve *lots* of other problems at the same time. I can't wait to do that on d.o itself.
I think I would probably use the custom CVS repository, but I know that I'm different enough in my use of CVS, and deployment strategies, that it may not be worth the effort to develop just for me. Let's wait till we here more requests.
Sounds good.
Thanks again for listening.
Agreed. Thanks, -Derek
On Jan 18, 2008 11:44 PM, David Metzler <metzlerd@metzlerd.com> wrote:
First, Thanks for the willingess to consider changes. I appreciate it. I'm on board too.
Great! We have one convert. Let us hear from DragonWize if he likes this approach. -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting.
@Angie & Derek As a new drupal contributor I have no intimate knowledge of who has access to what are areas of d.o, how the access is handled, what is and isn't possible with some of the code behind the scenes, etc., so I am entrusting you as my experts in that area. I don't specifically have any objections because I am not able to fully understand the implications of your proposals. My two main concerns are: 1. The process has to be simple (ie not like U.S. Tax laws :)) 2. Don't stop me from developing my module. As drupal becomes more a part of my business and my livelihood, taking 2 weeks off is not an option. If your proposals fulfill these objectives then count me in. Thank you, Alan On 1/18/08, Derek Wright <drupal@dwwright.net> wrote:
On Jan 17, 2008, at 7:41 PM, Angela Byron wrote:
I don't even know if this is technically feasible
Completely.
The Security Team sets up a cvs-security.drupal.org.
<bikeshed> cvs.security.drupal.org? </bikeshed>
Additionally, the node_access module @ security.drupal.org is tweaked so that it can allow access to specific issues for individual users.
project_issue can do this itself. ;) 'access own issues'.
1. Developer discovers security hole in their module. 2. Developer notifies security@drupal.org.
or creates an issue @ security.drupal.org.
3. Security team takes a copy of the currently vulnerable code and checks it into cvs-security.drupal.org at modules/foobar. Creates a CVS account for developer and gives them access to their module's directory only.
Easy. We already have separate projects on sec.d.o for all modules that have had security issues. Could use the same CVS access for cvs- sec.d.o -> sec.d.o as we do with cvs.d.o -> d.o. In fact, we could automate that each cvs account holder on d.o has an account in a separate CVS repo on cvs.sec.d.o. The CVS access tab on project nodes would be used to generate accounts in the CVSROOT/passwd files for each private repo.
4. Security team creates a user for them at security.drupal.org, and an issue that only the developer and the rest of the security team have access to, in order to act as the central place to test/ discuss patches to fix the issue.
Trivial. We could ensure that all users with CVS accounts on d.o also have limited access user accounts on sec.d.o that can at least submit issues for their own projects and access to their own projects CVS repos. We could have an automated solution to keep the project nodes in sync between the 2 sites.
5. Developer and security team use the normal contributed workflow to get the patch created, reviewed, applied, and tested. 6. Once fix is deemed acceptable, the normal SA process ensues.
Sounds great.
Seems to satisfy all concerns. Thoughts?
I love it! All the benefits you list are true, and there are others...
We can even increase the number of security team members to include those who /just/ do QA testing on a release before it's pushed out.
Additionally, we could:
* Setup the automated simpletest infrastructure that's integrated with project_issue. * Pound more contributed modules with regression tests. * Start to incorporate generation of simpletests into the security review/fix workflow. * Try to write generic simpletests that would work against any (or at least different classes of). For example, write tests that generate both random and specifically malicious content that all output filtering modules are fed.
Not only is it all technically feasible, it wouldn't even be *that* much work to setup the initial proposal you described, and at least the automated simpletests for the core repo on cvs.sec.d.o.
Any objections? Any volunteers?
Thanks! -Derek
-- Alan Doucette Koi Technology, LLC www.KoiTech.net
On Jan 17, 2008 11:52 PM, DragonWize <dragonwize@gmail.com> wrote:
@Angie & Derek
As a new drupal contributor I have no intimate knowledge of who has access to what are areas of d.o, how the access is handled, what is and isn't possible with some of the code behind the scenes, etc., so I am entrusting you as my experts in that area. I don't specifically have any objections because I am not able to fully understand the implications of your proposals.
My two main concerns are:
1. The process has to be simple (ie not like U.S. Tax laws :)) 2. Don't stop me from developing my module. As drupal becomes more a part of my business and my livelihood, taking 2 weeks off is not an option.
If your proposals fulfill these objectives then count me in.
Thank you, Alan
2. Nothing stops development of your module and it's local deployment. Everything does encourage one to work with the community that supports the project you rely on. It is in everyones best interest to not add additional burden to the active volunteers whose support and time you rely on. That reputation that the Drupal community cares about these issues. Because you have a business, it is in your best interest to actively participate and help ease those burdens others carry. My neighbor asked me to watch their kids because they had a medical emergency. I had plans. My neighbor asked me to help unload a heavy piece of equipment they rented. It got me up early. Sometimes, being a member of a community is inconvenient. Sometimes with Open Source it's also about considering the community while you make a profit because that helps you much more in the long run. I hope we can count you in. Steven Peck
On Jan 17, 2008, at 11:52 PM, DragonWize wrote:
My two main concerns are:
1. The process has to be simple (ie not like U.S. Tax laws :))
Basically, think of it as the "security" subdomain of d.o. You have a CVS repo, a project node, an issue queue, automated simpletesting, everything you're used to on d.o, but only you, your co-maintainers, your inner circle of alpha/beta testers, and the security team, gets to see it. Is that simple enough?
2. Don't stop me from developing my module. As drupal becomes more a part of my business and my livelihood, taking 2 weeks off is not an option.
Ah ha, another miscommunication has been uncovered, yay! I never said nor meant to imply "halt all development and stop committing any changes to your module until further notice." Feel free to keep developing your module, working on patches in the issue queue, fixing bugs, working on new features in your new feature branches, whatever you want. Just please try not to touch the vulnerable code at all, try to keep your stable branches stable (as always), and definitely try not to disclose the vulnerability in any way. Ideally, if you can hold off for those 0-3 weeks from modifying the vulnerable code at all in the public repo, that'd be best, but we're not going to call you irresponsible or careless traitor to the security of the project if you end up refactoring code that touches the vulnerability or something. We're all reasonable people here, and we're operating on the basic assumption that d.o CVS account holders are willing and trying to Do The Right Thing(tm), given enough information and help. We just ask a similar degree of goodwill and trust that the security team isn't trying to impede on your livelihood as a Drupal developer. Everyone profits and benefits tremendously from our work. In fact, I doubt many people could make a living with Drupal at all if we didn't have as kick-ass a security team as we do (and that's directed at the giants on whose shoulders I'm standing).
If your proposals fulfill these objectives then count me in.
I believe they do. Welcome aboard. :) -Derek (dww)
3. Security team takes a copy of the currently vulnerable code and checks it into cvs-security.drupal.org at modules/foobar. Creates a CVS account for developer and gives them access to their module's directory only.
This is the part that is of concern to me. First, is it scalable? It requires significant security team's manpower. Second, a snapshot can get stale vs. the code at cvs.d.o, and all sorts of interesting stuff can happen. Third, back synching the cvs-security.d.o to cvs.d.o after the SA process is done is a lot of work, and could introduce errors. Sorry, I don't want to sound too negative, but the security team is overloaded as it is. The rest of your proposal makes sense, and does have lots of benefits. -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting.
On Jan 17, 2008, at 11:27 PM, Khalid Baheyeldin wrote:
First, is it scalable?
Very. In fact, it's VASTLY more scalable than the existing process/ workflow.
It requires significant security team's manpower.
Not at all. Only to get the initial sync stuff working.
Second, a snapshot can get stale vs. the code at cvs.d.o , and all sorts of interesting stuff can happen.
That's why we'll still try to use patches in the (sec.d.o) issue queue, and if we have to, we just re-rsync the CVS dir on cvs.d.o to that project's private repo on cvs.sec.d.o again while we're working on something, re-apply the patches, etc. Alternately, we could consider using vendor branches on these private repos to help merge local changes. If we wanted to get really crazy, we could start to experiment with distributed revision control (e.g. git.sec.d.o) to help manage private repos for _some_ of the projects on sec.d.o. I know people who've have great luck importing a CVS checkout, "CVS" directory and all, into other revision control systems. They make local modifications and commit to the other RCS. Then, they run "cvs up" in the checkout, the CVS directory kicks in, CVS tries to merge in upstream changes, you resolve conflicts, and commit that again locally to the alternate RCS. Could work great, at least for projects where the maintainer is already familiar and would rather work with another tool for this task, but that would depend at the very least on people helping to complete the to-do list here: http://groups.drupal.org/node/8102 and then implementing other versioncontrol API backend modules for whatever tool(s) they wanted to be able to use for this.
Third, back synching the cvs-security.d.o to cvs.d.o after the SA process is done is a lot of work, and could introduce errors.
Not at all. It's just the identical workflow for maintainers to commit an RTBC patch from an issue to their official cvs.d.o directory. Even if we got crazy with other RCSs, you just update your workspace to the latest copy in $RCS, which is itself a "Locally modified" CVS workspace from CVS's perspective. You run "cvs diff - up" and you've got a perfectly synced, clean patch to apply upstream. -Derek (dww)
I hope this does not turn into another release system. I mean a lot of work initially, and high maintenance on an ongoing basis, lots of questions and confusion, and more stress for you. Sometimes I see the tendency of the technologists to overengineer things, just because we can. Maybe it is just the process that needs improvement, not the underlying technology. If we wanted to get really crazy, we could start to experiment with
distributed revision control (e.g. git.sec.d.o)
Does this means we finally move off CVS? Yay! Should I start an SVN vs. GIT vs. bzr flamewr thread? /me ducks ... -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting.
On 18.Jan.2008, at 10:30, Khalid Baheyeldin wrote:
Maybe it is just the process that needs improvement, not the underlying technology.
By the looks of it, the first thing to tackle should be the workflow process. / liza
I am on board. I am willing to help out however I can. I don't think I have enough knowledge of the systems to lead this project but if someone is willing to list and/or delegate some tasks to be done, I will contribute. Thanks to all for have put up with me and this extremely long thread, -- Alan Doucette Koi Technology, LLC www.KoiTech.net
On 17.Jan.2008, at 10:41 PM, Angela Byron wrote:
Seems to satisfy all concerns. Thoughts? -Angie
I know I am coming in late into the thread but I just have to jump and just say that what Angie has done is pure genius. As Drupal grows, more workflow processes will have to be set into place. Someone has to use this for the next DrupalCon and either turn it into a panel or a white paper. Anyway, I have to read down on the thread, but just wanted to take my hat off for Angie. YOU GO GRRRL! / liza Liza Sabater, Publisher www.culturekitchen.com www.dailygotham.com MOB - 646.552.7365 AIM - cultkitdiva
participants (21)
-
andrew morton -
Angela Byron -
blogdiva＠culturekitchen.com -
Daniel F. Kudwien -
David Metzler -
David Norman -
Derek Wright -
DragonWize -
Earl Miles -
FGM -
Gerhard Killesreiter -
Greg Knaddison -
Greg Knaddison - GVS -
Gábor Hojtsy -
Ivan Sergio Borgonovo -
Iñaki Lopez -
Jakob Petsovits -
Khalid Baheyeldin -
Neil Drumm -
Stephane Corlosquet -
Steven Peck