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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