-
Notifications
You must be signed in to change notification settings - Fork 282
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
Fix incorrect handling of request/response body data chain of ngx_buf_t buffers. #104
Conversation
…_t buffers. The documentation [http://nginx.org/en/docs/dev/development_guide.html#buffer] clearly states that .pos, .last must be used to reference actual data contained by the buffer. Whereas .start, .end denote the boundaries of the memory block allocated for the buffer (in case of dynamically allocated data) or just NULL (when .pos, .last reference a static memory location - one can see that kind of usage in ngx_http_gzip_filter_module.c:ngx_http_gzip_filter_gzheader()). To back up my words I invite to examine ngx_http_charset_filter_module.c:ngx_http_charset_recode() as an example of iteration over data contained in data buffer. Without this fix ngx_http_modsecurity_body_filter feeds random bytes from memory pointed by .start, .end range to msc_append_response_body. In my case is was 8KB of data instead of 10 bytes when referenced by (.pos, .last). That is this vulnerability may disclose sensitive data like passwords or whatever from nginx heap. The fix for ngx_http_modsecurity_pre_access_handler is to use .pos not .start to reference data as they may differ in general case.
Thank you @turchanov, i will have a look together with @defanator. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@turchanov how did you test your changes given that currently this module explicitly requires request body in temp. file: https://github.com/SpiderLabs/ModSecurity-nginx/blob/master/src/ngx_http_modsecurity_pre_access.c#L105-L106 ?
I'm seeing REQBODY_ERROR with "JSON parsing error: parse error: premature EOF\x0a" when I'm trying to POST valid JSON data with your patch applied and without hard requirements of using temp. files.
@turchanov please disregard the #104 (review) comment here, messed up things a bit. Will provide more information later. |
@turchanov this change looks good, though I'd use the Consider the following patch on top of your one:
|
dev/pull104 is now on our build bots. |
I voiced some of my concerns about |
Hi @turchanov, I did not merged to main line yet. Place it in this new branch. Waiting for @defanator's comments. |
I beg you pardon, I do not understand what do you want me to do? |
If you did ask to re-post my comments from #105, I can do it, but @defanator already answered them in #105. I'am sorry if I caused such a confusion. So what do I need to do? |
Merged. Thanks ;) |
The documentation [http://nginx.org/en/docs/dev/development_guide.html#buffer]
clearly states that .pos, .last must be used to reference actual data
contained by the buffer. Whereas .start, .end denote the boundaries of the memory
block allocated for the buffer (in case of dynamically allocated data) or just
NULL (when .pos, .last reference a static memory location - one can see that
kind of usage in ngx_http_gzip_filter_module.c:ngx_http_gzip_filter_gzheader()).
To back up my words I invite to examine
ngx_http_charset_filter_module.c:ngx_http_charset_recode() as an example of
iteration over data contained in data buffer.
Without this fix ngx_http_modsecurity_body_filter feeds random bytes from
memory pointed by .start, .end range to msc_append_response_body. In my case
is was 8KB of data instead of 10 bytes when referenced by (.pos, .last).
That is this vulnerability may disclose sensitive data like passwords or
whatever from nginx heap.
The fix for ngx_http_modsecurity_pre_access_handler is to use .pos not .start to
reference data as they may differ in general case.