| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAGiC5RN=78F4=nOby8n-voCADQWb_H154kNNGOBmP_wTu-c-Vw@mail.gmail.com> Date: Wed, 29 May 2013 10:19:24 +0300 From: Андрей Солозобов <andrei.solozobov@...il.com> To: linux-kernel@...r.kernel.org Subject: Loose source routing option in IP headers is processed incorrectly Hi! I'm a student and while doing my course work experiments I found out this problem: I found that loose source routing option in IP headers is processed incorrectly (I think that correct way is explained in RFC791 http://tools.ietf.org/html/rfc791#page-18). It don't replace the destination address with new one from rote and don't increment the option pointer. I made an experiment: Three hosts 10.0.1.1, 10.0.1.2, 10.0.1.3 - all are running under Ubuntu 12.10 quantal Linux 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:32:08 UTC 2012 i686 10.0.1.1 and 10.0.1.2 connected by Ethernet cable 10.0.1.2 and 10.0.1.3 connected by WiFi ad hoc connection 10.0.1.2 has network bridge between wireless network connection and local area connection 10.0.1.2 has Routing and Remote Access service running and in windows register folder /etc/sysctl.conf on 10.0.1.2 and 10.0.1.3 got entries: net.ipv4.ip_forward = 1 net.ipv4.conf.all.accept_source_route = 1 net.ipv4.conf.lo.accept_source_route = 1 net.ipv4.conf.eth0.accept_source_route = 1 net.ipv4.conf.default.accept_source_route = 1 net.ipv4.conf.all.log_martians = 1 net.ipv4.conf.lo.log_martians = 1 net.ipv4.conf.eth0.log_martians = 1 Example of ping ICMP request processing (Ethernet frame captures made with Wireshark): sent by 10.0.1.1 0000 00 04 00 01 00 06 00 22 4d 4f a0 9d 00 00 08 00 ......." MO...... 0010 47 00 00 5c 00 00 40 00 40 01 0e 16 0a 00 01 01 G..\..@. @....... 0020 0a 00 01 02 01 83 07 04 0a 00 02 02 08 00 5d 08 ........ ......]. 0030 3c 83 00 01 18 d8 a0 51 b9 46 01 00 08 09 0a 0b <......Q .F...... 0040 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b ........ ........ 0050 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b .... !"# $%&'()*+ 0060 2c 2d 2e 2f 30 31 32 33 34 35 36 37 ,-./0123 4567 received by 10.0.1.2 0000 00 00 00 01 00 06 00 22 4d 4f a0 9d 00 00 08 00 ......." MO...... 0010 47 00 00 5c 00 00 40 00 40 01 0e 16 0a 00 01 01 G..\..@. @....... 0020 0a 00 01 02 01 83 07 04 0a 00 02 02 08 00 5d 08 ........ ......]. 0030 3c 83 00 01 18 d8 a0 51 b9 46 01 00 08 09 0a 0b <......Q .F...... 0040 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b ........ ........ 0050 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b .... !"# $%&'()*+ 0060 2c 2d 2e 2f 30 31 32 33 34 35 36 37 ,-./0123 4567 sent by 10.0.2.1 (destination IP and next IP from option not swapped, option pointer not moved (must be 8), but packet sent to 10.0.2.2) 0000 00 04 00 01 00 06 14 d6 4d 0e ec d8 00 00 08 00 ........ M....... 0010 47 00 00 5c 00 00 40 00 3f 01 0f 16 0a 00 01 01 G..\..@. ?....... 0020 0a 00 01 02 01 83 07 04 0a 00 02 02 08 00 5d 08 ........ ......]. 0030 3c 83 00 01 18 d8 a0 51 b9 46 01 00 08 09 0a 0b <......Q .F...... 0040 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b ........ ........ 0050 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b .... !"# $%&'()*+ 0060 2c 2d 2e 2f 30 31 32 33 34 35 36 37 ,-./0123 4567 received by 10.0.2.2 and not processed 0000 00 00 00 01 00 06 14 d6 4d 0e ec d8 00 00 08 00 ........ M....... 0010 47 00 00 5c 00 00 40 00 3f 01 0f 16 0a 00 01 01 G..\..@. ?....... 0020 0a 00 01 02 01 83 07 04 0a 00 02 02 08 00 5d 08 ........ ......]. 0030 3c 83 00 01 18 d8 a0 51 b9 46 01 00 08 09 0a 0b <......Q .F...... 0040 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b ........ ........ 0050 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b .... !"# $%&'()*+ 0060 2c 2d 2e 2f 30 31 32 33 34 35 36 37 ,-./0123 4567 10.0.2.2 writes to /var/log/syslog record: "May 25 19:24:57 student4 kernel: [ 1464.555708] ip_forward(): Argh! Destination lost!" (I found that it's /net/ipv4/ip_options.c module http://lxr.free-electrons.com/source/net/ipv4/ip_options.c?v=3.5#L550 record). It's right that there is no destination Address in the LSRR list, because it must be replaced with emitting interface address. Is it a bug or a feature? Andrew Solozobov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists