Bulk fuzz-testing report

[gcode-importer]

Originally reported on Google Code with ID 427

I've been running AFL (https://code.google.com/p/american-fuzzy-lop/) against r2924
using the process outlined in 
https://gist.github.com/acdha/7db4f1c3ddbc40aee012:

afl-fuzz -i in -o out -f test.jp2 -t 60000 -m 128 -- ~/Projects/openjpeg/bin/opj_decompress
-i test.jp2 -o test.raw

At 61% complete, this has identified 370 unique code paths which result in a crash
and 9 paths which took an unusually long period of time to run (no true hangs, however).

I'm reporting these in bulk with restricted visibility because I haven't reviewed whether
any of these are exploitable and don't want zero-day everyone if something turns out
to be exploitable.

The directory names are rather ungainly because AFL encodes its parameters in the directory
and filenames but every file should be an input which causes opj_decompress to crash.

Reported by [email protected] on 2014-11-12 21:09:58

---

- _Attachment: [openjpeg-r2924-fuzzing.zip](https://storage.googleapis.com/google-code-attachments/openjpeg/issue-427/comment-0/openjpeg-r2924-fuzzing.zip)_

[gcode-importer]

I ran a quick confirmation run on OS X using a debug build ("-O1 -g  -fno-omit-frame-pointer")
and found a number of common assertion failures:

  22 Assertion failed: (l_height == 0 || l_width + l_stride <= l_tile_comp->data_size
/ l_height), function opj_tcd_dc_level_shift_decode, file /Users/cadams/Projects/openjpeg/src/lib/openjp2/tcd.c,
line 1693.
  64 Assertion failed: (l_res->x0 >= 0), function opj_j2k_update_image_data, file /Users/cadams/Projects/openjpeg/src/lib/openjp2/j2k.c,
line 8054.
  85 Assertion failed: (l_res->x1 >= 0), function opj_j2k_update_image_data, file /Users/cadams/Projects/openjpeg/src/lib/openjp2/j2k.c,
line 8055.
 414 Assertion failed: (b), function opj_int_ceildiv, file /Users/cadams/Projects/openjpeg/src/lib/openjp2/opj_intmath.h,
line 111.

Reported by [email protected] on 2014-11-12 21:13:29

[gcode-importer]

An initial pass suggests we'll need a guarded modulo function for cases like this where
the second operand can be zero, which triggers an exception at least on x86 with GCC
or Clang:

https://code.google.com/p/openjpeg/source/browse/trunk/src/lib/openjp2/pi.c?r=2924#363
https://code.google.com/p/openjpeg/source/browse/trunk/src/lib/openjp2/pi.c?r=2924#366

(see http://stackoverflow.com/a/7370211/59984)

Reported by [email protected] on 2014-11-13 15:14:27

[gcode-importer]

What a good idea!

Reported by boxerab on 2014-11-13 18:46:59

[gcode-importer]

AFL's great, isn't it?

I've created a couple of Github repos to track code changes:

https://github.com/acdha/openjpeg-private – not much here yet but I'm planning to develop
hardening patches as pull requests here.

https://github.com/acdha/openjpeg-fuzzing – the latest copy of the current testing
results and the primitive script I've been using to rerun updated OpenJPEG builds against
all of the input files

These are obviously private repos so send me a Github username and I can add you.

Reported by [email protected] on 2014-11-13 20:49:29

[gcode-importer]

setting to Priority Critical as this issue might include several security vulnerabilities

Reported by detonin on 2014-11-19 14:34:03

• Labels added: Priority-Critical
• Labels removed: Priority-Medium

[gcode-importer]

I just pushed out the updated results with ~1,863 unique crashing paths (32.7k total
input files):

https://github.com/acdha/openjpeg-fuzzing

I need to add some docs – the collect-backtraces script runs opj_decompress on everything
using a debug build in LLDB and saves a stack backtrace from the crash point. I started
work on some common sites but as you can see haven't had time for very much at all:

https://github.com/acdha/openjpeg-private/tree/input-hardening

(https://github.com/acdha/openjpeg-private/commit/bc95e5b230f21ffc1596c89eeb96b882b4dda3ca
is also a weak commit – that prevents the crash but it really needs to be checked earlier
so that client libraries would benefit as well) 

Reported by [email protected] on 2014-11-19 15:23:31

[gcode-importer]

I re-ran this using a newer version of AFL which has better heuristics for detecting
duplicates, leaving us with a far more manageable 365 unique crash sites:

https://github.com/acdha/openjpeg-fuzzing/tree/master/results/r2948

Reported by [email protected] on 2014-12-17 15:00:03

[gcode-importer]

Reported by mayeut on 2014-12-18 22:13:34

• Status changed: Started

[gcode-importer]

This issue was updated by revision r2959.

Reported by mayeut on 2014-12-18 22:16:55

[gcode-importer]

This issue was updated by revision r2960.

Reported by mayeut on 2014-12-18 22:19:58

[gcode-importer]

This issue was updated by revision r2961.

Reported by mayeut on 2014-12-18 22:55:51

[gcode-importer]

This issue was updated by revision r2962.

Reported by mayeut on 2014-12-18 22:56:43

[gcode-importer]

I've started a new run with r2962. It's certainly taking longer to find a crash then
on previous runs.

Reported by [email protected] on 2014-12-19 19:27:54

[gcode-importer]

Some images get 0 size tiles once subsampling is applied.
I'm not sure how this should be handled according to ISO15444-1. Is it allowed or simply
forbidden ?
If would think this is not allowed, in which case the attached patch would deal with
those images being rejected.

With this patch on r2962, remains 193 crashes out of the 365 found on r2948

Reported by mayeut on 2014-12-19 19:56:00

---

- _Attachment: [issue427-0-size-tile.patch](https://storage.googleapis.com/google-code-attachments/openjpeg/issue-427/comment-14/issue427-0-size-tile.patch)_

[gcode-importer]

I also discovered that many crashes reported by the fuzzer seem to be the same as the
one that's reported in Issue 448 sample2.j2k

opj_j2k_read_tile_header returns from line 7917 (or so, with previous patch applied).
No tile has been decoded & image data is NULL for all components thus making opj_decompress
crash later on.

I don't know how this case should be handled.
In opj_j2k_decode_tiles, the last return statement may be nr_tiles ==  p_j2k->m_cp.th
* p_j2k->m_cp.tw instead of OPJ_TRUE or something like this depending on opj_set_decode_area.
This will probably need to be check in opj_j2k_get_tile as well.


Here's code snippet for line 7917 :
        /* FIXME DOC ???*/
        if ( ! p_j2k->m_specific_param.m_decoder.m_can_decode) {
                l_tcp = p_j2k->m_cp.tcps + p_j2k->m_current_tile_number;
                l_nb_tiles = p_j2k->m_cp.th * p_j2k->m_cp.tw;

                while( (p_j2k->m_current_tile_number < l_nb_tiles) && (l_tcp->m_data
== 00) ) {
                        ++p_j2k->m_current_tile_number;
                        ++l_tcp;
                }

                if (p_j2k->m_current_tile_number == l_nb_tiles) {
                        *p_go_on = OPJ_FALSE;
                        return OPJ_TRUE;
                }
        }

Reported by mayeut on 2014-12-19 20:09:10

[gcode-importer]

Similar as comment #14 :
Some crash are caused by 0 size resolution level for a given tile.

I already made a comment in the coding part (opj_j2k_encoding_validation) regarding
the number of resolution levels. (with maybe one error in the checks, see Issue 215)
To sum up, even though ISO 15444-1 specifies NL to be between 0 & 32 (inclusive), I
think that it shall be between 0 & 31. 32 would always lead to a 0 size resolution
level, I think.

Reported by mayeut on 2014-12-19 20:56:44

[gcode-importer]

You can forget that last comment... See Issue 215 for the why.

Reported by mayeut on 2014-12-19 21:52:29

[tfmorris]

You know that the label "Restrict-View-CoreTeam" is a noop on Github, right?

[rouault]

@detonin I don't have permissions apparently to access https://storage.googleapis.com/google-code-attachments/openjpeg/issue-427/comment-0/openjpeg-r2924-fuzzing.zip . Could you attach it to this ticket ? (hopefully the issues are now fixed)

[tfmorris]

All the attachments that were on Google Code are gone. It's not a permissions thing.

[rouault]

All the attachments that were on Google Code are gone. It's not a permissions thing.

That's not true. You can for example access http://storage.googleapis.com/google-code-attachments/openjpeg/issue-496/comment-0/openjpeg-svn-id000023svn-double-free-j2k_read_ppm_v3.jp2 of https://code.google.com/archive/p/openjpeg/issues/496. The issue here was that https://code.google.com/archive/p/openjpeg/issues/427 is access restricted

[detonin]

Most of the google code issues are still available (and the IDs correspond to the github ones) but this is apparently not the case for the issues that were marked as "private" in Google Code, like this one. Unfortunately, I do not know at this point a way to login back into Google Code to get access to it.
https://code.google.com/archive/p/openjpeg/

[rouault]

Google answer to our request to access those tickets : """ Unfortunately the Google Code Archive only
contains public project data, so restricted-access issues are no longer
available."""

So closing as there's nothing actionable anymore... Hopefully those issues have been spotted by other people doing fuzzing or will be by OSS-Fuzz