Subject: RE: [rohc] sigcomp issue sugar-3

From: [email-masked]
Date: Wed, 24 Apr 2002 11:32:53 -0500

Hi,

Re the stack_location overwritten, I'll vote for treating
it as decompression failure too. It's simple and makes sense
(though we're living in a crazy world).

Then, I don't see why we need to mandate the value of 
stack_location to be >= 56. The idea of stack_location
is to allow the compressor to specify where it wants
to grow the stack. If it screws up, then it's one way
ticket to decompression failure.

BTW, what is the reason for the mysterious reserved field 
(10-15)? Same question for the gap 16-47 (i.e. any particular
reason to put the registers at area starting 48?).

BR,
Zhigang

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Price, Richard" <[email-masked]>
Date: Thu, 25 Apr 2002 13:03:27 +0100

> > Assuming that we want to store the stack in low memory, I'd be marginally
> > happier if we call a decompression failure when the stack overwrites its
> > own stack_location. However, any solution is fine provided that it isn't
> > along the lines of "crash horribly and corrupt the memory for the entire
> > endpoint"!
> 
> Based on Mark's message today, I propose the new text I just checked in, 
> which makes the behavior in this case unpredictable (and encourages 
> DECOMPRESSION-FAILURE in a "checking" implementation).  It also defines 
> the stack in (I hope) a slightly more rigorous manner.
> 
> Comments?

Carsten,

Allowing the UDVM to behave unpredictably is dangerous from a security
perspective, because it isn't clear which implementation options pose an
unacceptable security risk.

For example, in the interests of performance it might seem sensible to
leave the initial contents of the UDVM memory undefined. However, this
would open a major security hole if an implementer chose to just reuse
the UDVM memory from the last message (possibly containing important
data that is supposed to be secure against malicious access).

Whilst I'm not particularly concerned with the exact way that stack
manipulation instructions cope with overwriting the stack_location, I
believe strongly that we shouldn't allow a particular behaviour unless
it is well-defined in the draft and has been checked for possible
security implications.

In this particular case, it turns out that the stack is written to at most
twice by any single stack manipulation instruction. Therefore it appears
that there are exactly three sensible implementation choices that do not
pose extra security risks compared with SigComp-05:

1.  When the instruction writes to the stack, if stack_location or
    stack_fill are overwritten then decompression failure is called.

2.  When the instruction first writes to the stack, if stack_location or
    stack_fill are overwritten then the old values must still be used
    when writing to the stack for a second time.

3.  When the instruction first writes to the stack, if stack_location or
    stack_fill are overwritten then the new values are used when writing
    to the stack for a second time.

Choice 1 is the simplest to describe (if not to implement). However, if
performance is a goal then the best choice appears to be 3 as it avoids
the need to protect stack_location or stack_fill at all. We can just read
the values directly from the UDVM memory when they are needed.

It would also be OK to describe all three options in the draft and let
implementers choose for themselves (although in this case it doesn't
seem to buy us anything over just making choice 3 mandatory).

Regards,

Richard