HamBSD Development Log 2020-05-08

· hambsd journal aprs openbsd ax25

I worked on HamBSD today, still looking at improvements to aprsisd(8). My focus today was on documentation, tests and tidying up. It’s good to keep technical debt in check and while no new big exciting features got made today on anything, lots of hard work was done.

I started the day on documentation, adding details on the new -b flag for aprsisd and details on which packets will be sent to APRS-IS. I also added a reference to the APRS-IS specifications to both the aprsisd(8) and the aprsis-filter(7) man pages.

I’ve added a few more unit tests to test the generation of the TNC2 format packets from AX.25 packets to upload to APRS-IS. One of these covers an interesting case, where a carriage return or line feed is present in the information field of an APRS packet.

This could lead to an “injection attack” if the payload of the packet is copied verbatim to the server, each of these characters are interpreted as packet delimiters and it would be possible to send packets bypassing checks or to send in-band commands (such as filter) via RF.

I tested both Dire Wolf and Xastir, both are immune to this attack. I posted to the tapr-aprssig mailing list. It turns out that YAAC may be affected by this issue.

John Langner WB2OSZ commented on the thread to say that the approach that Dire Wolf takes is to truncate the packet at the first carriage return or line feed character, so I’ve implemented this in aprsisd before any checks are carried out on the information part.

I’ve learned from looking at YAAC that it also implements TLS for APRS-IS and so that brings the number of other clients I know about to two: APRSdroid and YAAC. I also managed to find in its source code the root CA certificate for the APRS tier 2 servers and have included this in the HamPKI certificate bundle.

Bad news is that it uses SHA-1 as a signature scheme and while this meant I can now enable certificate validation, neither server has ssl.aprs2.net in its certificate so the name can’t be validated and one of the servers still has an expired certificate. Progress is still progress.

Another test case looks at third-party traffic with TCPIP in the third-party header, and this will now be correctly dropped.

I’m not going to list any next steps in this post, because I think now I need to do a review of what has been done and where effort needs to go next. The next steps are going to be working out what the next steps are.

If you would like to contact me with comments, please send me an email.
If you would like to support my free software work, you can support me on Patreon or donate via PayPal.

This post was syndicated on: