Subject: Re: Where to put VTIMEZONE and VALARM?

From: [email-masked]
Date: Tue, 1 May 2001 13:17:15 -0400

Alan wrote on 05/01/2001 11:02:02 AM:
> You're assuming that an average CU is capable of recognising
> a bogus VTIMEZONE, which might be expecting a bit too much.
> 
> Remember it's not always easy to tell spam/malicious email
> from real email- just look at how email viruses manage to
> spread. 

Sure, anyone can build a CUA that is not well designed and CUs are more 
than welcome to use it and pay the price ("Ya get what you pay for" and 
"What goes around, comes around" come to mind for both CU and vendor in 
this case).  However, Id hope that a CUA that offers autoprocessing would 
have some kind of smarts in it (ie: "I only want requests from my boss to 
be autoprocessed", "Only process signed iMIP requests from domains X, Y or Z", etc) so that this is not an issue. 

After all, if I dont accept the spam then why would my CUA need or want to 
store the bogus defintions?  The bogus definitions are only useful in the 
context of the iTIP/iMIP message that my CUA is processing to start with 
and if I toss it, I can safely toss the cruft too.

>         I wouldn't even expect an average CU to be able to look
> at the source of a VTIMEZONE and decide if it's valid or not. 

Whoa Hoss.  The CU is not very likely at all to even see the TZ 
defintions.  They see the decoded iTIP request and will generally toss it 
(unless of course they love adding spam to their calendar).  If they for 
some reason accept the spam then Id expect the CUA to require some CU 
involvement before "updating" or 'overwriting" its own TZ definitions.

> If
> all CUAs accepted buggy timezones that were presented to them, those
> VTIMEZONEs could spread quickly, in a similar manner to viruses-
> imagine if my EST5EDT timezone was messed up, but only in the
> 'standard' portion; I wouldn't realise until October.

I think that Erics current proposal is NOT that the bogus defintions would 
be propigated but rather that each app would encode the TZ information 
from its own internal table of TZ definitions.  That is, I may get (and 
for some reason) accept your spam that adds a new 
North_America/Los_Angeles to my system but it will have a different 
product and/or version info in it.  As such my CUA would not be resending 
it out in any of my requests, it would use its own internal table w/its 
own product name and version on it.  If the offending spam came in w/the 
same TZID as my own CUAs then my CUA could safely ignore it (ie: "I 
already know what ~Lotus/Notes/1/North_America/Los_Angeles/ is so I dont 
need to use the senders TZ info")

If for some reason my CUA wanted keep the spam TZ info and it was forged 
so that it appeared to be a 'newer' version of the TZ definition then the 
CUA should have some reasonable behaviour like prompt the CU that a 
'newer' TZ definition is (or "may be") available and what do they want to 
do w/it.  If it came in on some spam then I would expect the CUs to do 
nothing!   Afterall you can only protect a CU from themselves for so long 
before its just 10 lines of code and 10,000 lines of safety netting. 
Better that the CUA make it something that takes cogntive action on the 
part of the CU _before_ the suspect (or real) TZ defs are added to the 
system!! 

> It would also be kind of annoying though to be in the position
> where another vendor's bugs can mess up my TZ database- 

Please reread Erics proposal.  His proposal does not say that your CUA 
would absorb and reuse the bogus TZ info.  I believe that his intent is 
still that your CUA would continue to use its own tables for all outbound 
stuff w/possibly the exception of delegations or "party crashing".  Eric 
can confirm or deny this though.    As such, the bogus data wont be 
mucking up your normal workflow process since it is only applied to the 
entry(s) that it came in on.

> It would also be kind of annoying though to be in the position
> where another vendor's bugs can mess up my TZ database- 
> [Snip, snip]                    it wouldn't feel
> like my own CUA was very robust.

Given the format of Erics TZID, your vendor and product ID wont match the 
crufty CUAs vendor and product ID so a poor CUAs defintions wont be 
messing up your CUAs (unless your CUA is poorly designed too and reuses 
someone elses TZ info as their own). 

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Eric Busboom <[email-masked]>
Date: Thu, 3 May 2001 10:46:15 -0700 (PDT)

On Tue, 1 May 2001 [email-masked] wrote:

> from its own internal table of TZ definitions. 

Exactly. A CUA will use its own TZ database for outgoing messages, not the
VTIMEZONES that is collects in its calendar. To do otherwise would result
in a nasty Internet-wide bootstrapping problem.

The only VTIMEZONES that should get into the victim's calendar are those
that have TZIDs that are not already in the calendar -- if the CUA expects
all TZIDs of the same value to map to the same VTIMEZONE, then it should
choose to keep only the first one it receives, not the last. 

Recap of the problem we are discussing, as I understand it: 

	Maillicious CUA sends an event with a VTIMEZONE that contains a
	TZID that conflicts with ( or will conflict with ) another TZID in the
	victim's calendar

In order for this attack to work:

	1) The attacker has to guess what timezones the recipient will
	receive and from what timezone database the VTIMEZONES will be
	created. For each attack message, the attacker would have to
	choose a TZID with a vendor name, a timezone name, a timezone version, and
	possibly a vendor database name, and all of those must map to at
	TZID that the victim will eventually use in the future. 

	2) The attacker must be the first to send the victim such a
	VTIMEZONE

	3) The victim has to book the incoming attack event in the
	calendar.

What is the payoff for the attacker? The victim might show up
late for a few meetings. That's not going to get the crackers, script
kiddies and disgruntled IT techs excited. 

If a CUA implementer does want to tackle to problem, they just need
to compare incoming VTIMEZONES to ones with the same TZID in the calendar
and issue a notice if there is a difference.

So, we've got an extremely unlikely attack that has a small payoff and a
simple fix. I really don't think we need to worry about this. 

eric.