stack smashing detected

[don41382]

Hey Jakub and Libor,

thanks for the great project. Was this your thesis work? I really like the idea of tracking over clock skew. But I have problem, after a short while I get following exception:

5215 packets captured* stack smashing detected *: ./pcf terminated ======= Backtrace: ========= /lib/libc.so.6(__fortify_fail+0x37)[0x7fce90765d27] /lib/libc.so.6(__fortify_fail+0x0)[0x7fce90765cf0] ./pcf[0x40713d] [0x181e7d0] ======= Memory map: ======== 00400000-0040b000 r-xp 00000000 08:03 12337986 /home/felix/pcf/bin/pcf 0060a000-0060b000 r--p 0000a000 08:03 12337986 /home/felix/pcf/bin/pcf 0060b000-0060c000 rw-p 0000b000 08:03 12337986 /home/felix/pcf/bin/pcf 01809000-0182a000 rw-p 00000000 00:00 0 [heap] 7fce903d5000-7fce90664000 rw-s 00000000 00:06 8771453 socket:[8771453] 7fce90664000-7fce907e1000 r-xp 00000000 08:03 2064692 /lib/libc-2.11.1.so 7fce907e1000-7fce909e0000 ---p 0017d000 08:03 2064692 /lib/libc-2.11.1.so 7fce909e0000-7fce909e4000 r--p 0017c000 08:03 2064692 /lib/libc-2.11.1.so 7fce909e4000-7fce909e5000 rw-p 00180000 08:03 2064692 /lib/libc-2.11.1.so 7fce909e5000-7fce909ea000 rw-p 00000000 00:00 0 7fce909ea000-7fce909ff000 r-xp 00000000 08:03 2064653 /lib/libgcc_s.so.1 7fce909ff000-7fce90bfe000 ---p 00015000 08:03 2064653 /lib/libgcc_s.so.1 7fce90bfe000-7fce90bff000 r--p 00014000 08:03 2064653 /lib/libgcc_s.so.1 7fce90bff000-7fce90c00000 rw-p 00015000 08:03 2064653 /lib/libgcc_s.so.1 7fce90c00000-7fce90cea000 r-xp 00000000 08:03 13533656 /usr/lib/libstdc++.so.6.0.17 7fce90cea000-7fce90ee9000 ---p 000ea000 08:03 13533656 /usr/lib/libstdc++.so.6.0.17 7fce90ee9000-7fce90ef1000 r--p 000e9000 08:03 13533656 /usr/lib/libstdc++.so.6.0.17 7fce90ef1000-7fce90ef3000 rw-p 000f1000 08:03 13533656 /usr/lib/libstdc++.so.6.0.17 7fce90ef3000-7fce90f08000 rw-p 00000000 00:00 0 7fce90f08000-7fce90f0a000 r-xp 00000000 08:03 2064689 /lib/libdl-2.11.1.so 7fce90f0a000-7fce9110a000 ---p 00002000 08:03 2064689 /lib/libdl-2.11.1.so 7fce9110a000-7fce9110b000 r--p 00002000 08:03 2064689 /lib/libdl-2.11.1.so 7fce9110b000-7fce9110c000 rw-p 00003000 08:03 2064689 /lib/libdl-2.11.1.so 7fce9110c000-7fce9118e000 r-xp 00000000 08:03 2064670 /lib/libm-2.11.1.so 7fce9118e000-7fce9138d000 ---p 00082000 08:03 2064670 /lib/libm-2.11.1.so 7fce9138d000-7fce9138e000 r--p 00081000 08:03 2064670 /lib/libm-2.11.1.so 7fce9138e000-7fce9138f000 rw-p 00082000 08:03 2064670 /lib/libm-2.11.1.so 7fce9138f000-7fce914e9000 r-xp 00000000 08:03 13541517 /usr/local/lib/libxml2.so.2.9.0 7fce914e9000-7fce916e9000 ---p 0015a000 08:03 13541517 /usr/local/lib/libxml2.so.2.9.0 7fce916e9000-7fce916f1000 r--p 0015a000 08:03 13541517 /usr/local/lib/libxml2.so.2.9.0 7fce916f1000-7fce916f3000 rw-p 00162000 08:03 13541517 /usr/local/lib/libxml2.so.2.9.0 7fce916f3000-7fce916f4000 rw-p 00000000 00:00 0 7fce916f4000-7fce9172d000 r-xp 00000000 08:03 13541526 /usr/local/lib/libpcap.so.1.3.0 7fce9172d000-7fce9192c000 ---p 00039000 08:03 13541526 /usr/local/lib/libpcap.so.1.3.0 7fce9192c000-7fce9192e000 r--p 00038000 08:03 13541526 /usr/local/lib/libpcap.so.1.3.0 7fce9192e000-7fce9192f000 rw-p 0003a000 08:03 13541526 /usr/local/lib/libpcap.so.1.3.0 7fce9192f000-7fce91930000 rw-p 00000000 00:00 0 7fce91930000-7fce91950000 r-xp 00000000 08:03 2064680 /lib/ld-2.11.1.so 7fce91b40000-7fce91b47000 rw-p 00000000 00:00 0 7fce91b4c000-7fce91b4f000 rw-p 00000000 00:00 0 7fce91b4f000-7fce91b50000 r--p 0001f000 08:03 2064680 /lib/ld-2.11.1.so 7fce91b50000-7fce91b51000 rw-p 00020000 08:03 2064680 /lib/ld-2.11.1.so 7fce91b51000-7fce91b52000 rw-p 00000000 00:00 0 7fffdec26000-7fffdec3b000 rw-p 00000000 00:00 0 [stack] 7fffded1b000-7fffded1c000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]

