[aprssig] Weird characters from station VKA

[Scott Miller]

> I have seen concatenation occurring with APRS+SA IGates (not sure of the TNC configuration) and I have seen certain versions of aprsD also have issues with null and other non-printable characters due to the use of C string functions instead of memory functions.  I looked for VA7YLW-15 originated packets and only found some gated to APRS-IS by another IGate.  Unfortunately, the destination "call" is APRS so there is no information on the software used.

The particular instance I saw was two widely separated stations, which 
ruled out an IGate problem in this case - though that's always the first 
thing I look at, with people running converse-mode TNCs.  I do need to 
check my monitoring program and make sure it's handling nulls properly.. 
it's certainly possible that it's got a bug there.  Looks like it's 
using the strchr() function to find a carriage return in the incoming 
TCP stream and doesn't process a line until it sees one.  I wrote this 
thing years ago so I'd have to dig in to it a bit more to remember how 
it works.

> I saw the same issue with the null character being appended to each AGWTracker transmission.  Something for George to look into.

It's an easy mistake to make.  This whole scheme of packaging AX.25 
frames that could contain unvalidated 8-bit data into a stream intended 
for 7-bit data bugs me a bit, especially from a security perspective.

At the very least, you've got the potential for spoofing - a packet 
received on-air could have a CR/LF in the middle, followed by a valid 
TNC2 header and another fake packet.  Even with a KISS TNC, you can't 
tell the difference once it gets to the APRS IS.  Will the hubs pass 
comment lines like this?  Can clients be confused by 'comments' that 
appear to be coming from the IS server?

If some 16-year-old with too much time on their hands starts testing for 
things like buffer overflows and format string vulnerabilities, we could 
be in real trouble.  With the huge variety of stuff listening to the 
APRS IS, chances are SOMETHING is going to be vulnerable.  Even for 
programmers with some experience dealing with this sort of threat, it's 
hard to know how to deal with the APRS IS because the specifications 
(thanks Pete for posting what's out there on aprs-is.net, BTW) don't 
seem to cover things like nulls and embedded CR/LFs.  That might be a 
good place to start.  I don't expect anyone to restructure the whole 
APRS IS, but defining how some exceptional conditions should be handled 
would be nice.

Scott
N1VG