Chrome OS Version: latest/master
Chrome OS Platform: any

Steps To Reproduce:

$ echo H4sICO5KhVcCA2xvbACLj3fzdQyIj2dkIAUwMoQASQUgDvKPDwtwQZWND/aNZ5DB1GUIxB/RxLhqlC93qTsFzdxfkbHoUXZiGg4b/zH8B4JKBgBouubdsAAAAA== | \
base64 -d | gzip -d > loop.dump
$ vpd -f loop.dump

Expected Result:

- Do not accept invalid files.

Actual Result:

- Endless loop (or crash, see below)

How frequently does this problem reproduce?

- Always

What is the impact to the user, and is there a workaround? If so, what is
it?

The tool vpd does not end or crashes, which is of no security impact due to out of boundary reads or "infinite" out of boundary write crashing very fast.


I have attached a small proof of concept file that will lead to an endless loop upon parsing. The interesting code sequence is this "vpd string":

FE 00 FF FF  FF FF 79

Type FE leads to no output, as it means "info". The next byte, 00, will be parsed as length. 0 simply means that there is no "key" string. The next sequence, FFFFFFFF79 will be parsed as another length. This sequence will overflow int32_t, turning it negative. It is specially crafted so the negative length lets the parser end up at FE again. So the next parsed vpd string will be the same, leading to an endless loop.

You can easily crash the tool if you make the length very small, letting the offset point outside the allocated memory.

Turning FE into 01 would result in real output. For that, vpd allocates memory with "length + 1" which could overflow again into 0, which means that we write 4 gb into a 0-byte allocated area. This will clearly crash the tool due to segmentation fault.
 

Deleted: vpd.patch 943 bytes

vpd.patch 943 bytes Download