authbind: get endianness right (again)
It appears that:
* authbind's documentation authbind-helper(8) describes the
endianness convention of authbind's helper program incorrectly.
See Debian #651694.
* The version of secnet 0.1.16 tagged as such in revision control
contains a "fix" which was based on the authbind documentation but
not apparently tested against authbind. Ie, this part from NEWS:
4) Change the endianess of the arguments to authbind-helper.
sprintf("%04X") already translates from machine repesentation to most
significant octet first so htons reversed it again.
* The version of secnet 0.1.16 actually in service on chiark had an
out-of-version-control change to udp.c to make it work with
chiark's authbind 1.2.0. The actual code found has been recorded
on the dead branch "chiark-0.1.16" in the master git repo, but the
version of udp.c is exactly that from 0.1.15 so it looks like we
just reverted to the previous udp.c during deployment of 0.1.16.
* We (re)discovered all this after the release of secnet 0.2.0
because my attempt to deploy 0.2.0 on chiark was not actually
effective.
Therefore, undo the authbind endianness change introduced in secnet
0.1.16. This is most easily achieved by constructing the arguments to
the helper from the sockaddr rather than the contents of "st".
Thanks are due to Simon Tatham for the bug report.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
(cherry picked from commit
51b259535294bb46757a040596ab052e53f29483)
build system: Include signing of tarballs in release checklist
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
(cherry picked from commit
b57cc2eba7de61952a8633637f8f2fd91486ec71)
Set group ID and group list.
More sensible username lookup.
Signed-off-by: Richard Kettlewell <rjk@terraraq.org.uk>
md5: correct size arg to memset().
On realistic targets the effect of the error was that the MD5 context
wasn't fully cleared.
Signed-off-by: Richard Kettlewell <rjk@terraraq.org.uk>
(cherry picked from commit
dfa6ab137e7565bd1afc03b045fff4aa737a7c9e)
cleanup: build on Ubuntu Lucid
The discard() idiom is chosen because Clang tolerates it.
Signed-off-by: Richard Kettlewell <rjk@terraraq.org.uk>
(cherry picked from commit
5a8a70536e4fa79612405a88c50743976abb2d50)
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>