[ https://issues.apache.org/jira/browse/AXIS2C-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bill Blough closed AXIS2C-1644. ------------------------------- Fix Version/s: (was: 1.7.0) Resolution: Duplicate > Buffer overflow in axis2_simple_http_svr_conn_write_response() > -------------------------------------------------------------- > > Key: AXIS2C-1644 > URL: https://issues.apache.org/jira/browse/AXIS2C-1644 > Project: Axis2-C > Issue Type: Bug > Components: transport/http > Affects Versions: 1.6.0 > Reporter: Ralph Loader > Priority: Major > Labels: security > > Valgrind found a heap buffer overflow by a single byte in [a slightly > modified] axis2-c 1.6.0. > Out of caution, I am marking this as a security issue, although I am > uncertain as to how practical it would be to exploit. > Looking at the source code, I believe that the issue still exists in svn > trunk, and that my local modifications are not related to the buffer > overflow. I have not tested that belief beyond reading the source code. > The issue is that the addition of a single terminating NUL character in > axis2_simple_http_svr_conn_write_response() is not guarded by a check for > available space: > response_body[body_size] = AXIS2_ESC_NULL; > (line 287 of simple_http_svr_conn.c in subversion trunk rev 1496107). > Here is the original valgrind output; although the line numbers are > completely different, I do not believe that the underlying logic is different > between my version and the svn trunk version. > ==18852== Invalid write of size 1 > ==18852== at 0x56B8BD0: axis2_simple_http_svr_conn_write_response > (simple_http_svr_conn.c:543) > ==18852== by 0x56BD2B0: axis2_http_worker_process_request > (http_worker.c:1970) > ==18852== by 0x5D728AD: axis2_svr_thread_worker_func > (http_svr_thread.c:265) > ==18852== by 0x5D72666: axis2_http_svr_thread_run (http_svr_thread.c:164) > ==18852== by 0x5D72025: axis2_http_server_start (http_receiver.c:298) > ==18852== by 0x58E9F9D: axis2_transport_receiver_start > (transport_receiver.c:45) > ==18852== by 0x411220: main (http_server_main.c:223) > ==18852== Address 0x6ec3990 is 0 bytes after a block of size 2,048 alloc'd > ==18852== at 0x4C228B8: malloc (vg_replace_malloc.c:270) > ==18852== by 0x54853BF: axutil_allocator_malloc_impl (allocator.c:75) > ==18852== by 0x5487245: axutil_stream_create_basic (stream.c:247) > ==18852== by 0x56B908B: axis2_http_worker_process_request > (http_worker.c:118) > ==18852== by 0x5D728AD: axis2_svr_thread_worker_func > (http_svr_thread.c:265) > ==18852== by 0x5D72666: axis2_http_svr_thread_run (http_svr_thread.c:164) > ==18852== by 0x5D72025: axis2_http_server_start (http_receiver.c:298) > ==18852== by 0x58E9F9D: axis2_transport_receiver_start > (transport_receiver.c:45) > ==18852== by 0x411220: main (http_server_main.c:223) > Incidently, it may just have been luck, but this showed up immediately the > first time I tried axis2c under valgrind. That suggests to me that the axis2c > developers have not been regularly running their code under valgrind. Can I > humbly suggest that they may wish to consider doing that? -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: c-dev-unsubscr...@axis.apache.org For additional commands, e-mail: c-dev-h...@axis.apache.org