Security: Reduce impact of bogus key setup packet DoS
If a MSG1 (key setup initiation packet) is received containing
expected local and remote site names, the receiving secnet will start
a key setup attempt with details from that packet.
MSG1 packets are (almost necessarily) unauthenticated, so anyone on
the Internet can cause this to happen. secnet is only willing to have
one key exchange attempt ongoing at once, and will ignore subsequent
incoming MSG1s until it has dealt with the first key exchange attempt.
So this means that an attacker who can send packets to any secnet
instance can DoS secnet at session setup (or key renewal) time. All
the attacker needs to know is the secnet site names, and the IP
address and port number of one of the secnets. The attacker does not
need to spoof their IP address or know any secret keys.
If the attacker sends a contant stream of bogus packets they can
probably prevent the link coming up at all.
This is difficult to fix without changing the protocol.
However, there is worse: when the key setup with the bogus peer
eventually fails, as it must, secnet invalidates the current session
key and its note of where to send actual data packets. It will then
refuse to attempt a new key exchange for a timeout period. During
this period, data packets will not flow.
This means that sending one fairly easy to construct udp packet can
cause a 20s outage. Worse, after this one packet has had its effect,
the attacker can prevent the connection being reestablished, as
described above.
In this patch we fix the latter problem. It is simply a bug that the
session key and data transport peer address (resulting from a previous
successful key exchange) are discarded when a key setup fails.
We also provide a test program "test-example/bogus-setutp-request.c"
which can be used to reproduce the problem.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
(cherry picked from commit
78d458950e6cec7e8fce890362e54e4e9ba5c635)
Conflicts:
.gitignore
possible security fix: do not call slilog with intended message as format string
vMessage would call slilog with part of the intended log message as
the format string. This is a potential format string vulnerability,
detected by -Wformat-security.
I have not analysed the code in detail to determine in exactly which
circumstances a secnet installation will be vulnerable, but in general
a vulnerability (at least for DOS) will exist in any situation where
an attacker can cause a log message to contain things which look like
printf directives.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
(cherry picked from commit
7908f2c6b5be419f8f4031876139953d4ee8340d)
build system: import .gitignore
Copy the .gitignore from the master branch to the stable branch.
(Version is that from
364e35df4fec5bdae53579ffe97297c280be4d88)
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>