Change in ...libosmocore[master]: vty/vty.c: fix vty_read(): prevent further heap-buffer overrun

[Vadim Yanitskiy]

Vadim Yanitskiy has submitted this change and it was merged. ( https://gerrit.osmocom.org/c/libosmocore/+/14973 )

Change subject: vty/vty.c: fix vty_read(): prevent further heap-buffer overrun
......................................................................

vty/vty.c: fix vty_read(): prevent further heap-buffer overrun

After reading data from the socket, assigned to a given VTY, we
need to '\0'-terminate the received string. Otherwise, further
access to that string, stored in a heap buffer vty->buf, would
lead to a heap overrun.

== How to reproduce?

  $ python -c "print 'A' * 512" | telnet $HOST $PORT

  ==21264==ERROR: AddressSanitizer: heap-buffer-overflow on address
                                    0x6190000211e0 at pc 0x000000435d2f
				    bp 0x7ffc06c7add0 sp 0x7ffc06c7a578
  READ of size 1025 at 0x6190000211e0 thread T0
    #0 0x435d2e in __interceptor_strlen (/usr/local/bin/osmo-msc+0x435d2e)
    #1 0x7fb95bfa5624 in talloc_strdup (/usr/lib/x86_64-linux-gnu/libtalloc.so.2+0x6624)
    #2 0x7fb95c1be2bc in vty_hist_add /opt/osmocom/libosmocore/src/vty/vty.c:578
    #3 0x7fb95c1be2bc in vty_execute /opt/osmocom/libosmocore/src/vty/vty.c:703
    #4 0x7fb95c1be2bc in vty_read /opt/osmocom/libosmocore/src/vty/vty.c:1425
    #5 0x7fb95c1bfd78 in client_data /opt/osmocom/libosmocore/src/vty/telnet_interface.c:157
    #6 0x7fb95b90bd33 in osmo_fd_disp_fds /opt/osmocom/libosmocore/src/select.c:223
    #7 0x7fb95b90bd33 in osmo_select_main /opt/osmocom/libosmocore/src/select.c:263
    #8 0x5006cc in main /opt/osmocom/osmo-msc/src/osmo-msc/msc_main.c:723:3
    #9 0x7fb959935f44 in __libc_start_main /build/eglibc-xkFqqE/eglibc-2.19/csu/libc-start.c:287
    #10 0x4226fb in _start (/usr/local/bin/osmo-msc+0x4226fb)

== Why exactly 512?

Because the initial size of the heap buffer is 512 (see VTY_BUFSIZ).
Later on it can be realloc()ated, so X > 512 should also work.

Found using AddressSanitizer and Radamsa [1] fuzzer.

[1] https://gitlab.com/akihe/radamsa

Change-Id: I82f774ad18d0e555eb8f3590a519946d9c583c78
---
M src/vty/vty.c
1 file changed, 2 insertions(+), 0 deletions(-)

Approvals:
  laforge: Looks good to me, but someone else must approve
  pespin: Looks good to me, approved
  Jenkins Builder: Verified



diff --git a/src/vty/vty.c b/src/vty/vty.c
index 98b332d..b1bb3f4 100644
--- a/src/vty/vty.c
+++ b/src/vty/vty.c
@@ -1416,6 +1416,8 @@
 		case '\n':
 		case '\r':
 			vty_out(vty, "%s", VTY_NEWLINE);
+			/* '\0'-terminate the command buffer */
+			vty->buf[vty->length] = '\0';
 			vty_execute(vty);
 			break;
 		case '\t':

-- 
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/14973
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: I82f774ad18d0e555eb8f3590a519946d9c583c78
Gerrit-Change-Number: 14973
Gerrit-PatchSet: 4
Gerrit-Owner: Vadim Yanitskiy <axilirator at gmail.com>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: Vadim Yanitskiy <axilirator at gmail.com>
Gerrit-Reviewer: laforge <laforge at gnumonks.org>
Gerrit-Reviewer: pespin <pespin at sysmocom.de>
Gerrit-CC: neels <nhofmeyr at sysmocom.de>
Gerrit-MessageType: merged
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20190730/0ab3cde0/attachment.htm>