From: Paula Dowie (terhi.victor@logonet.com)
Date: Sun Nov 11 2001 - 02:09:45 EET
Ok, this is the FOURTH time I've tried to get the list to accept this
message....
----- Original Message -----
From: "Paula Dowie" <terhi.victor@logonet.com>
To: <evgngfa.tymgb@optimad.com>
Sent: Saturday, November 10, 2001 4:28 PM
Subject: Netrom module vulnerability
Hello All,
I have been informed that my (DOS) AX25/IP router is "crashing" netrom
sessions on adjacent Linux machines, and I therefore believe there is a
vulnerability within the netrom receive routines in Linux.
I can hear you muttering "How dare you, a mere DOS programmer, challenge the
perfection of Linux!"..
Well I must admit, I am merely a DOS programmer / user, I don't have a Linux
machine, and until today I'd never seen the linux Netrom code. So maybe I
don't have the right to stick my nose into your system, but if you want to
avoid future problems I suggest someone should apply a fix... (By the way, I
am not anti-linux, from what I've seen I think it's wonderful)
Ok, so here's the problem:
Netrom frametype 0x00 is used as a "protocol extension", allowing IP
datagrams (and other things) to be transported in Netrom L3 frames.
When the frametype is 0x00, the "circuit index" and "circuit id" (first 2
bytes of the transport header) take on a different meaning, something like
"protocol family" and "protocol id". IP over netrom uses 0x0C for both
bytes, TheNet uses 0x00 for both bytes when making L3RTT measurements, and
Xnet uses family 0x00, protocol id 0x01 for Netrom Record Route. I believe
there are authors using other values too. Unfortunately there is no
co-ordinating authority for these numbers, so authors just pick an unused
one.
My software implements all the above, and in addition it uses protocol
family 0x0F along with various protocol ids for special traffic between
Xrouter systems. (I haven't released the protocol specs yet, because I don't
want them cast in stone before I've finished my development).
I believe Linux does not follow the robustness principle (can't remember the
exact wording, but it basically means "expect the unexpected") when dealing
with netrom frames. In af_netrom.c, the function nr_rx_frame() only checks
for "frametype" NR_PROTOEXT if CONFIG_INET is #defined, and it only checks
for 0x0C in the first two bytes. If they're not both 0x0c, it falls
through. Here's the code...
841 #ifdef CONFIG_INET
842 /*
843 * Check for an incoming IP over NET/ROM frame.
844 */
845 if (frametype == NR_PROTOEXT && circuit_index == NR_PROTO_IP &&
circuit_id == NR_PROTO_IP) {
846 skb_pull(skb, NR_NETWORK_LEN + NR_TRANSPORT_LEN);
847 skb->h.raw = skb->data;
848
849 return nr_rx_ip(skb, dev);
850 }
851 #endif
852
If it falls through the above check (which it will do for L3RTT, NRR and
Xrouter frames) it will try and find a socket which matches "circuit id" and
"circuit index" - but these are not valid for frametype NR_PROTOEXT. If it
happens to find a socket, all sorts of problems will ensue... It should
never have been allowed to get that far.
I believe a more robust method would be to ALWAYS check the frametype for
NR_PROTOEXT (0x00), and to return if it doesn't understand the protocol
family/protocol ID. For example:
/*
* Check for protocol extensions
*/
if (frametype == NR_PROTOEXT)
{
#ifdef CONFIG_INET
/* Check for IP over Netrom */
if (circuit_index == NR_PROTO_IP && circuit_id == NR_PROTO_IP)
{
skb_pull(skb, NR_NETWORK_LEN + NR_TRANSPORT_LEN);
skb->h.raw = skb->data;
return nr_rx_ip(skb, dev);
}
#endif
/* Ignore anything not understood */
return(0);
}
As I said, this is my first look at Linux code, so I may have misunderstood
something. If so, could someone more knowledgeable please take this up and
fix the problem?
73, Paula
-
To unsubscribe from this list: send the line "unsubscribe linux-hams" in
the body of a message to terhi.victor@logonet.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
This archive was generated by hypermail 2b30 : Sun Nov 11 2001 - 01:11:42 EET