[Oleg Kostenko <oleg.kostenko@xxxxxxxxxxxx>]

Guys,

So, what's the conclusion? Is this packet correct or not?

I think that:

1. If the packet is incorrect (in terms of BER-encoding), then
   the "BER error" message should be put back, but the dissection
   of the current sequence should not be aborted.

2. If we don't know whether it is correct or not, probably we should
   give warning instead of error?

3. Anyway, those 'one item of zero length' lines in the decoded
   packet tree should be changed to '0 items' or removed completely.

What do you think?
  
-- 
Best regards,
 Oleg                          mailto:spirent@xxxxxxxxxxxx


Original Message:
Date: Mon, 25 Sep 2006 17:45:39 +0200
From: "Anders Broman" <a.broman@xxxxxxxxx>
Subject: Re: [Wireshark-dev] Fwd: And again BER
        errorswhiledecodingH248packets
To: "'Developer support list for Wireshark'"
        <wireshark-dev@xxxxxxxxxxxxx>
Message-ID: <002a01c6e0b9$a6dc8800$6800a8c0@ditt7huk3o9fm5>
Content-Type: text/plain;       charset="us-ascii"

Hi,
>From below it looks like a SEQUENCE may NOT be coded as a Zero item but
SEQUENCE OF may.
Comments?

ITU-T Recommendation X.690
International Standard 8825-1
Information technology  -
ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
and Distinguished Encoding Rules (DER)
For SEQUENCE it says:
8.9     Encoding of a sequence value
8.9.1   The encoding of a sequence value shall be constructed.
8.9.2   The contents octets shall consist of the complete encoding of one
data value from each of the types listed in the ASN.1 definition of the
sequence type, in the order of their appearance in the definition, unless
the type was referenced with the keyword OPTIONAL or the keyword DEFAULT.
8.9.3   The encoding of a data value may, but need not, be present for a
type which was referenced with the keyword OPTIONAL or the keyword DEFAULT.
If present, it shall appear in the encoding at the point corresponding to
the appearance of the type in the ASN.1 definition.

For SEQUENCE OF it says:
8.10    Encoding of a sequence-of value
8.10.1  The encoding of a sequence-of value shall be constructed.
8.10.2  The contents octets shall consist of zero, one or more complete
encodings of data values from the type listed in the ASN.1 definition.
8.10.3  The order of the encodings of the data values shall be the same as
the order of the data values in the sequence of value to be encoded.

And the length encoding:
8.1.3   Length octets
8.1.3.1 Two forms of length octets are specified. These are:
a)      the definite form (see 8.1.3.3); and
b)      the indefinite form (see 8.1.3.6).
8.1.3.2 A sender shall:
a)      use the definite form (see 8.1.3.3) if the encoding is primitive;
b)      use either the definite form (see 8.1.3.3) or the indefinite form
(see 8.1.3.6), a sender's option, if the encoding is constructed and all
immediately available;
c)      use the indefinite form (see 8.1.3.6) if the encoding is constructed
and is not all immediately available.
8.1.3.3 For the definite form, the length octets shall consist of one or
more octets, and shall represent the number of octets in the contents octets
using either the short form (see 8.1.3.4) or the long form (see 8.1.3.5) as
a sender's option.
NOTE - The short form can only be used if the number of octets in the
contents octets is less than or equal to 127.
8.1.3.4 In the short form, the length octets shall consist of a single octet
in which bit 8 is zero and bits 7 to 1 encode the number of octets in the
contents octets (which may be zero), as an unsigned binary integer with bit
7 as the most significant bit.
EXAMPLE
L = 38 can be encoded as 001001102
8.1.3.5 In the long form, the length octets shall consist of an initial
octet and one or more subsequent octets. The initial octet shall be encoded
as follows:
a)      bit 8 shall be one;
b)      bits 7 to 1 shall encode the number of subsequent octets in the
length octets, as an unsigned binary integer with bit 7 as the most
significant bit;
c)      the value 111111112 shall not be used.
NOTE 1 - This restriction is introduced for possible future extension.
Bits 8 to 1 of the first subsequent octet, followed by bits 8 to 1 of the
second subsequent octet, followed in turn by bits 8 to 1 of each further
octet up to and including the last subsequent octet, shall be the encoding
of an unsigned binary integer equal to the number of octets in the contents
octets, with bit 8 of the first subsequent octet as the most significant
bit.
EXAMPLE
L = 201 can be encoded as:
        100000012
        110010012
NOTE 2 - In the long form, it is a sender's option whether to use more
length octets than the minimum necessary.
8.1.3.6 For the indefinite form, the length octets indicate that the
contents octets are terminated by end-of-contents octets (see 8.1.5), and
shall consist of a single octet.
8.1.3.6.1       The single octet shall have bit 8 set to one, and bits 7 to
1 set to zero.
8.1.3.6.2       If this form of length is used, then end-of-contents octets
(see 8.1.5) shall be present in the encoding following the contents octets.
8.1.4   Contents octets
The contents octets shall consist of zero, one or more octets, and shall
encode the data value as specified in subsequent clauses.
NOTE - The contents octets depend on the type of the data value; subsequent
clauses follow the same sequence as the definition of types in ASN.1.
8.1.5   End-of-contents octets

Brg
Anders

all that H.248  says about sequences is:

NOTE 2 - The ASN.1 specification below contains a clause defining
TerminationIDList as a
sequence of TerminationIDs. The length of this sequence SHALL be one,
except possibly when used in contextAuditResult.

Is that our case?

Luis.

On 9/25/06, Anders Broman (AL/EAB) <anders.broman@xxxxxxxxxxxx> wrote:
>
> >On 9/25/06, ronnie sahlberg <ronniesahlberg@xxxxxxxxx> wrote:
> >> Are these zero length constructs actually allowed by the standard?
> >>
> >> If they are not it might be better to just abort dissection completely
> >> with a "[malformed packet]" message.
>
> >I honestly do not know if the standard allows for that, however,
> >I do not agree with aborting dissection en tout. I believe that if we
> >can decode it we should, but an error label  (expert info) should be
> >added to the item.
> >
> >Luis
>
> If I remeber correctly the "BER" standard allows zero lengt SEQUENCE and
SEQUENCE OF, I'm haven't checked if the H.248 standard
> says anything on the subject.
> It looks though like an "unusual" implementation :)
>
> Brg
> Anders
>
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
>
>


-- 
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev