Project

General

Profile

Bug #1274

[openssh-knock] is ignoring TCPStealthSecret and always accept the connection even if secret are different

belette - about 7 years ago - . Updated about 7 years ago.

Status:
fixed
Priority:
bug
Assignee:
-
% Done:

100%


Description

I have tested different TCPStealthSecret on server and client side but it ignores it and always accept to connect.
To confirm I don't have an issue on my kernel (I am using linux-libre-grsec-knock) I have use the simple program Gnunet proposed on their website (https://gnunet.org/sites/default/files/examples.tar.gz) and it is working as expected (different secrets makes the connection fails, same secret validate the connection).

History

#1

Updated by belette about 7 years ago

Doing further analysis, the patch doesn't seems to define TCP_STEALTH_SECRET on the right place.

The sample program from Gnunet gives 0x1e for setsockopt:
setsockopt(3, SOL_TCP, 0x1e /* TCP_??? */,"thisismysecret\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 0
and the knock process is working correctly.

The same setsockopt from the openssh-knock is doing:
setsockopt(3, SOL_TCP, TCP_NOTSENT_LOWAT,"thisismysecret\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 0
and the knock process is not working (ssh always accept connection even if secret are not the same between client and server)

#2

Updated by Anonymous about 7 years ago

  • Assignee set to Anonymous
#3

Updated by korobkov about 7 years ago

I confirm this behavior. It was so for a long time already.

#4

Updated by Anonymous about 7 years ago

  • % Done changed from 0 to 100
  • Status changed from open to fixed
#5

Updated by belette about 7 years ago

Yep I confirmed it is fixed
many thanks @Emulatorman for your quick fix :)

Also available in: Atom PDF