New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Heap-buffer-overflow in fallback-motion.cc: void put_epel_hv_fallback<unsigned short>( #345
Comments
|
Hi (in advance, sorry for the wall of text… I'm just trying to convey as much information as I was debugging into this crash and like to share my findings. I've using a lots of additional printfs for debugging output, the branch I'm using I've compiled it on Debian unstable with asan, cmake invocation: The complete log of poc11-1 is here (using my debug code)
TL;DR: I think (not sure if I read the standard correctly here) that This tricks the decoder to mix different images generated with different SPS is the same decoded pictures, How to Fix? Said that here I've got an fix to at least avoid the crashes, by One way would be just to look at the pointers of the SPS (fast and easy, but (I'll submit as PR later, after cleaning it up, to have a better base Some other observations:
** verbose debug log** I believe the poc11-1 does this evil: (- Generating
(- output of image
At this point the DPB contains: (- output of image
Now
Taking a look at the SHDR, I can reconfirm that the reference set contains: -
|
See strukturag#345 for my analysis and details… (This PR is just for discussion.) (The CVE references are obtained from the Debian security tracker, which links the issues.) This makes the following POCs stop failing: - poc3 (strukturag#337) - poc7-1 (strukturag#341) CVE-2022-43239 (note: does NOT fix poc7-2) - poc8-2, poc8-3, poc8-4 (strukturag#342) CVE-2022-43244 (note: does NOT fix poc8-1) - poc11-1, poc11-2 (strukturag#345) CVE-2022-43249 - poc12 (strukturag#346) - poc13 (strukturag#347) CVE-2022-43252 - poc16 (strukturag#350)
|
libdec265-poc11-1-withdump.txt
|
|
According to Debian this is CVE-2022-43249 |
(as e.g mc_chroma is using the sps to determine picture properties, like pic_width_in_luma_samples and pic_height_in_luma_samples, I *think* this is more correct. This PR is for discussion. (See strukturag#345.) It makes the failures go away, but that does not mean it's correct :) The following poc will be stop failing if (only) this patch is applied: - poc2 strukturag#336 - CVE-2022-43238 - poc4 strukturag#338 - CVE-2022-43241 - poc6-1, poc6-2 strukturag#340 - CVE-2022-43242 - poc7-1, poc7-2 strukturag#341 - CVE-2022-43239 - poc8-1 strukturag#342 - CVE-2022-43244 - poc9-3 strukturag#343 - CVE-2022-43236 - poc10-2, poc10-3 strukturag#344 - CVE-2022-43237 - poc16 strukturag#350 - poc19 strukturag#353 The following are still failing if only this patch is applied, but they stop failing if strukturag#365 is applied as well, but will still fail with ONLY strukturag#365 applied (IOW, both are needed) - poc1 strukturag#335 - CVE-2022-43240 - poc3 strukturag#337 - CVE-2022-43235 - poc5 strukturag#339 - CVE-2022-43423 - poc9-1,poc9-2, poc9-4 strukturag#343 - CVE-2022-43236 - poc14 strukturag#348 - CVE-2022-43253 - poc15 strukturag#349 - CVE-2022-43248 - poc17-1, poc17-2 strukturag#351 - poc18 strukturag#352 - CVE-2022-43245
This is an attempt to improve the mitigations from strukturag#365 and strukturag#366 and picks up an idea I described at strukturag#345: > One way would be just to look at the pointers of the SPS (fast and easy, but > may reject more than required), or investigate if the SPS used for the image > generations are "compatible". This changes do exactly this: It (very conservativly) checks if the old and new sps have identical information -- except the reference picture set, which I believe is supposed to be updated by new sps'). If they are basically identical, the old sps will be used instead of the new one, (of course, reference image set is updated from the new one) I'm using standalone operator== and helper functions to avoid changing ABI of the library; if an ABI bump would be done, of course this should go to the respective classes. I've tested the patch with several videos, they still play fine. @farindk I'd really appreciate to receive your feedback; the reason is that I want to fix the many open CVE's for the package as it is currently in Debian and other distributions… -- Cheers, tobi
This is an attempt to improve the mitigations from strukturag#365 and strukturag#366 and picks up an idea I described at strukturag#345: > One way would be just to look at the pointers of the SPS (fast and easy, but > may reject more than required), or investigate if the SPS used for the image > generations are "compatible". This changes do exactly this: It (very conservativly) checks if the old and new sps have identical information -- except the reference picture set, which I believe is supposed to be updated by new sps'). If they are basically identical, the old sps will be used instead of the new one, (of course, reference image set is updated from the new one) I'm using standalone operator== and helper functions to avoid changing ABI of the library; if an ABI bump would be done, of course this should go to the respective classes.
|
Thanks for the extensive analysis and patch. While your patch tries to prevent the situation by detecting it high-level, it is complicated to compare SPSs for "compatibility" and whether they are simply repeated (51f07f1). I think, this is very error prone. Checking for matching bit-depth directly, on the other hand, secures the function itself, which may also be helpful if used in another context. And it also allows us to output a warning what actually is wrong with the input stream. There might be a performance penalty in carrying out this check for each PB, but here I simply hope for a good branch prediction. |
This was my first approach, and while it fixes that specific exploit bitdepth is not the only paramter to be checked; for example I saw also crashes out of the poc if the dimensions where not matching the expectaions. Comparing the sps is of course a "brute force" attempt to fix that; The patch to check for compatiblity was only for to avoid over-rejecting. My reference videos played well without it, but I thought "better save here". This patch is also erroring on the "it's incompatible if in doubt" side. |
|
Should be fixed with #373 |
|
@coldtobi The ideal check would be on several levels. I think it is important that each function checks that its input parameters are valid. Furthermore, there can be another high-level check whether the SPS packets in the input stream are valid. I see this mainly as a better error reporting instead of a wall of low-level errors. Hence, I'll go with the low-level fix for the moment, but leave your pull-requests open so that we can look at this again to improve error reporting. |
Description
Heap-buffer-overflow (/libde265/build/libde265/liblibde265.so+0x148fda) in void put_epel_hv_fallback(short*, long, unsigned short const*, long, int, int, int, int, short*, int)
Version
Replay
ASAN
WARNING: pps header invalid WARNING: CTB outside of image area (concealing stream error...) WARNING: CTB outside of image area (concealing stream error...) ================================================================= ==61372==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62b00002951c at pc 0x7f3e99904fdb bp 0x7ffe34d063b0 sp 0x7ffe34d063a0 READ of size 2 at 0x62b00002951c thread T0 #0 0x7f3e99904fda in void put_epel_hv_fallback<unsigned short>(short*, long, unsigned short const*, long, int, int, int, int, short*, int) (/libde265/build/libde265/liblibde265.so+0x148fda) #1 0x7f3e999332ca in acceleration_functions::put_hevc_epel_hv(short*, long, void const*, long, int, int, int, int, short*, int) const (/libde265/build/libde265/liblibde265.so+0x1772ca) #2 0x7f3e99935213 in void mc_chroma<unsigned short>(base_context const*, seq_parameter_set const*, int, int, int, int, short*, int, unsigned short const*, int, int, int, int) (/libde265/build/libde265/liblibde265.so+0x179213) #3 0x7f3e99925b2d in generate_inter_prediction_samples(base_context*, slice_segment_header const*, de265_image*, int, int, int, int, int, int, int, PBMotion const*) (/libde265/build/libde265/liblibde265.so+0x169b2d) #4 0x7f3e9993290f in decode_prediction_unit(base_context*, slice_segment_header const*, de265_image*, PBMotionCoding const&, int, int, int, int, int, int, int, int) (/libde265/build/libde265/liblibde265.so+0x17690f) #5 0x7f3e9996d7e3 in read_prediction_unit(thread_context*, int, int, int, int, int, int, int, int, int) (/libde265/build/libde265/liblibde265.so+0x1b17e3) #6 0x7f3e9996f39a in read_coding_unit(thread_context*, int, int, int, int) (/libde265/build/libde265/liblibde265.so+0x1b339a) #7 0x7f3e99970250 in read_coding_quadtree(thread_context*, int, int, int, int) (/libde265/build/libde265/liblibde265.so+0x1b4250) #8 0x7f3e99970091 in read_coding_quadtree(thread_context*, int, int, int, int) (/libde265/build/libde265/liblibde265.so+0x1b4091) #9 0x7f3e99967726 in read_coding_tree_unit(thread_context*) (/libde265/build/libde265/liblibde265.so+0x1ab726) #10 0x7f3e999709ea in decode_substream(thread_context*, bool, bool) (/libde265/build/libde265/liblibde265.so+0x1b49ea) #11 0x7f3e9997270f in read_slice_segment_data(thread_context*) (/libde265/build/libde265/liblibde265.so+0x1b670f) #12 0x7f3e998d16d2 in decoder_context::decode_slice_unit_sequential(image_unit*, slice_unit*) (/libde265/build/libde265/liblibde265.so+0x1156d2) #13 0x7f3e998d1ec1 in decoder_context::decode_slice_unit_parallel(image_unit*, slice_unit*) (/libde265/build/libde265/liblibde265.so+0x115ec1) #14 0x7f3e998d0c0f in decoder_context::decode_some(bool*) (/libde265/build/libde265/liblibde265.so+0x114c0f) #15 0x7f3e998d093d in decoder_context::read_slice_NAL(bitreader&, NAL_unit*, nal_header&) (/libde265/build/libde265/liblibde265.so+0x11493d) #16 0x7f3e998d343e in decoder_context::decode_NAL(NAL_unit*) (/libde265/build/libde265/liblibde265.so+0x11743e) #17 0x7f3e998d3ab3 in decoder_context::decode(int*) (/libde265/build/libde265/liblibde265.so+0x117ab3) #18 0x7f3e998bae95 in de265_decode (/libde265/build/libde265/liblibde265.so+0xfee95) #19 0x55a40ac18bc9 in main (/libde265/build/dec265/dec265+0x6bc9) #20 0x7f3e993ecc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) #21 0x55a40ac169b9 in _start (/libde265/build/dec265/dec265+0x49b9) 0x62b00002951c is located 12 bytes to the right of 25360-byte region [0x62b000023200,0x62b000029510) allocated by thread T0 here: #0 0x7f3e99de3790 in posix_memalign (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdf790) #1 0x7f3e9990c1cb in ALLOC_ALIGNED(unsigned long, unsigned long) (/libde265/build/libde265/liblibde265.so+0x1501cb) #2 0x7f3e9990c99d in de265_image_get_buffer(void*, de265_image_spec*, de265_image*, void*) (/libde265/build/libde265/liblibde265.so+0x15099d) #3 0x7f3e9990ed1a in de265_image::alloc_image(int, int, de265_chroma, std::shared_ptr<seq_parameter_set const>, bool, decoder_context*, long, void*, bool) (/libde265/build/libde265/liblibde265.so+0x152d1a) #4 0x7f3e998f30cc in decoded_picture_buffer::new_image(std::shared_ptr<seq_parameter_set const>, decoder_context*, long, void*, bool) (/libde265/build/libde265/liblibde265.so+0x1370cc) #5 0x7f3e998d4824 in decoder_context::generate_unavailable_reference_picture(seq_parameter_set const*, int, bool) (/libde265/build/libde265/liblibde265.so+0x118824) #6 0x7f3e998d7332 in decoder_context::process_reference_picture_set(slice_segment_header*) (/libde265/build/libde265/liblibde265.so+0x11b332) #7 0x7f3e998dad70 in decoder_context::process_slice_segment_header(slice_segment_header*, de265_error*, long, nal_header*, void*) (/libde265/build/libde265/liblibde265.so+0x11ed70) #8 0x7f3e998d0246 in decoder_context::read_slice_NAL(bitreader&, NAL_unit*, nal_header&) (/libde265/build/libde265/liblibde265.so+0x114246) #9 0x7f3e998d343e in decoder_context::decode_NAL(NAL_unit*) (/libde265/build/libde265/liblibde265.so+0x11743e) #10 0x7f3e998d3ab3 in decoder_context::decode(int*) (/libde265/build/libde265/liblibde265.so+0x117ab3) #11 0x7f3e998bae95 in de265_decode (/libde265/build/libde265/liblibde265.so+0xfee95) #12 0x55a40ac18bc9 in main (/libde265/build/dec265/dec265+0x6bc9) #13 0x7f3e993ecc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86) SUMMARY: AddressSanitizer: heap-buffer-overflow (/libde265/build/libde265/liblibde265.so+0x148fda) in void put_epel_hv_fallback<unsigned short>(short*, long, unsigned short const*, long, int, int, int, int, short*, int) Shadow bytes around the buggy address: 0x0c567fffd250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c567fffd260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c567fffd270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c567fffd280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c567fffd290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0c567fffd2a0: 00 00 fa[fa]fa fa fa fa fa fa fa fa fa fa fa fa 0x0c567fffd2b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c567fffd2c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c567fffd2d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c567fffd2e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c567fffd2f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==61372==ABORTINGPOC
https://github.com/FDU-Sec/poc/blob/main/libde265/poc11-1
https://github.com/FDU-Sec/poc/blob/main/libde265/poc11-2
Environment
Credit
Peng Deng (Fudan University)
The text was updated successfully, but these errors were encountered: