<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>