[aprssig] Weird characters from station VKA
Scott Miller
scott at opentrac.org
Mon Dec 1 13:16:07 EST 2008
> 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
More information about the aprssig
mailing list