Re: [reSIProcate] Timer vulnerability
I recommend using the Date header from the 200 to the REGISTER as
david also suggests and using this as a time base. Once we switch to
TLS for our transport, we can be certain that this value has not been
tampered with.
Jason
On Apr 4, 2005 8:24 AM, david Butcher <david@xxxxxxxxxxxxxx> wrote:
> Quoting Kenneth Ho <kenho@xxxxxxxxxxxxxx>:
>
> This sort of thing has been considered.
> Less from a hack perspective than from robustness.
>
> Largely, anyone can get a stack that sends whatever, whenever. So locking down
> the client is helpful only if there is a particularly nasty and easy client
> hack. Such attacks are always possible so must be dealt with elsewehere
> (possibly as well).
>
> There are calendar time functions, such as the Date header.
>
> david
>
>
> > We are experiencing users hacking our client software on windows. They
> > do so by manipulating windows system time. Which causes timers to be
> > fired prematurely and incur undesired behavior in the stack.
> >
> > As a counter to these hacks, I plan to change Timer::getSystemTime() to
> > use GetTickCount() instead of GetSystemTime() for windows. The drawbacks
> > are:
> > 1. The value returned would have less precision. From 1/million second
> > to 1/thousand second, but remain the same unit (1/million second). Which
> > should not be a big deal, at least on Windows anyhow.
> > 2. The value returned would not be associated to calendar time anymore.
> > This worries me somewhat, I am not sure if anyone uses this function in
> > such a way.
> >
> > Ken
> >
> >
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> >
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>