We just got confirmation from Microsoft this evening that the.NET Framework Assistant add-on (used to provide ClickOnce stuffs) was NOT a vector for this vulnerability, so we've removed it from the blocklist. The WPF plugin is still there, though we're working on a way to let sophisticated users and enterprises override the block if they know that they have applied the relevant IE patch to their system.
http://blogs.technet.com/srd/archive/2009/10/12/ms09-054.aspx says pretty clearly that it's an IE vulnerability: "While the vulnerability is in an IE component", which fits with the information I have. I think perhaps the WPF plugin uses that IE component?
There is no version difference for the plugin or add-on between patched and unpatched systems. That's one reason that this is so messy right now; if we had known about the Firefox aspect of the vulnerability before the SRD blog post, we would have suggested just that sort of version bump.
We have interest in determining if the Firefox user in question has applied the IE patch in question, but we do not have the means.
It is related to IE, because the patch in question is explicitly labelled as affecting Internet Explorer, and makes no mention of the fact that it can impact Firefox users who have not gone out of their way to disable part of.NET Framework 3.5 SP1. (That's one of the things we're working on getting fixed, as it happens.)
I believe that by tomorrow you will have a number of options, though switching browsers is certainly one of them. I hope to post an update to our security blog about it tonight.
(Do your boxes depend on the WPF plugin or the ClickOnce add-on, out of curiosity? And can I ask what you did before Windows.NET Framework 3.5 SP1 installed this plugin? Or are all the apps in question more recent than February? Genuinely interested, trying to learn more about the scope of people's use here.)
There is no war. We decided together that this was the right step to take right now to protect our mutual users, based on our understanding of the problem and outcomes.
I (Mike Shaver) am the person who spoke with the person at Microsoft. I'm not going to name them, because that's not my place, but this was not a case of us sticking it to Microsoft -- it was a case of us protecting our mutual users, with their agreement.
We're working (today, as I type this) on ways to make the blocklist entry less disruptive for people who have their systems patched up. If we had known about the vulnerability before it was publicly disclosed, we could have done a lot more to make it smooth for users, but timing left us with an unpleasantly reduced set of options.
Yes, sorry, I should have said that we can't distinguish it without custom code pushed through a patch, because it doesn't affect any files that we load or touch.
The plugin in question was installed via a Windows Update _security_ update, it wasn't something that people really chose to install.
I agree, though, that this really, really isn't malware. That's a ridiculous misuse of the term.
That statement is consistent with what I heard from Microsoft, though their post has been updated since that conversation. And MSFT has seen that text; if it's not correct, I'm sure I'll hear it from them, and will be happy to correct it. (I wrote the text pretty quickly, since it was late on Friday night and we were getting inbound already from the blocklist addition.)
But that's really ancillary to the issue, which is that Firefox users are vulnerable to a problem that we learned about this week, which is labelled as an IE problem/patch. Microsoft and Mozilla agreed that we should block the plugin and add-on to mitigate the risk while we made sure that FF users were going to install that IE patch. This isn't an us-vs-them thing, but I don't know who you're talking to at Microsoft who is saying different things.
If Microsoft or Apple asked us about such a kill-switch for a version of Firefox that we put onto their users' systems via a security update, and we agreed that it was the right thing to do, I would hope there wouldn't be a shitstorm at all.
Because there is no way to distinguish patched from unpatched systems -- the WPF plugin doesn't expose any version information, unlike Flash and other such systems, and it didn't get updated with MS09-054. If I had known about this vulnerability before they posted on their blog, I would have told them to provide just such a distinction, so that we could disable only unpatched setups!
We can remove from the blocklist as quickly as we added, but I wanted to protect users while we made sure that Firefox users would apply this patch, and figure out how to do better with this subsystem going forward. Microsoft agreed, and -- my sympathy for users that this has inconvenienced notwithstanding -- I still think it was the best of our available options.
There's no cat and mouse -- they agreed to this blocking. I have in fact encouraged them to use a different extension ID if and when they make a fixed ClickOnce/WPF add-on that can be installed by active user choice rather than by default!
MS09-054 is labelled as an Internet Explorer update, so it's not obvious that Firefox users need to apply it. We're working with Microsoft on getting that fixed.
Microsoft did definitely agree to it; I'm the one they told, on the telephone, before I requested the block be pushed out. I don't know why you think I was lying -- I didn't "imply" it, I flat out said that they agreed, which is the case. Do I have a history of lying about such things?
So we were a bit faster, sorry about that:-) I can only speak for OGo by saying that the Sunbird GroupDAV efforts wouldn't have been started if Sunbird CalDAV support would have already been available.
That strikes me as a curious statement, given that Stelian announced on Feb 15that he'd "started his work", but that there was "no code yet", and in the same thread mentioned mozilla/calendar/providers, which has hosted development of a CalDAV provider since the middle of December. In the same newsgroup, in fact, we'd been discussing the architectural changes we were making to Sunbird to support remote servers properly, and the progress of CalDAV, since early November.
But maybe I'm missing something here. It's happened before.
Yes, this code is not real in the OpenSource community. Where can we download the Sunbird CalDAV support you mention, we dare to get access to this! Where can I buy the Outlook CalDAV connector by Oracle?
From Mozilla CVS, as with all things Sunbird. If you'd like to, you can browse the source for the CalDAV provider on LXR. Sunbird 0.3 will be the first released version with native CalDAV support, but you're welcome to build your own in the interim.
This is the sort of thing that can be trivially discovered by asking in the Sunbird newsgroup or IRC channel, in case you are ever confused in the future about where to find Sunbird source.
You'd have to ask an Oracle representative about their connector; I think some are listed on the CalConnect site.
Yet please: do not turn this into a CalDAV vs GroupDAV flame war.
I don't have much to say to this, I just really enjoyed reading it after the both the initial posting and the Citadel guy's post elsewhere in this thread decried CalDAV as "vaporware" and "without working code". So I thought I'd quote it so I could read it again and again!
PS: unlike CalDAV GroupDAV tries to restrict ICS requirements to deal with limitations. Pragmatic approach to deal with the real world. A CalDAV server currently requires a full ICS implementation in both the client and the server.
CalDAV is relying on, and helping, the Calsify effort to come up with simplified, min-interop subsets of iCalendar, based on input from many implementors of many products, rather than inventing our own subset based on just the products we've been directly involved with. I believe there is a BOF on this topic at the IETF in Minnesota shortly, if your group would like to participate in it.
As Helge tried to explain, WebDAV itself has no versioning in it. It's not "in the tech", at all. The name was selected when "V"ersioning was going to be a part of the core standard, but the versioning part was dropped (pushed out to DeltaV) before the standard was finalized. WebDA just doesn't have the same ring to it, I guess, so they didn't change the name. Any good WebDAV book (I recommend Lisa Dusseault's) should explain it well.
Too complicated to implement (as was the case with CAP, which nobody has even tried to implement, and CalDAV, which exists only in a few vaporware implementation). GroupDAV is designed to be easy to implement yet cover the most common use cases: connecting address books, calendars, task lists, etc. to your server.
I don't know what "vaporware" implementations are to you, but as one of the authors of a publicly-available CalDAV client, I suspect I should take offense. I've seen CalDAV interoperate, including basic scheduling and search, with products from other implementors. I'm not interested in whipping out a ruler on Slashdot, but I think you do your own group's reputation a disservice with that representation.
(Also: people have indeed tried to implement CAP, and in fact I believe Groupwise shipped with support for one of the drafts quite some time ago. I do agree that CAP's a bad scene, but you really should be a little more careful with both facts and language if you're going to both represent your efforts and disparage others'.)
If you believe that the "most common use cases" don't include alarm preservation or recurring events, we must be talking to very different users.
Too specific to one product or project. GroupDAV solves this problem by sticking to the standards: iCalendar for calendar and task list data, vCard for address book data, HTTP for authentication and transport.
If you believe that "sticking to the standards" with iCalendar "solves" the problem of being specific to one product, I submit that you have not spent enough time trying to actually interoperate with other iCalendar-using products. RRULE support (especially BYSETPOS, but also exclusions), VTIMEZONE handling, proper invalidation of PARTSTAT when "significant" changes happen, preservation of X-PROPS and X-PARAMS, alarm semantics, even proper newline behaviour are all stumbling blocks of various heights. GroupDAV itself seems to encourage behaviours that would prevent iCalendar compliance, such as not round-tripping alarm information and recurrences.
Even HTTP doesn't solve it all for you, as has been discussed in some detail recently on the caldav list. It's better than the alternatives, but saying that it "solves the problem" strikes me as pretty naive.
All talk, no proof of concept. GroupDAV has proven that's not the case here, because we have at least two clients and two servers up and running today, with more on the way.
When we started building CalDAV support into Sunbird in December, we had a proof-of-concept server from Oracle to work against, and did, scheduling meetings with other people and interoperating with other (esp. non-CalDAV) clients. We had two servers and two clients at the January interop, plus the Exchange adapter that let us run Sunbird against Exchange and share calendars with Outlook, including basic scheduling. I'm very happy for your project's success in implementing a simple document-sharing collaboration model, but you should really consider raising your standards of research.
All that said, I would be happy to help the author of the "beta" Sunbird GroupDAV connector get themselves checked into mozilla/calendar/providers. It was a pleasant surprise to hear that it was in beta, since I hadn't heard anything of it myself.
I've been bitching about that for a LONG time now, and Sunbird/etc has really progressed no further. It can't even read its *own* invites sometimes.
I suspect that it can't read its invites because Sunbird has never sent email invitations. Ever. Not even once when it thought you weren't looking.
I'm sorry that your bitching (always productive) has not driven Sunbird progress to new paroxysms of productivity, but I wasn't able to find anything in the Calendar product in bugzilla.mozilla.org filed by, commented-on, or even cc:d to anyone with "pbp.net" in their email address. Can you direct me to your bug report? I suspect it needs to be marked INVALID, but I'll give it the benefit of the doubt.
Mike
(who marks these things "insightful", anyway?)
Unlike CAP and CalDAV, the GroupDAV effort is backed by real code that works today.
Huh. I participated in an interop in January in which we had CalDAV implementations from 3 different vendors interoperate pretty darned well. (Where they didn't the limitations were almost exclusively due to differences in handling of various ICS details, which problem plagues all ICS-based calendaring efforts, from CAP to GroupDAV and beyond.)
In addition to the IETF-style interop checklist we ran over the course of two sessions, we also had demonstrations of things like Sunbird and Outlook sharing a calendar on the basis of a CalDAV adapter for Exchange (written by Oracle). Is this code that's not real? That would make me and others sad, because we spent a fair bit of time writing this code, and it sure seemed real when we ran it and shared calendars!
I'm also interested, as someone who works on Sunbird pretty much every day, to hear more about this "Sunbird connector" that is in beta. I haven't seen it yet, and we're always looking for useful new providers -- where is the beta testing being done? (The discussion of the implementations on the groupdav.org site confused me -- why would you need to have a server as a goal for a client-side connector? Isn't the whole point of a pseudo-standard like GroupDAV that you code to the protocol and not the peer?)
Until the Mozilla folks take handhelds seriously, Thunderbird and Sunbird are not going to be competitive IMO.
Thunderbird's palm-sync extension works well for many people, though not for all, and I know that several Mozilla calendar developers are interested in synchronization. A fair bit of time during the recent architecture discussions was spent on making sure that we could fit a good sync model -- including transparent offline support, etc. -- into the new calendar system, and I think we've done a decent job of that.
Slashdot Mirror
Pretty sure it's XBAP's use of mshtml that's the problem for 09-054; 09-061 is a different vuln that is also exposed through some .NET widget.
We just got confirmation from Microsoft this evening that the .NET Framework Assistant add-on (used to provide ClickOnce stuffs) was NOT a vector for this vulnerability, so we've removed it from the blocklist. The WPF plugin is still there, though we're working on a way to let sophisticated users and enterprises override the block if they know that they have applied the relevant IE patch to their system.
o/~ the more you know o/~
http://blogs.technet.com/srd/archive/2009/10/12/ms09-054.aspx says pretty clearly that it's an IE vulnerability: "While the vulnerability is in an IE component", which fits with the information I have. I think perhaps the WPF plugin uses that IE component?
There is no version difference for the plugin or add-on between patched and unpatched systems. That's one reason that this is so messy right now; if we had known about the Firefox aspect of the vulnerability before the SRD blog post, we would have suggested just that sort of version bump.
We have interest in determining if the Firefox user in question has applied the IE patch in question, but we do not have the means.
It is related to IE, because the patch in question is explicitly labelled as affecting Internet Explorer, and makes no mention of the fact that it can impact Firefox users who have not gone out of their way to disable part of .NET Framework 3.5 SP1. (That's one of the things we're working on getting fixed, as it happens.)
I believe that by tomorrow you will have a number of options, though switching browsers is certainly one of them. I hope to post an update to our security blog about it tonight.
(Do your boxes depend on the WPF plugin or the ClickOnce add-on, out of curiosity? And can I ask what you did before Windows .NET Framework 3.5 SP1 installed this plugin? Or are all the apps in question more recent than February? Genuinely interested, trying to learn more about the scope of people's use here.)
There is no war. We decided together that this was the right step to take right now to protect our mutual users, based on our understanding of the problem and outcomes.
We're working on it (today) -- I'm very sorry for the inconvenience!
I (Mike Shaver) am the person who spoke with the person at Microsoft. I'm not going to name them, because that's not my place, but this was not a case of us sticking it to Microsoft -- it was a case of us protecting our mutual users, with their agreement. We're working (today, as I type this) on ways to make the blocklist entry less disruptive for people who have their systems patched up. If we had known about the vulnerability before it was publicly disclosed, we could have done a lot more to make it smooth for users, but timing left us with an unpleasantly reduced set of options.
Yes, sorry, I should have said that we can't distinguish it without custom code pushed through a patch, because it doesn't affect any files that we load or touch.
The plugin in question was installed via a Windows Update _security_ update, it wasn't something that people really chose to install. I agree, though, that this really, really isn't malware. That's a ridiculous misuse of the term.
That statement is consistent with what I heard from Microsoft, though their post has been updated since that conversation. And MSFT has seen that text; if it's not correct, I'm sure I'll hear it from them, and will be happy to correct it. (I wrote the text pretty quickly, since it was late on Friday night and we were getting inbound already from the blocklist addition.) But that's really ancillary to the issue, which is that Firefox users are vulnerable to a problem that we learned about this week, which is labelled as an IE problem/patch. Microsoft and Mozilla agreed that we should block the plugin and add-on to mitigate the risk while we made sure that FF users were going to install that IE patch. This isn't an us-vs-them thing, but I don't know who you're talking to at Microsoft who is saying different things.
If Microsoft or Apple asked us about such a kill-switch for a version of Firefox that we put onto their users' systems via a security update, and we agreed that it was the right thing to do, I would hope there wouldn't be a shitstorm at all.
I applaud your commitment to understanding ahead of commenting. I wish such commitment were as widespread as the plugin in question!
Because there is no way to distinguish patched from unpatched systems -- the WPF plugin doesn't expose any version information, unlike Flash and other such systems, and it didn't get updated with MS09-054. If I had known about this vulnerability before they posted on their blog, I would have told them to provide just such a distinction, so that we could disable only unpatched setups! We can remove from the blocklist as quickly as we added, but I wanted to protect users while we made sure that Firefox users would apply this patch, and figure out how to do better with this subsystem going forward. Microsoft agreed, and -- my sympathy for users that this has inconvenienced notwithstanding -- I still think it was the best of our available options.
There's no cat and mouse -- they agreed to this blocking. I have in fact encouraged them to use a different extension ID if and when they make a fixed ClickOnce/WPF add-on that can be installed by active user choice rather than by default!
MS09-054 is labelled as an Internet Explorer update, so it's not obvious that Firefox users need to apply it. We're working with Microsoft on getting that fixed. Microsoft did definitely agree to it; I'm the one they told, on the telephone, before I requested the block be pushed out. I don't know why you think I was lying -- I didn't "imply" it, I flat out said that they agreed, which is the case. Do I have a history of lying about such things?
See http://blog.mozilla.com/security/2009/07/19/milw0rm-9158-stack-overflow-crash-not-exploitable-cve-2009-2479/ for more details, including specifics about how the bug affects different platforms and versions (worst case: unexploitable crash in OS X system libraries).
But maybe I'm missing something here. It's happened before.
Mike
From Mozilla CVS, as with all things Sunbird. If you'd like to, you can browse the source for the CalDAV provider on LXR. Sunbird 0.3 will be the first released version with native CalDAV support, but you're welcome to build your own in the interim.
This is the sort of thing that can be trivially discovered by asking in the Sunbird newsgroup or IRC channel, in case you are ever confused in the future about where to find Sunbird source.
You'd have to ask an Oracle representative about their connector; I think some are listed on the CalConnect site.
I don't have much to say to this, I just really enjoyed reading it after the both the initial posting and the Citadel guy's post elsewhere in this thread decried CalDAV as "vaporware" and "without working code". So I thought I'd quote it so I could read it again and again! CalDAV is relying on, and helping, the Calsify effort to come up with simplified, min-interop subsets of iCalendar, based on input from many implementors of many products, rather than inventing our own subset based on just the products we've been directly involved with. I believe there is a BOF on this topic at the IETF in Minnesota shortly, if your group would like to participate in it.Mike
Mike
(Also: people have indeed tried to implement CAP, and in fact I believe Groupwise shipped with support for one of the drafts quite some time ago. I do agree that CAP's a bad scene, but you really should be a little more careful with both facts and language if you're going to both represent your efforts and disparage others'.)
If you believe that the "most common use cases" don't include alarm preservation or recurring events, we must be talking to very different users.
If you believe that "sticking to the standards" with iCalendar "solves" the problem of being specific to one product, I submit that you have not spent enough time trying to actually interoperate with other iCalendar-using products. RRULE support (especially BYSETPOS, but also exclusions), VTIMEZONE handling, proper invalidation of PARTSTAT when "significant" changes happen, preservation of X-PROPS and X-PARAMS, alarm semantics, even proper newline behaviour are all stumbling blocks of various heights. GroupDAV itself seems to encourage behaviours that would prevent iCalendar compliance, such as not round-tripping alarm information and recurrences.
Even HTTP doesn't solve it all for you, as has been discussed in some detail recently on the caldav list. It's better than the alternatives, but saying that it "solves the problem" strikes me as pretty naive.
When we started building CalDAV support into Sunbird in December, we had a proof-of-concept server from Oracle to work against, and did, scheduling meetings with other people and interoperating with other (esp. non-CalDAV) clients. We had two servers and two clients at the January interop, plus the Exchange adapter that let us run Sunbird against Exchange and share calendars with Outlook, including basic scheduling. I'm very happy for your project's success in implementing a simple document-sharing collaboration model, but you should really consider raising your standards of research.
All that said, I would be happy to help the author of the "beta" Sunbird GroupDAV connector get themselves checked into mozilla/calendar/providers. It was a pleasant surprise to hear that it was in beta, since I hadn't heard anything of it myself.
Good luck to you!
Mike
I'm sorry that your bitching (always productive) has not driven Sunbird progress to new paroxysms of productivity, but I wasn't able to find anything in the Calendar product in bugzilla.mozilla.org filed by, commented-on, or even cc:d to anyone with "pbp.net" in their email address. Can you direct me to your bug report? I suspect it needs to be marked INVALID, but I'll give it the benefit of the doubt.
Mike (who marks these things "insightful", anyway?)
In addition to the IETF-style interop checklist we ran over the course of two sessions, we also had demonstrations of things like Sunbird and Outlook sharing a calendar on the basis of a CalDAV adapter for Exchange (written by Oracle). Is this code that's not real? That would make me and others sad, because we spent a fair bit of time writing this code, and it sure seemed real when we ran it and shared calendars!
I'm also interested, as someone who works on Sunbird pretty much every day, to hear more about this "Sunbird connector" that is in beta. I haven't seen it yet, and we're always looking for useful new providers -- where is the beta testing being done? (The discussion of the implementations on the groupdav.org site confused me -- why would you need to have a server as a goal for a client-side connector? Isn't the whole point of a pseudo-standard like GroupDAV that you code to the protocol and not the peer?)
Mike
Thunderbird's palm-sync extension works well for many people, though not for all, and I know that several Mozilla calendar developers are interested in synchronization. A fair bit of time during the recent architecture discussions was spent on making sure that we could fit a good sync model -- including transparent offline support, etc. -- into the new calendar system, and I think we've done a decent job of that.
Mike