Do you have any Idea what is this about?

Greetings Felix

[polcak]

Hello Felix,

thank you for your input. The problem you have encountered is caused by overly optimistic reduction of packet data stored by the program. You can disable the reduction by recompiling the program: "make clean; make donotreduce".

The starting point of this repository is the result of Jakub's diploma thesis, which was inspired by work of Kohno et al. However, the program is still in development so it is planned that this issue will be solved.

I have added new section to README about the origins of the project and a note about this issue to the INSTALL file.

Thanks again for your interest about the program,

Cheers, Libor

[don41382]

Hallo Libor,

thanks for your fast response and the workaround. Is the thesis for public? I really like to read it and go deeper in to this field. Is it true, that Windows System can't be tracked, because they don't transmit the TCP Timestamp?

Cheers, Felix

[polcak]

Hello Felix,

the thesis is public, but it is in Czech. See http://www.fit.vutbr.cz/study/DP/DP.php?id=14040&file=t. I tried to google-translate it and the text was readable but the English was far from perfect.

If you want to go deeper, you can start with: Kohno, T.; Broido, A.; Claffy, K.: Remote physical device fingerprinting. IEEE Transactions on Dependable and Secure Computing, volume 2, no. 2, May 2005: pp. 93–108, ISSN 1545-5971.

This paper was also cited frequently and you can find many papers that refers to the topic.

Windows machines can be tracked but client stations does not send TCP timestamps by default. See http://technet.microsoft.com/en-us/library/cc938205.aspx for details. My experiments confirm that windows servers respect requests for TCP timestamps. So it is possible to track Windows if they act as a server for at least one Linux/BSD/MAC OS etc. computer client and/or if someone manually enables TCP timestamps in registry. Kohno et al. describes another possibility of forging Windows SYN packets.

Cheers,

Libor

[don41382]

Hey Libor,

thanks for your answer. You are right, the google translation works almost "perfekt" ;)

I already checked the Kohno document and tried to reproduce the described way of SYN/ACK method. But it doesn't work passive. Only if you initiate the connection to the client, it will work. And yes, I know that you can enable TCP Timestamp sending in the registry, but that would be to difficult to do that on every client. I really would love the passive way. But no luck so far. Maybe you have another idea to get this to work.

And yes, the "donotreduce" option helped. It's running perfectly. Thanks for that.

Cheers, Felix

[polcak]

This should be fixed by e7788437d7be6ad9acf7362ad6fc901d3d259710