1037978 - Set PRODID in VCALENDAR items with current name and version of Lightning

Status: NEW

(Calendar :: Internal Components, defect)

Description

[[:MakeMyDay]]

Currently prodid in ical items is set statically to

-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN

at http://mxr.mozilla.org/comm-central/source/calendar/base/src/calUtils.js#1350

We should change this to reflect the name (useful for some Linux distributions) and version of Lightning.

-//Mozilla.org//NONSGML Lightning V2.6.6//EN or
-//Mozilla.org//NONSGML Iceowl V2.6.6//EN

Additional note: The ISO 9070-1991 style is not required by RfC 5545, any text string is also appropriate.

Comment 1

[[:MakeMyDay]]

Philipp, there is __LIGHTNING_VERSION__ for the version number - is there a similar constant for the application name available (I didn't find one) which is used by Debian,Ubuntu,... maintainers to change the app name?

Comment 2

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

I've thought about this in the past and there is a potential privacy/security issue if we include this information. Lets say there is a remotely exploitable security bug in a certain Lightning version that someone is still using. This person sends invitations to various people, one of which is evil. He then knows an exploited version is being used.

Also, what is the behavior on modification? If its an invitation, then the calendar server might not support changing the PRODID. You would also have to possibly ignore the PRODID when opening the event dialog and checking if the event has been changed. Lots of edge cases here, not sure its worth the effort.

If we do decide to do this, I don't think we have a constant defined anywhere, but you can get the Lightning version asynchronously through the addons manager API. I would instead suggest to use the useragent string from here. Note however that this might have been set empty by the user trying to hide the app version, so be sure to handle it.

http://mxr.mozilla.org/comm-central/source/calendar/lightning/content/lightning.js#131

Maybe we can get someone from the security group to comment on this bug.

Comment 3

[[:MakeMyDay]]

I would consider such an approach as security by obfuscation - not a good way to deal with any security issue.

Also, the user regularly provides almost all required information to perform such an attack, when he/she is sending a regular e-mail with Thunderbird. The User-Agent e-mail header of the sent message combined with the information from https://developer.mozilla.org/en-US/docs/Mozilla/Calendar/Calendar_Versions is everything you would need for your scenario.

Regarding the modification thing, this is not an issue, as the server must not rely for any operation on the delivered PRODID. Also it happens already today, that a server may receive different PRODIDs for an event (e.g. by replies from remote parties with different clients or accessing a calendar with more the one client in a mobile use scenarios).

For implementing this, I would prefer not to rely on the user editable string, as this would undermine the intention of faciliating investigations on itip/imip bugs.

Comment 4

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

(In reply to MakeMyDay from comment #3)
> I would consider such an approach as security by obfuscation - not a good
> way to deal with any security issue.
I'm not proposing to fix any security issues with this, just not exposing the information that might lead to people being interested :-)

On the other hand...

> Also, the user regularly provides almost all required information to perform
> such an attack, when he/she is sending a regular e-mail with Thunderbird.
> The User-Agent e-mail header of the sent message combined with the
You are right, the information is already available. Taking back my concern then, this change won't make it any worse.


> Regarding the modification thing, this is not an issue, as the server must
> not rely for any operation on the delivered PRODID. Also it happens already
> today, that a server may receive different PRODIDs for an event (e.g. by
> replies from remote parties with different clients or accessing a calendar
> with more the one client in a mobile use scenarios).
I'm more interested in the client side modifications. When a user opens a meeting organized by someone else to change the participation status, you need to make sure you are not changing the PRODID, because the caldav server might not allow this.

There may also be other cases where changing the PRODID is not accepted by the remote server. Google Calendar is a good candidate for testing, they are generally very restrictive.


> 
> For implementing this, I would prefer not to rely on the user editable
> string, as this would undermine the intention of faciliating investigations
> on itip/imip bugs.

The amount of users changing the user agent string is probably very low. If you use this string you are catering to the paranoid that don't want to expose their version number. Its also much easier than asynchronously retreiving the version number from the addons manager :)

Comment 5

[[:MakeMyDay]]

Attachment: AddCurrentAppVersionToIcal-v1.diff

Comment 6

[[:MakeMyDay]]

Comment on attachment 8567634 [details] [diff] [review]
AddCurrentAppVersionToIcal-v1.diff

This patch is still buggy, so taking back the review request.