full-disclosure - Strange interactions between tunnelling and SMB under the proprietary Microsoft Windows environment

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu Mar 30 11:08:08 2006
From: 3APA3A at SECURITY.NNOV.RU (3APA3A)
Subject: Strange interactions between tunnelling and SMB
	under the proprietary Microsoft Windows environment

Dear Marc SCHAEFER,

--Thursday, March 30, 2006, 9:52:10 AM, you wrote to full-disclosure@...ts.grok.org.uk:

MS>    Testing pings and telnet on the remote tunnel address (e.g.
MS>    192.168.1.2) and capturing data with the libre software Ethereal on the
MS>    real Ethernet interface did show me that the flow of data was
MS>    correctly routed through the tunnel.

MS>    However, accessing \\192.168.1.2\c$ did go through the Ethernet
MS>    interface, and *not the tunnel*, and strangely half-using the private
MS>    addresses!

Make sure "Client for Microsoft Network" is bound to tunnel adapter.

Microsoft's  network filesystem works with NIC in "shorten" way: data is
copied  from  the disk to the file cache (physical memory), and the same
physical memory address is given to NIC to transfer data. And vice versa
for  network  client.  It  eliminates  copying  file data from memory to
memory  using  CPU.  That's why there can be differences in the CIFS/SMB
behavior comparing with the rest of TCP/IP stack. Also, this can lead to
incompatibilities with "emulated" NICs.

-- 
~/ZARAZA
http://www.security.nnov.ru/