search

abema / go-mp4

Go library for reading and writing MP4 file
https://dev.to/sunfishshogi/go-mp4-golang-library-and-cli-tool-for-mp4-52o1
MIT License
464 stars 30 forks source link

Fix out-of-memory errors with mdat boxes and remove size-based checks #152

Closed aler9 closed 1 year ago

aler9 commented 1 year ago

@sunfish-shogi

While patch #150 is able to prevent RAM exhaustion with the majority of small, specially-crafted strings, it isn'effective against strings that contain mdat boxes. A short string is able to cause RAM exhaustion by setting the mdat box size to a big number.

This PR fixes the issue by replacing size-based checks with checks on the effective size of the underlying buffer, that are performed by using Seek(). In this way, an attacker may cause DoS errors if and only if he is able to upload an amount of data equal to the size of the RAM of the machine, and if there are no size checks before passing the buffer to ReadBoxStructure() or Unmarshal().

Size-based checks are performed only in case of non-uint8 slices, since it's not possible to know in advance the overall size of a generic slice.

sunfish-shogi commented 1 year ago

Thank you for PR! I missed reflect.MakeSlice in #150 .

I have only one question about this change. Could you check my comment about maxSliceCapacity?

aler9 commented 1 year ago

i edited the patch and merged the comment, thanks

sunfish-shogi commented 1 year ago

@aler9

i increased the maximum capacity to 128k

Sorry, I didn't make it clear enough. Some boxes have entries for each frames. For example, in 60fps video, it will be 216k entries per hour. So I think maxSliceCapacity should be larger than 2M.

aler9 commented 1 year ago

If that's the case, i would discard the idea of imposing a fixed cap on the array size, since it limits the use cases of this library without solving the issue, that is preventing specially-crafted strings to crash applications.

It's also impossible to know in advance the overall bit size of a field and use it to check whether there are enough bits, since some fields have a dynamic length that depends on some other fields, and it would require decoding the struct.

In my opinion the only way to solve the issue consists in replacing the static preallocation of the slice with a dynamic allocation, replacing the make() call with multiple append() calls. I know that this decreases performance, but i don't see any other way.

aler9 commented 1 year ago

I've edited the patch in order to remove the slice preallocation. Adding appends() was not necessary since they are already there.