[aprssig] Escaping \r\n in packets for APRS-IS

[spam8mybrain]

Uh, oh. Not cool. I just checked my APRS-IS and SSL-APRS-IS port drivers in YAAC, and I send the packet as-is byte-for-byte, assuming it is only one line with no embedded control characters.
    
Hmmm... in one of my displays, I replace all the ASCII control characters (byte values 0x00 through 0x1F) with their corresponding display glyphs in Unicode (\u2400 through \u241F), so they can be interpreted properly by the user. But that doesn't fix I-gating.Would that be a good solution? The problem is, Tx I-gate retransmission would show a different packet, and not all software supports UTF-8 characters in the free-text comment of APRS packets. I know the Kenwood radios only do 7-bit US-ASCII; at least, only characters in the byte range 0x20 through 0x7E can be entered for beacon comments or text messages, not the entire 65000 characters of Unicode.Any opinions? Andrew, KA2DDOauthor of YAAC

-------- Original message --------
From: "Iain R. Learmonth" <irl at hambsd.org> 
Date: 5/8/20  09:30  (GMT-05:00) 
To: aprssig at lists.tapr.org 
Subject: Re: [aprssig] Escaping \r\n in packets for APRS-IS 

Hi,On 08/05/2020 13:36, Lynn W Deffenbaugh (Mr) wrote:> Are you sure it is your radio adding the <CR> to the packet and not the> IGate that is receiving it? Or where do you actually see this character> since, as you say, it is dropped by the TNC2 format required by the> APRS-IS interface.It's definitely the Yaesu radio.I've checked with both Dire Wolf and a PK-88 and they are both decodinga 0x0d at the end of the packets, for example:MM0ROR-7>UWPYXU,WIDE1-1,WIDE2-1:`xaRl <0x1c>[/`_ <0x0d>It appears on the air, and being at the end of the packet anyway hasn'tcaused issues.> And further, what is the use case for needing a trailing <CR> on an APRS> packet?I don't need it. I suspect this to be a bug in the firmware, but that'snever going to get fixed. What I'd like to figure out is the best way tohandle this, which is likely to be the way that is most consistent withother IGate software so as to avoid creating modifications to the packetthat other software hasn't made, leading to duplicates and loops.Some black box testing with Dire Wolf and Xastir seems to indicate thatthe common way to handle this is truncating the packets. If the packetsare not truncated then this can lead to a security issue, as it'spossible to send arbitrary additional packets that may bypass checks, oreven send filter commands that may cause an IGate to jam a channel.If you can send a \r or \n in the middle of the packet, the data thatfollows that will be interpreted by the IGate server as a new line, anda new TNC2 formatted packet.An example packet has a position report, where the comment is:"Test packet\r#filter m/1000"In my implementation where I have tried as much as possible to treatpackets as binary data and not modify them, this gets passed directly tothe server, and the server happily starts sending me all positionreports from 1000 miles around.In my opinion this is a huge hole in the spec. Without a method ofescaping these characters, this could get missed by implementers and weend up in a situation that could lead to abuse if systems not handlingthis case are widely deployed.I wonder if Xastir and Dire Wolf have deliberately truncated packets orif they just got lucky, and I wonder what other IGate implementationsare out there that might not have implemented mitigations for this attack.Thanks,Iain MM0ROR.-- https://hambsd.org/_______________________________________________aprssig mailing listaprssig at lists.tapr.orghttp://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20200508/fac14bd7/attachment.html>