-
Notifications
You must be signed in to change notification settings - Fork 316
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
Integer overflow related to reg->dmax in search_in_range (regexec.c) #164
Comments
I could not reproduce the same result(SEGV). |
You can make it crash by changing a, b in x{a}{b}0. |
Yes. |
This was assigned CVE-2019-19012. |
Hi, |
I'm not going to do anything about this or anything else. |
I backported the 5 patches to 5.9.5. Comments welcome: |
I have not confirmed the execution. (1) Casting with ptrdiff_t is unnecessary. (2) The last change is different from me.
|
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 |
I confirmed the contents. |
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
The text was updated successfully, but these errors were encountered: