Package: mt-daapd
Version: 0.9~r1696-1.2
Severity: grave
Hi,
I found a security issue in mt-daapd:
This is an integer overflow leading to a heap-based buffer overflow in
the ws_getpostvars function.
>From src/webserver.c:
707 int ws_getpostvars(WS_CONNINFO *pwsc) {
708 char *content_length;
709 unsigned char *buffer;
710 uint32_t length;
711 uint32_t ms;
....
715 content_length = ws_getarg(&pwsc->request_headers,"Content-Length");
....
722 length=atoi(content_length);
723 ws_dprintf(L_WS_DBG,"Thread %d: Post var length: %d\n",
724 pwsc->threadno,length);
725
726 buffer=(unsigned char*)malloc(length+1);
....
739 if(!io_read_timeout(pwsc->hclient, buffer, &length, &ms)) {
....
757
758 if(!ws_getgetvars(pwsc,(char*)buffer)) {
759 /* assume error was set already */
760 free(buffer);
761 ws_dprintf(L_WS_LOG,"Could not parse get vars\n");
762 return FALSE;
763 }
764
765 free(buffer);
The relevant variable here is length, it is of type uint32_t. In line
715 content_length points to the user supplied Content-Length value in the HTTP
POST.
This value gets then converted to an integer using atoi in line 722.
Here integer conversion happens on negative values. A value of -1 will set
length to
UINT_MAX because length is of type uint32_t. Then the length value is used to
allocate space on the heap. Adding + 1 in the malloc call triggers an integer
overflow.
With a Content-Length: -1 the buffer size (UINT_MAX + 1) buffer size passed to
malloc
will be 0. This causes malloc to allocate the smallest possible chunk but it
does not fail.
In line 739 a timed read is done on the buffer. io_read_timeout() (from
src/io.c)
basically ends up calling io_read and reading length bytes into the buffer and
writing
the count of read bytes back to length. So there is a heap-based buffer
overflow here.
This corrupts the heap structure and leads to a server crash in line 765 when
freeing the
buffer which is now corrupted.
This is a remote DoS for _unauthenticated_ users and does possibly lead to
arbitrary code
execution
A very simple PoC attached.
CVE-2008-1771 was assigned to this, please mention this CVE id in the changelog
if you
fix this bug.
Kind regards
Nico
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
