Multi-line packets are forwarded by the igate, allowing command injection attacks

[hessu]

https://github.com/nakhonthai/ESP32IGate/blob/b1386e0716aec2434063c5d0689d838af088dd84/src/igate.cpp#L83

APRS packets are only supposed to contain a single line of data. If a packet containing multiple lines of data (with some CR LF sequences in there), this igate now forwards all of those lines to the APRS-IS server. It generates the packet header for the first line it sends, but the additional lines will be forwarded unmodified, without header of any sort, and may contain additional headers, or anything else.

The second line in the received packet could just as well be an APRS-IS server command, such as #filter p/N which would suddenly cause the igate to receive a lot of packets from the APRS-IS server.

From https://github.com/hessu/aprsc/blob/main/doc/IGATE-HINTS.md:

Please do not modify packet data. Do not trim spaces from the end, do not remove non-ASCII bytes such as 0x1C or 0x00. Just send everything on the first line, up to the newline (either first CR or LF character seen in packet).

Stop sending at the first CR or LF character in the packet, and send a CR LF sequence at the end of that line.

Thanks!

[nakhonthai]

Thanks you.

[hessu]

Hello,

This ticket has been closed without fixing the issue? The bug needs to be fixed to make the igate work correctly. Thanks!

[erstec]

@nakhonthai
It should be same fix as here https://github.com/erstec/APRS-ESP/pull/49/files

[nakhonthai]

I understand the problem as Hessu said, regarding CR, LF and Binary in frames.
But I don't think it's due to my project.Please provide information about problems in aprsc log caused by this project.

Because the TNC and igate code are combined together, the TNC section has CRC checks in the AX.25 protocol and the APRS info data is text only, with no assci or binary.
Therefore, no CR,LF or Binary occurs in the frame package received from RF. It still follows the rules of AX.25 and APRS protocol.

The problems mentioned I found this a lot in other igate projects.
In practice, no erroneous packets should be sent onto the Internet network.
There is a serial communication uart error between TNC and IGATE.
The TNC is made using an Arduino board (ATmega328), because the arduiono uses a crystal frequency of 8Mhz/16Mhz,This causes serial communication uart errors, where 9600bps has an error of 0.2% or 115200bps has an error of 8.5% ,See other errors You can find it in the data sheet in the table 19-12 of ATmega328.

However, I will include this bug in my code. To prevent mistakes and to provide a basis for others to develop further.

[nakhonthai]

Hello,

This ticket has been closed without fixing the issue? The bug needs to be fixed to make the igate work correctly. Thanks!

I will upload again affter open shared ESP32APRS _T-TWR Plus project.

[hessu]

@nakhonthai Please reopen the bug until the bug is fixed, so that it's easier to track it? Also, so that it is clearer to everyone that the bug is still present.

[hessu]

But I don't think it's due to my project.Please provide information about problems in aprsc log caused by this project.

Because the TNC and igate code are combined together, the TNC section has CRC checks in the AX.25 protocol and the APRS info data is text only, with no assci or binary. Therefore, no CR,LF or Binary occurs in the frame package received from RF. It still follows the rules of AX.25 and APRS protocol.

The underlying problem is that the AX.25 protocol allows any station to transmit a packet which contains many lines of data, with CR / LF sequences in them.

On the other hand, the APRS protocol (not a great protocol as such) consists of one-line packets. Likewise the APRS-IS network deals with one-line packets.

If an igate forwards a packet of multiple lines from RF to APRS-IS, any station on RF may inject commands to the APRS-IS server, effectively making a DOS attack, or other confusion. This may be done intentionally or accidentally, or due to packet corruption (which is quite common, actually).

For example, a station may send the following two-line packet on RF:

N0CALL-9>APRS:>valid APRS packet here<CR><LF>
#filter p/A/N/K/W

Your igate will forward the second line, unmodified, to the APRS-IS server. The server will treat it as an individual packet or command, and will not know it is somehow attached or related to the first line, because the CR LF sequence is the delimiter between two packets, according to the APRS-IS. The APRS-IS server will start sending all packets sourced by US callsigns to your igate, which might be choked or confused by the large amount of traffic.

The fix is to not send anything beyond the first CR or LF, and to always terminate with a CR LF when sending to APRS-IS.

https://github.com/hessu/aprsc/blob/main/doc/IGATE-HINTS.md#packets-modified-by-igates