Re: [Qemu-devel] [PATCH v3 03/19] qemu-nbd: Sanity check partition bounds

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 4142 bytes --]

On 1/15/19 10:20 AM, Vladimir Sementsov-Ogievskiy wrote:
> 12.01.2019 20:57, Eric Blake wrote:
>> When the user requests a partition, we were using data read
>> from the disk as disk offsets without a bounds check. We got
>> lucky that even when computed offsets are out-of-bounds,
>> blk_pread() will gracefully catch the error later (so I don't
>> think a malicious image can crash or exploit qemu-nbd, and am
>> not treating this as a security flaw), but it's better to
>> flag the problem up front than to risk permanent EIO death of
>> the block device down the road.  Also, note that the
>> partition code blindly overwrites any offset passed in by the
>> user; so make the -o/-P combo an error for less confusion.
>>
>> This can be tested with nbdkit:
>> $ echo hi > file
>> $ nbdkit -fv --filter=truncate partitioning file truncate=64k
>>
>> Pre-patch:
>> $ qemu-nbd -p 10810 -P 1 -f raw nbd://localhost:10809 &
>> $ qemu-io -f raw nbd://localhost:10810
>> qemu-io> r -v 0 1
>> Disconnect client, due to: Failed to send reply: reading from file failed: Input/output error
>> Connection closed
>> read failed: Input/output error
>> qemu-io> q
>> [1]+  Done                    qemu-nbd -p 10810 -P 1 -f raw nbd://localhost:10809
>>
>> Post-patch:
>> $ qemu-nbd -p 10810 -P 1 -f raw nbd://localhost:10809
>> qemu-nbd: Discovered partition 1 at offset 1048576 size 512, but size exceeds file length 65536
>>
>> Signed-off-by: Eric Blake <eblake@redhat.com>
>> ---
>> v3: new patch
>> ---
>>   qemu-nbd.c | 18 +++++++++++++++++-
>>   1 file changed, 17 insertions(+), 1 deletion(-)
>>
>> diff --git a/qemu-nbd.c b/qemu-nbd.c
>> index 51b55f2e066..ff4adb9b3eb 100644
>> --- a/qemu-nbd.c
>> +++ b/qemu-nbd.c
>> @@ -1013,12 +1013,28 @@ int main(int argc, char **argv)
>>       fd_size -= dev_offset;
>>
>>       if (partition != -1) {
>> -        ret = find_partition(blk, partition, &dev_offset, &fd_size);
>> +        off_t limit;
>> +
>> +        if (dev_offset) {
>> +            error_report("Cannot request partition and offset together");
> 
> hmm, but you still allow to request partition and set -o 0, I think it's better
> to forbid it too.

Not worth the bother. Someday, we may want to permit -o and -P together,
where we first calculate the bounds of the partition from -P, and then
use -o to further restrict an even smaller subset of the image exposed
to the user.  Under that interpretation, the added error makes sense as
a short-term stop-gap that prevents us from doing what we want (since we
did not actually treat a non-zero offset as an offset within the
partition), but an offset of 0 is the same as omitting the offset.  So I
didn't see the point to complicate the code just to check whether -o had
been explicitly supplied with its already-default value.

> 
>> +            exit(EXIT_FAILURE);
>> +        }
>> +        ret = find_partition(blk, partition, &dev_offset, &limit);
>>           if (ret < 0) {
>>               error_report("Could not find partition %d: %s", partition,
>>                            strerror(-ret));
>>               exit(EXIT_FAILURE);
>>           }
>> +        /* partition limits are (32-bit << 9); can't overflow 64 bits */
>> +        assert(dev_offset >= 0 && dev_offset + limit >= dev_offset);
> 
> hmm, so these values are read from file and may be whatsoever. Why to assert instead
> of error_report and exit() ?

The assertion is letting the compiler know that we can't get a negative
value.  (off_t)(uint32_t << 9)*2 is always a positive value for 64-bit
off_t, but the compiler doesn't necessarily know that ((off_t)a +
(off_t)b >= a) is going to be true if it doesn't track the range
limitations imposed by find_partition().  You are right that we are
doing an assertion based on data obtained by reading from potentially
malicious data, but the assertion is safe because it will NEVER fail,
but is rather augmenting the compiler's data-type analysis.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]