<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body>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.
<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Any opinions? </div><div><br></div><div>Andrew, KA2DDO</div><div>author of YAAC</div><br><br>-------- Original message --------<br>From: "Iain R. Learmonth" <irl@hambsd.org> <br>Date: 5/8/20 09:30 (GMT-05:00) <br>To: aprssig@lists.tapr.org <br>Subject: Re: [aprssig] Escaping \r\n in packets for APRS-IS <br><br>Hi,<br><br>On 08/05/2020 13:36, Lynn W Deffenbaugh (Mr) wrote:<br>> Are you sure it is your radio adding the <CR> to the packet and not the<br>> IGate that is receiving it? Or where do you actually see this character<br>> since, as you say, it is dropped by the TNC2 format required by the<br>> APRS-IS interface.<br><br>It's definitely the Yaesu radio.<br><br>I've checked with both Dire Wolf and a PK-88 and they are both decoding<br>a 0x0d at the end of the packets, for example:<br><br>MM0ROR-7>UWPYXU,WIDE1-1,WIDE2-1:`xaRl <0x1c>[/`_ <0x0d><br><br>It appears on the air, and being at the end of the packet anyway hasn't<br>caused issues.<br><br>> And further, what is the use case for needing a trailing <CR> on an APRS<br>> packet?<br><br>I don't need it. I suspect this to be a bug in the firmware, but that's<br>never going to get fixed. What I'd like to figure out is the best way to<br>handle this, which is likely to be the way that is most consistent with<br>other IGate software so as to avoid creating modifications to the packet<br>that other software hasn't made, leading to duplicates and loops.<br><br>Some black box testing with Dire Wolf and Xastir seems to indicate that<br>the common way to handle this is truncating the packets. If the packets<br>are not truncated then this can lead to a security issue, as it's<br>possible to send arbitrary additional packets that may bypass checks, or<br>even send filter commands that may cause an IGate to jam a channel.<br><br>If you can send a \r or \n in the middle of the packet, the data that<br>follows that will be interpreted by the IGate server as a new line, and<br>a new TNC2 formatted packet.<br><br>An example packet has a position report, where the comment is:<br><br>"Test packet\r#filter m/1000"<br><br>In my implementation where I have tried as much as possible to treat<br>packets as binary data and not modify them, this gets passed directly to<br>the server, and the server happily starts sending me all position<br>reports from 1000 miles around.<br><br>In my opinion this is a huge hole in the spec. Without a method of<br>escaping these characters, this could get missed by implementers and we<br>end up in a situation that could lead to abuse if systems not handling<br>this case are widely deployed.<br><br>I wonder if Xastir and Dire Wolf have deliberately truncated packets or<br>if they just got lucky, and I wonder what other IGate implementations<br>are out there that might not have implemented mitigations for this attack.<br><br>Thanks,<br>Iain MM0ROR.<br><br>-- <br>https://hambsd.org/<br><br>_______________________________________________<br>aprssig mailing list<br>aprssig@lists.tapr.org<br>http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org<br></body></html>