Security issue due to size_t overflows in pb_dec_string/bytes

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Put 0xFFFFFFFF as string length in encoded protobuf buffer
2. Decode using pb_decode()
3. Depending on platform, pb_dec_string() will either write a null terminator 
outside field bounds, or write up to 4 GB of attacker controlled data outside 
field bounds.

Possible consequences of bug:
    1) Denial of service by causing a crash
       Possible when all of the following apply:
          - Untrusted data is passed to pb_decode()
          - The top-level message contains a static string field as the first field.
       Causes a single write of '0' byte to 1 byte before the message struct.

    2) Remote code execution
       Possible when all of the following apply:
          - 64-bit platform
          - The message or a submessage contains a static string field.
          - Decoding directly from a custom pb_istream_t
          - bytes_left on the stream is set to larger than 4 GB
       Causes a write of up to 4 GB of data past the string field.

Original issue reported on code.google.com by Petteri.Aimonen on 11 Sep 2014 at 3:52

[GoogleCodeExporter]

Original comment by Petteri.Aimonen on 11 Sep 2014 at 4:31

• Changed state: FixedInGit
• Removed labels: Restrict-View-Commit

[GoogleCodeExporter]

    3) Possible heap corruption or remote code execution
       Possible when all of the following apply:
          - less than 64-bit platform
          - The message or a submessage contains a pointer-type bytes field.
       Causes a write of sizeof(pb_size_t) bytes of data past a 0-byte long
       malloc()ed buffer. On many malloc() implementations, this causes at
       most a crash. However, remote code execution through a controlled jump
       cannot be ruled out.

Original comment by Petteri.Aimonen on 11 Sep 2014 at 4:50

[GoogleCodeExporter]

Fix released in nanopb-0.3.1

Original comment by Petteri.Aimonen on 11 Sep 2014 at 5:13

• Changed state: FixReleased