Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upInteger overflow related to reg->dmax in search_in_range (regexec.c) #164
Comments
This comment has been minimized.
This comment has been minimized.
I could not reproduce the same result(SEGV). |
This comment has been minimized.
This comment has been minimized.
You can make it crash by changing a, b in x{a}{b}0. |
This comment has been minimized.
This comment has been minimized.
Yes. |
This comment has been minimized.
This comment has been minimized.
This was assigned CVE-2019-19012. |
This comment has been minimized.
This comment has been minimized.
Hi, |
This comment has been minimized.
This comment has been minimized.
I'm not going to do anything about this or anything else. |
This comment has been minimized.
This comment has been minimized.
I backported the 5 patches to 5.9.5. Comments welcome: |
This comment has been minimized.
This comment has been minimized.
I have not confirmed the execution. (1) Casting with ptrdiff_t is unnecessary. (2) The last change is different from me.
|
This comment has been minimized.
This comment has been minimized.
Thanks a lot for having a look. (1) I missed one ptrdiff_t when applying 778a43d , this is now fixed (and I dropped the extra #include as well). (2) the original 5.x file is different too and doesn't use For execution I tested with Updated 5.x patch: CVE-2019-19012.patch.zip |
This comment has been minimized.
This comment has been minimized.
I confirmed the contents. |
This comment has been minimized.
This comment has been minimized.
Thank you. |
Hello,
I found an integer overflow in search_in_range at regexec.c:5365:
reg->dmax is max repeat num, whose type is unsigned int. ONIG_MAX_REPEAT_NUM is 100000, but it can be multiplied into a very large number with distance_multiply at:
And Sch_range is a pointer. So if compiled in 32bit, sch_range += reg->dmax results into integer overflow.
There should be other places related to reg->dmax/dmin which are vulnerable to integer overflow.
PoC:
Compilation:
Output with pattern = x{55380}{77548}0 and string = x:
In sunday_quick_search, the PoC gets crashed because p points to an invalid memory address. If it does not crash, p luckily points to a valid memory address.
That it crashes or does not crash depends on the supplied pattern. This bug at least can be used to detect if the target system is 32bit or not. And if the target system is 32bit, is the KASLR is enable or not (constantly crashes or constantly no-crashes means no KASLR).
--
Thanks & Regards,
Nguyễn Đức Mạnh
[E] v.manhnd@vincss.net