I'm really feeling for our Rails Core friends... they're getting blasted right now for not having a complete policy for releasing and communicating urgent security flaws. I'm not poking fun, this is pretty serious stuff.
Read here for some of the comments they're getting today via Reddit.com: "Mandatory security patch issued for Rails, but the vulnerability is not disclosed. " http://programming.reddit.com/info/cvlr/comments
Rather than poke fun or make light of the today's situation with Rails, I'd rather like to turn the focus on the Django project and play the "But what if it happened to you?" game.
I heard way-back-when that Django was security-audited, and found to be secure, but that was (I think) before Django was open-sourced, and I don't remember seeing many details.. However, doing a quick search for "security" of the Dev list shows this message from Jacob: http://groups.google.com/group/django-developers/msg/682543e6c084ff75
Should someone commission a new audit given the amount of code changes in Django since last year? (It would be a great opportunity for some company <cough Google cough ThoughtWorks cough WorldOnline /> to sponsor.
A few questions: 1) If there was critical security flaw found in Django (any version) today, are there plans in place on how to deal with it? If so, are those plans posted anywhere? If not, let's roll up our sleaves and do it! :-)
2) Is there a Django mailing list for security alerts? If not, let's create one!
3) What are some projects to emulate in terms of "They do security right"? I've heard Debian has good policies and execution on those plans. Any others?
Having an emergency plan ready to go the moment a security issue crops up is one of those things that will really ease the mind of an "enterprise" flirting with the idea of going Django. It's also an area where Django can really shine compared to other web frameworks (Python or otherwise).
I'm on the Apache security list, and I'll offer my 2c's on how they do it.
1) A security@ email alias which is private and is a alias for the core developers. be prepared for a *LOT* of spam, and a lot of questions which should have been asked on dev@ or users@. Certain security providers like to send stuff with GPG encryption. make sure that you have a GPG key with good trust paths so that they can send encrypted information to you.
2) Acknowledge each email on it, the security 'researchers' like prompt feedback, and will post on full-disclosure if they don't feel like they are getting a fast enough response.
3) a vendors-announce@ mailing list which goes to the major vendors who use django. people like redhat, debian, and possibly some of the large ISPs who provide django hosting. They usually get notified that there is an issue (not what it is) and the expected announce date so they can have some resources to deal with it when it comes out. you should also notify agencies like CERT and get a CVE id for the issue.
4) a regular announce@ mailing list for the rest of us mortals.
apache also has a private SVN repo for keeping track of issues, but I'm not sure if that is warranted here.. django is much smaller
5) when a security release happens, the release notes acknowledge the security research firm that found it. This will encourage them to tell you about it first.
oh.. and security usually comes in waves.. now that a vulnerability has been found in Rails, I expect it will attract several other research firms to look at rails (and django) very carefully.
> I'm really feeling for our Rails Core friends... they're getting > blasted right now for not having a complete policy for releasing and > communicating urgent security flaws. I'm not poking fun, this is > pretty > serious stuff.
> Read here for some of the comments they're getting today via > Reddit.com: > "Mandatory security patch issued for Rails, but the vulnerability is > not disclosed. " > http://programming.reddit.com/info/cvlr/comments
> Rather than poke fun or make light of the today's situation with > Rails, > I'd rather like to turn the focus on the Django project and play the > "But what if it happened to you?" game.
> I heard way-back-when that Django was security-audited, and found > to be > secure, but that was (I think) before Django was open-sourced, and I > don't remember seeing many details.. However, doing a quick search for > "security" of the Dev list shows this message from Jacob: > http://groups.google.com/group/django-developers/msg/682543e6c084ff75
> Should someone commission a new audit given the amount of code changes > in Django since last year? (It would be a great opportunity for some > company <cough Google cough ThoughtWorks cough WorldOnline /> to > sponsor.
> A few questions: > 1) If there was critical security flaw found in Django (any version) > today, are there plans in place on how to deal with it? If so, are > those plans posted anywhere? If not, let's roll up our sleaves and do > it! :-)
> 2) Is there a Django mailing list for security alerts? If not, let's > create one!
> 3) What are some projects to emulate in terms of "They do security > right"? I've heard Debian has good policies and execution on those > plans. Any others?
> Having an emergency plan ready to go the moment a security issue crops > up is one of those things that will really ease the mind of an > "enterprise" flirting with the idea of going Django. It's also an area > where Django can really shine compared to other web frameworks (Python > or otherwise).
On Wed, 2006-08-09 at 18:41 -0700, Jason Huggins wrote:
[...]
> A few questions: > 1) If there was critical security flaw found in Django (any version) > today, are there plans in place on how to deal with it? If so, are > those plans posted anywhere? If not, let's roll up our sleaves and do > it! :-)
> 2) Is there a Django mailing list for security alerts? If not, let's > create one!
If somebody did find a security problem, I would hope they would have the presence of mind to look in the "how to contribute" document if they could find no other way to contact people. Also note that the email address there is the "obvious" one in some sense for reporting security problems.
Finally, a little while ago somebody did report what they thought was a security hole via Trac (an unfortunate choice, but that's the way it goes) and it was looked at immediately.
> 3) What are some projects to emulate in terms of "They do security > right"? I've heard Debian has good policies and execution on those > plans. Any others?
Which policies in particular are you thinking about?
To provide some background about how distros work: Each professional distribution (Debian, Suse, Mandrake, Red Hat, Ubuntu, Slackware, *BSD, ...) has a security team that has representatives on the contacts list specifically for notifying vendors of security problems in advance of a release. It's why when you read about, e.g., an Apache release, you also see most major distributions putting out update packages on the same day. It isn't magic -- it's coordination and it's a very professional group of people to work with.
> Having an emergency plan ready to go the moment a security issue crops > up is one of those things that will really ease the mind of an > "enterprise" flirting with the idea of going Django. It's also an area > where Django can really shine compared to other web frameworks (Python > or otherwise).
Revolutionary ideas aren't really needed here, since the current system(s) work fairly well and using proven practices in cases like this is absolutely the right thing to do. The thing that seems to have bitten Ruby on Rails (and is applicable to us as well) is that they have a broad installation base via grass-roots support, rather than via distributions. Python, for example, has had security flaws in the past (usually due to third-party libraries) and they have handled the release and disclosure process very well.
I'm not completely sure I agree with the way the Ruby team are handling this release, but since I don't know the details yet, I can't really work out what is happening; they may have very good justification for the way they are doing it, or they may just be slightly shell-shocked. It just didn't cross my radar on any of the security-related lists I'm on that normally cover these types of security announcements. They are the places that this "enterprise" group watch for results. Presumably there was a post to the Ruby-users mailing list, wherever that is and that is the other place people are going to be watching: if you're using something that is essentially pre-release for mission-critical work, you are implicitly taking on the responsibility of watching carefully for things like this.
On 8/9/06, Malcolm Tredinnick <malc...@pointy-stick.com> wrote:
> I'm not completely sure I agree with the way the Ruby team are handling > this release, but since I don't know the details yet, I can't really > work out what is happening; they may have very good justification for > the way they are doing it, or they may just be slightly shell-shocked.
Dave Thomas, who is heavily involved with Ruby yet not Rails-core, and who I think has very good judgement, thinks the issue is severe enough that they're doing the right thing to let people hear and upgrade before full disclosure.
> something that is essentially pre-release for mission-critical work, you > are implicitly taking on the responsibility of watching carefully for > things like this.
True, but Rails had lots of buzz and has -lots- of prod systems. Of the 2 people I talked to with prod rails systems, neither had heard of this 3 hours after the posting. I only knew because of luck on prog.reddit.
Sorry I didn't read that first before posting here. Though I did a Trac search for "security" and that page didn't come up in the first few search results...
Though, looking at the guidelines, I wonder how the Django devs would know who to contact in one-on-one private emails about the vulnerability and the fix.
> Which policies in particular are you thinking about?
I guess I'm focused on three things: 1) How do Django devs handle security issues when notified? This looks well covered in the existing reporting-security-issues doc. 2) How should the affected users be notified? Having read the above doc, I think this could use some more detail. 3) Is there any sort of policy or promise on how many versions back Django devs are willing to go back and support?
The implicit assumption of using pre 1.0 code (especially open source) is that there are no promises... But there might need to be something more explicit like ("we'll make our best effort to support the creation of any critical security patches for version 'X' for at least Y number of years after initial release). In the Rails case, they first said "upgrade to the latest version to get the patch", which made many people unhappy. Then they back-peddaled and said they'd work on patches for the older versions, too. Might be better to state up-front how long Django devs expect to support various versions so people can weigh the risks of staying on an old release later on. This is a good thing to decide on when 1.0 ships. By comparison, the Ubuntu project is very upfront in how they promise to support each release.
On 8/9/06, Jason Huggins <jrhugg...@gmail.com> wrote:
> 2) How should the affected users be notified? Having read the above > doc, I think this could use some more detail.
One would hope that anyone who's using Django is subscribed to django-users and/or watches the Django blog (or that a company which uses Django has a designated person doing that), because those would be the obvious channels for notifying users that a security-related patch/release had been issued.
> 3) Is there any sort of policy or promise on how many versions back > Django devs are willing to go back and support?
The documentation page Malcolm linked states that patches will be developed for the current release and the two releases previous to it. That seems like a fairly sane policy, is roughly in line with what some of the more popular Linux distros do.
-- "May the forces of evil become confused on the way to your house." -- George Carlin
Jeremy Dunck wrote: > True, but Rails had lots of buzz and has -lots- of prod systems. Of > the 2 people I talked to with prod rails systems, neither had heard of > this 3 hours after the posting. I only knew because of luck on > prog.reddit.
Same here, programming.reddit.com is my most hit site these days...
But all the more reason for letting Django users know *before-hand* where they should look for stuff like this (which list they should be subscribed to or RSS feed to check). As Django user/dev, I would *not* want to *first* hear about something like this on reddit. :-)
Maybe there should be some guideline like.. "If you're going to deploy Django on a server accessible by the general public, subscribe to our security RSS feed or mailing list to be notified as needed". Even then, I can see how a policy like that is "tricky"... What's to keep an evil blackhat from subscribing to the very same list so he he knows when to get busy cracking sites using the same information?
James Bennett wrote: > > 3) Is there any sort of policy or promise on how many versions back > > Django devs are willing to go back and support?
> The documentation page Malcolm linked states that patches will be > developed for the current release and the two releases previous to it. > That seems like a fairly sane policy, is roughly in line with what > some of the more popular Linux distros do.
Ugh. May bad... I must have missed that. Right there it says, "[For security issues, we'll] Halt all other development as long as is needed to develop a fix, including patches against the current and two previous releases."
Thanks for answering my questions, everyone. I'll try to read the docs more closely next time... :-)
On 8/9/06, Jason Huggins <jrhugg...@gmail.com> wrote:
> I can see how a policy like that is "tricky"... What's to keep an evil > blackhat from subscribing to the very same list so he he knows when to > get busy cracking sites using the same information?
I've been watching people go round and round about this in various places today, and I have to say that I can respect the Rails team's policy of not releasing full details of the vulnerability until after their users have had a little time to patch. Full disclosure still happens, but it's slightly safer for end users this way. A couple other open-source projects I've used/been involved with have followed a similar policy of "update ASAP, and we'll release details once people have had time to patch", and it's caused no harm that I've seen.
And as much as some people I've talked to have been wailing and gnashing teeth about Rails being into Mac OS X 10.5 while Django isn't, well, I don't envy somebody who gets shipped as part of a major operating system when it comes time to issue security updates :)
-- "May the forces of evil become confused on the way to your house." -- George Carlin
On Wed, 2006-08-09 at 23:50 -0500, James Bennett wrote: > [...] > And as much as some people I've talked to have been wailing and > gnashing teeth about Rails being into Mac OS X 10.5 while Django > isn't, well, I don't envy somebody who gets shipped as part of a major > operating system when it comes time to issue security updates :)
This is pretty much a solved problem. It is coordinated through the vendor security contacts lists that Ian was talking about. It happens more often than you may realise: Apache or OpenSSL or the Linux kernel or some other pervasive, critical component has a security hole discovered and the release of the updates is coordinated and simultaneous. So Apple would release the updates on the same day as everybody else. If you do it well, you don't end up where people look at you like Microsoft and think they can't trust the update (another advantage of Open Source, too). Often the upstream source can supply the patch, so the vendors need only audit it and do package rebuilds and rush it through release QA (again, they'll often have priority paths internally for security fixes).
James Bennett wrote: > One would hope that anyone who's using Django is subscribed to > django-users and/or watches the Django blog
This would be less and less true as time goes because Django will spread beyond early adopters to a new forming local communities. For example there is russian Django's LiveJournal community where I suspect many people read just that list and not django-users because either they're already happy with local list or just don't feel comfortable enough with English to read it on a dialy basis.