#101 (1.6.15) memcpy() accesses beyond alloced memory webserver.c

open-duplicate
nobody
None
5
2012-03-19
2012-03-19
zephyrus
No

Using evaluation version of IBM Rational purify, I noticed a read of uninitialized memory and actually
beyond malloced area by memcpy() in CheckOtherHTTPHeaders() in
upnp/src/genlib/net/http/webserver.c

It seems that the particular memcpy is invoked only to a certain type of
UPnP request.

sizeof(RespInstr->AcceptLanguageHeader) is larger then LINE_SIZE, and

memcpy(RespInstr->AcceptLanguageHeader, TmpBuf,
sizeof(RespInstr->AcceptLanguageHeader) - 1);

could access memory area beyond allocated by malloc(LINE_SIZE) under
some circumstances. So we should allocate large enough buffer.

Noticed on a solaris 10 VM image. Funny, though, the other solaris 10
VM image on a different LAN didn't produce the bug.

This problem seems to be timing-related as well as depending on the
applications that issue UPnP SSDP packets.

I noticed "opera" string in the parsed packet when I saw the memory
read error detected by purify, but can't say for sure whether it had
something to do with opera. Funny, does browser have something to
with UPnP?

Now I confirmed it. I used google to find "opera unite" which has
something to with UPnP for file/media sharing, etc., and it seems to
send UPNP SSDP packet that can trigger the bug.

I confirmed it by downloading opera browser and opera unite software
on my Windows PC. It uses UPnP to open port at 8840 and when it sends
packet to open the port, the receiving UPnP daemon causes the memcpy
under "case HDR_ACCEPT_LANGUAGE:" below to run and causes
uninitialized memory read.

Patch attached.

Discussion

  • zephyrus
    zephyrus
    2012-03-19

    Allocate larger buffer

     
    Attachments
  • zephyrus
    zephyrus
    2012-03-19

    This is the packet capture that triggered the original error.
    (Note that Accpet-Language line is actually rather short.)

    POST /upnp/control/wanipconnection3 HTTP/1.1
    User-Agent: Opera/9.80 (Windows NT 6.1; U; ja) Presto/2.10.229 Version/11.61
    Host: 192.168.0.15:49152
    Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/webp, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
    Accept-Language: ja-JP,ja;q=0.9,en;q=0.8
    Accept-Encoding: gzip, deflate
    Connection: Keep-Alive
    Content-Length: 590
    CONTENT-TYPE: text/xml;charset="utf-8";
    TIMEOUT: infinite
    SOAPACTION: "urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping"

    <?xml version="1.0"?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:AddPortMapping xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1"><NewRemoteHost></NewRemoteHost><NewExternalPort>8840</NewExternalPort><NewProtocol>TCP</NewProtocol><NewInternalPort>8840</NewInternalPort><NewInternalClient>192.168.0.112</NewInternalClient><NewEnabled>1</NewEnabled><NewPortMappingDescription>Opera Unite</NewPortMappingDescription><NewLeaseDuration>0</NewLeaseDuration></u:AddPortMapping></s:Body></s:Envelope>

     
  • Hi,

    There was also an existing Tracker entry for this issue (3496933). So, this bug should be fixed in next pupnp release.

    Best Regards,

    Fabrice

     
    • status: open --> open-duplicate