The xt_SYSRQ hash now includes the destination IPv4 or IPv6 address
which makes it harder to replay a request to many different machines
in the hope that some of them are using the same password.
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.
