diff options
author | gman@google.com <gman@google.com@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-07-16 02:36:10 +0000 |
---|---|---|
committer | gman@google.com <gman@google.com@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-07-16 02:36:10 +0000 |
commit | dcbbc67b1f2f8d93f3b085625c1827a7ce751b80 (patch) | |
tree | 4ccf53bb5e236c7a0b80100da62ccdfaf7291487 /chrome | |
parent | bdee626afdb33cdb928a34bfbd141a339c9a869d (diff) | |
download | chromium_src-dcbbc67b1f2f8d93f3b085625c1827a7ce751b80.zip chromium_src-dcbbc67b1f2f8d93f3b085625c1827a7ce751b80.tar.gz chromium_src-dcbbc67b1f2f8d93f3b085625c1827a7ce751b80.tar.bz2 |
Some security fixes for Skin and Curve deseralization.
Both Curve and Skin have the issue that the format
does not store any kind of length.
So, I serialize a Skin to binary, followed but some other data
in the same binary. Then at runtine I can deserialize the Skin
and call mySkin.setFromRaw(rawData, validOffset, INVALID_LENGTH)
At which point there the possibility, how ever small, that
the skin deserialization code will read into the next
chunk of binary data in the RawData. Data that does not belong
to it.
The best solution IMO would be to add a length or count to
the Skin and Curve formats since then, like Buffer, it would
know exactly how much data is expected and if the length
passed in does not match the length the format says it needs
it would fail.
Unfortunately, that would break all assets out there.
This fix just makes sure that if we do get any kind of error
the data is not left in the Skin or Curve like it was before.
Should probably do the same with Buffer.
Review URL: http://codereview.chromium.org/155599
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20841 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome')
0 files changed, 0 insertions, 0 deletions