<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Yes it is something that needs to be considered.  As long as the
    deserialiser also checks that it isn't reading past the end of the
    packet then there is no problem.  Whether or not an overflow would
    constitute an attack vector depends on where the buffer is located
    (e.g. stack, heap or static).<br>
    <br>
    To aid your understanding of buffer overflow attacks it's easy
    enough to demonstrate one with your specific example, assuming the
    deserialiser didn't implement the above check.<br>
    <br>
    Let's assume that a received packet is stored in a static buffer
    declared like this:<br>
    <br>
    static char packet_buffer[32];<br>
    static char secret_keys[16];<br>
    <br>
    It's highly likely that the linker will place the secret_keys buffer
    immediately after the packet buffer in memory.<br>
    <br>
    Send a crafted packet that attempts to update the device's friendly
    name (which is used to derive the MQTT topic):<br>
    <br>
    0x00 0xC1 0x2D "HERE_COMES_THE_SECRET_KEYS---"<br>
    <br>
    [NOTE: I notice I missed the friendly name data ID from the table on
    the wiki, but it should be in the system profile]<br>
    <br>
    The packet is crafted to fully occupy the packet buffer (which is
    fine), but the length byte if unchecked will result in the
    deserialiser walking off the end and adding the 16 bytes of key data
    the decoded string (0x2D = 45 = 32+16-3).  In the proposed
    implementation the attacker then just needs to have subscribed to a
    wildcard topic /tinyhan/+/sys and to wait for the attack packet to
    result in a publish to a topic of the form
    /tinyhan/HERE_COMES_THE_SECRET_KEYS---<keys here>/sys.<br>
    <br>
    So no, not a stupid question at all.<br>
    <br>
    Mike<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 10/12/14 15:34, Bruno Girin wrote:<br>
    </div>
    <blockquote
cite="mid:CABWzvxsKJvfLYDT6knEectO5BnSRgH=qSYYjyXdxa=0WvWyr1w@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div>
            <div>Mike,<br>
              <br>
              I've got a stupid question on your wiki paper. It says:
              "If data type is variable then the data is prefixed by a
              single length byte. There is no end of field delimiter."
              Is there a risk of buffer overflow if the value in the
              length byte is higher than the actual length of the
              field/message?<br>
              <br>
            </div>
            So if I send the following 4 byte message, is there a risk
            that the code reading that message would read byte #3
            indicating a 255 byte value when in fact it's just one byte
            and therefore read the remaining 254 byte of random memory
            beyond the message?<br>
            <br>
          </div>
          0x00 0xC1 0xFF 0x01<br>
          <br>
        </div>
        <div>Please tell me if that question is stupid as I'm a bit
          fuzzy about how buffer overflow attacks work.<br>
          <br>
        </div>
        Bruno<br>
        <br>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On 10 December 2014 at 13:59, Damon
          Hart-Davis <span dir="ltr"><<a moz-do-not-send="true"
              href="mailto:dhd@exnet.com" target="_blank">dhd@exnet.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">Maybe we
            (you, I, others) can discuss in the IRC session tomorrow
            night?<br>
            <br>
            I do want to support one-way encryption for deployments
            using transport other than TinyHAN where a backchannel is
            hard/slow/expensive/periodic, and I’d prefer to avoid doing
            security stuff twice!  B^><br>
            <br>
            (I’m up to my eyes in motor drive code kinda sorta;
            production engineering is moving along well.)<br>
            <br>
            Rgds<br>
            <span class="HOEnZb"><font color="#888888"><br>
                Damon<br>
              </font></span>
            <div class="HOEnZb">
              <div class="h5"><br>
                <br>
                > On 10 Dec 2014, at 13:47, Mike Stirling <<a
                  moz-do-not-send="true"
                  href="mailto:mail@mikestirling.co.uk">mail@mikestirling.co.uk</a>>
                wrote:<br>
                ><br>
                > Hi All,<br>
                ><br>
                > I've been thinking about the proposed TinyHAN
                binary protocol and how to automatically map it to
                grown-up IoT protocols such as MQTT. I've committed my
                initial thoughts to virtual paper here and would be
                grateful for comments: <a moz-do-not-send="true"
href="http://www.mike-stirling.com/redmine/projects/tinyhan/wiki/TinyHAN_application_protocol"
                  target="_blank">http://www.mike-stirling.com/redmine/projects/tinyhan/wiki/TinyHAN_application_protocol</a><br>
                ><br>
                > The write access is something that has been
                bothering me, because MQTT does not actually seem like
                that good a fit for what is essentially a remote
                procedure call.  However, the approach I've proposed on
                the wiki feels reasonable.<br>
                ><br>
                > I've got most of what I've described up and running
                with a couple of sensors and I'm quite pleased with the
                result so far.<br>
                ><br>
                > Mike<br>
                ><br>
                > _______________________________________________<br>
                > OpenTRV-dev mailing list<br>
                > <a moz-do-not-send="true"
                  href="mailto:OpenTRV-dev@lists.opentrv.org.uk">OpenTRV-dev@lists.opentrv.org.uk</a><br>
                > <a moz-do-not-send="true"
                  href="http://lists.opentrv.org.uk/listinfo/opentrv-dev"
                  target="_blank">http://lists.opentrv.org.uk/listinfo/opentrv-dev</a><br>
                <br>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
OpenTRV-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenTRV-dev@lists.opentrv.org.uk">OpenTRV-dev@lists.opentrv.org.uk</a>
<a class="moz-txt-link-freetext" href="http://lists.opentrv.org.uk/listinfo/opentrv-dev">http://lists.opentrv.org.uk/listinfo/opentrv-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>