jorgelo, could you please take a look? Not familiar with this code.

I can take a look but the week after next, since I'm OOO next week.

Thanks! If there's someone else who can take a look too, please assign it to them :)

For now, Security_Impact-None to get this out of the queue since it's not obvious that this is a real vulnerability yet.

furquan@, the commit logs suggest you wrote this code. Any comments on the absence of image_size checks? Where is the data processed by this function coming from? received via fastboot? If that's the case, it may allow someone to cause RAM contents to be written to a partition, which may or may not be a problem depending on memory contents.

After looking a bit more at the code, I'm pretty sure the data is indeed an image received from fastboot. One would have to experiment with writing images with inconsistent sizes to see whether this can be exploited. One thing I'd try would be to write to a large partition but only provide a short image, then read back that partition and look at the returned data.

Anyhow, we definitely should get this addressed, so assigning to furquan@.

I'll set Impact-Stable and Severity-Low since for now given that this apparently affects production code, but we haven't come up with a plausible way to exploit this.

Yes, I will take a look.

Re#4: Yes the data is received via fastboot.

Re#5: It is not possible to read back partition from the device using fastboot. Fastboot only allows writing to partitions on the device, not reading them back.

I will push a change out to add checks for image_size.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/depthcharge/+/f24e564cef473cf9beae54963cb73147aaebfd53

commit f24e564cef473cf9beae54963cb73147aaebfd53
Author: Furquan Shaikh <furquan@chromium.org>
Date: Wed May 10 09:08:29 2017

fastboot/backend: Check image_size for overflow in sparse image write

Add proper checks in sparse image write to avoid image read beyond
image_size.

BUG= chromium:718526 
BRANCH=None
TEST=Compiles successfully.

Change-Id: I4c1d320ceaeb05cd366676123f0c67b4bb5f905f
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/499048
Reviewed-by: Aaron Durbin <adurbin@chromium.org>

[modify] https://crrev.com/f24e564cef473cf9beae54963cb73147aaebfd53/src/fastboot/backend.c
[modify] https://crrev.com/f24e564cef473cf9beae54963cb73147aaebfd53/src/fastboot/backend.h
[modify] https://crrev.com/f24e564cef473cf9beae54963cb73147aaebfd53/src/fastboot/fastboot.c

Can confirm the fix looks right.

The NextAction date has arrived: 2017-05-16

This looks like it should at least make it to the rewards panel?

Sure, we'll take a look.

I'm afraid the VRP panel declined to reward for this bug, but did say they would reconsider if you describe how this could be exploitable. Thanks!

I guess the only ways to exploit this flaw is:
- dumping/tracing partition data using external hardware attached to the storage device's bus.
- getting access to the partition when the OS is running (another vuln might be required, I am not sure).

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot