Revert part of 3c8131b976.
The transport header offset is not (yet) set by the time Netfilter
is invoked so using tcp_hdr/udp_hdr has undefined behavior.
Syslog was flooded by lots of messages due to if (plen >= 5) firing
on any packet, when it should have been plen < 5. Incidentally, this
turned up that plen also takes on huge nonsense values, assuming
underflow - yet to be investigated.
I want to be able to use SYSRQ to reboot, crash or partially diagnose
machines that become unresponsive for one reason or another. These
machines, typically, are blades or rack mounted machines that do not
have a PS/2 connection for a keyboard and the old method of wheeling
round a "crash trolley" that has a monitor and a keyboard on it no
longer works: USB keyboards rarely, if ever, work because by the time
the machine is responding only to a ping, udev is incapable of
setting up a new keyboard.
This patch extends the xt_SYSRQ module to avoid both disclosing the
sysrq password and preventing replay. This is done by changing the
request packet from the simple "<key><password>" to a slightly more
complex "<key>,<seqno>,<salt>,<hash>". The hash is the sha1 checksum
of "<key>,<seqno>,<salt>,<password>". A request can be constructed in
a small shell script (see manpage).
Verification of the hash in xt_SYSRQ follows much the same process.
The sequence number, seqno, is initialised to the current time (in
seconds) when the xt_SYSRQ module is loaded and is updated each time
a valid request is received. A request with a sequence number less
than the current sequence number or a wrong hash is silently ignored.
(Using the time for the sequence number assumes (requires) that time
doesn't go backwards on a reboot and that the requester and victim
have reasonably synchronized clocks.)
The random salt is there to prevent pre-computed dictionary attacks
difficult: dictionary attacks are still feasible if you capture a
packet because the hash is computed quickly -- taking perhaps several
milliseconds to compute a more complex hash in xt_SYSRQ when the
machine is unresponsive is probably not the best thing you could do.
However, cracking, say, a random 32 character password would take
some time and is probably beyond what the people in the target
untrustworthy environment are prepared to do or have the resources
for. It almost goes without saying that no two victim machines should
use the same password.
Finally, the module allocates all the resources it need at module
initialisation time on the assumption that if things are going badly
resource allocation is going to be troublesome.
