LMNR issue in TCP 2.0.7

Kernel
1

abrous3d wrote on Tuesday, December 11, 2018:

We have ported a working app, originally based on FreeRTOS 9.0 and TCP 2.0.1 to the latest TCP 2.0.7.
For simplicity reasons, we decided to upgrade only the TCP stack to the latest version and not the kernel.
The stack seem to work fine so far with the exception of LMNR. The device advertises correctly the device name when scanned externally but it doesn’t seem to respond to any LMNR packets.
The previous version using TCP 2.0.1 used to respond perfectly to both browser requests (http://devicename/) and ping (ping devicename).
Following the suggestion in a similar question in another thread I increased the ipconfigDNS_CACHE_NAME_LENGTH to 128 although the used name is just 7 characters long with no effect as expected.

Tracing the code I can see the network descriptors arriving in ulDNSHandlePacket() when an LMNR request is issued, but :

pxNetworkBuffer->xDataLength in ulDNSHandlePacket is usually 25 when an LMNR packet arrives (but the same applies for the working version 2.0.1).

The calculation of xPlayloadBufferLength = pxNetworkBuffer->xDataLength - sizeof( UDPPacket_t ) gives a result in the range of 0xFFFFFFEF (FreeRTOS_DNS.c line ~816 ).

Subsequently the condition :

if( pxNetworkBuffer->xDataLength > sizeof( UDPPacket_t ) )
{
prvParseDNSReply( pucUDPPayloadBuffer,
xPlayloadBufferLength,
( uint32_t )pxDNSMessageHeader->usIdentifier );
}

Is never satisfied since UDPPacket_t is 42 Bytes long so prvParseDNSReply() is never executed.

The intension of the above calculations are not so clear to me so far but probably I am missing something.
Can you see any possible reasons for that ? Are there any known issues regarding LMNR in 2.0.7 or I am just missing something ?

Thanks

Angelo B.

2

abrous3d wrote on Tuesday, December 11, 2018:

Looking at the code I noticed that

xPlayloadBufferLength = pxNetworkBuffer->xDataLength - sizeof( UDPPacket_t );
in FreeRTOS_DNS.c line 816 is subtracting the size of the UDPPacket which is already subtracted earlier in prvProcessIPPacket() in the line :
if ( pxNetworkBuffer->xDataLength >= sizeof( UDPPacket_t ) )
{
pxNetworkBuffer->xDataLength -= sizeof( UDPPacket_t );
… }

So I patched the line to :

xPlayloadBufferLength = pxNetworkBuffer->xDataLength; ////// - sizeof( UDPPacket_t );

Also the comparison :
if( pxNetworkBuffer->xDataLength > sizeof( UDPPacket_t ) )
can’t be true anymore so I commented out this line.
So the function simplifies to :

uint32_t ulDNSHandlePacket( NetworkBufferDescriptor_t *pxNetworkBuffer )
{
uint8_t *pucUDPPayloadBuffer;
size_t xPlayloadBufferLength;
DNSMessage_t *pxDNSMessageHeader;

xPlayloadBufferLength = pxNetworkBuffer->xDataLength;
if ( xPlayloadBufferLength < sizeof( DNSMessage_t ) )
{
return pdFAIL;
}
pucUDPPayloadBuffer = pxNetworkBuffer->pucEthernetBuffer + sizeof( UDPPacket_t );
pxDNSMessageHeader = ( DNSMessage_t * ) pucUDPPayloadBuffer;
prvParseDNSReply( pucUDPPayloadBuffer, xPlayloadBufferLength,
( uint32_t )pxDNSMessageHeader->usIdentifier );
/* The packet was not consumed. */
return pdFAIL;
}

Now it works fine. Can you see any possible vulnerabilities into this simplification ? Is there any other way to make it work ?

Thanks

Angelo B.

3

heinbali01 wrote on Tuesday, December 11, 2018:

Hi Angelo, thanks for taking the time to report this. Your diagnosis is correct.

I just reposted a pull-request to revert the changes done in commit v1.3.2 on august 23, 2018 :

https://github.com/aws/amazon-freertos/pull/146

You can download the adapted sources from here