[OpenTRV-dev] tinyHAN application protocol and mapping to MQTT

[Mike Stirling]

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

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.

Let's assume that a received packet is stored in a static buffer 
declared like this:

static char packet_buffer[32];
static char secret_keys[16];

It's highly likely that the linker will place the secret_keys buffer 
immediately after the packet buffer in memory.

Send a crafted packet that attempts to update the device's friendly name 
(which is used to derive the MQTT topic):

0x00 0xC1 0x2D "HERE_COMES_THE_SECRET_KEYS---"

[NOTE: I notice I missed the friendly name data ID from the table on the 
wiki, but it should be in the system profile]

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.

So no, not a stupid question at all.

Mike


On 10/12/14 15:34, Bruno Girin wrote:
> Mike,
>
> 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?
>
> 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?
>
> 0x00 0xC1 0xFF 0x01
>
> Please tell me if that question is stupid as I'm a bit fuzzy about how 
> buffer overflow attacks work.
>
> Bruno
>
>
> On 10 December 2014 at 13:59, Damon Hart-Davis <EMAIL ADDRESS HIDDEN 
> <mailto:EMAIL ADDRESS HIDDEN>> wrote:
>
>     Maybe we (you, I, others) can discuss in the IRC session tomorrow
>     night?
>
>     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^>
>
>     (I'm up to my eyes in motor drive code kinda sorta; production
>     engineering is moving along well.)
>
>     Rgds
>
>     Damon
>
>
>     > On 10 Dec 2014, at 13:47, Mike Stirling <EMAIL ADDRESS HIDDEN
>     <mailto:EMAIL ADDRESS HIDDEN>> wrote:
>     >
>     > Hi All,
>     >
>     > 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:
>     http://www.mike-stirling.com/redmine/projects/tinyhan/wiki/TinyHAN_application_protocol
>     >
>     > 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.
>     >
>     > 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.
>     >
>     > Mike
>     >
>     > _______________________________________________
>     > OpenTRV-dev mailing list
>     > EMAIL ADDRESS HIDDEN
>     <mailto:EMAIL ADDRESS HIDDEN>
>     > http://lists.opentrv.org.uk/listinfo/opentrv-dev
>
>
>
>
> _______________________________________________
> OpenTRV-dev mailing list
> EMAIL ADDRESS HIDDEN
> http://lists.opentrv.org.uk/listinfo/opentrv-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opentrv.org.uk/pipermail/opentrv-dev/attachments/20141210/5932be7f/attachment.html>