Patrick McHardy wrote:
John Haxby wrote:
Rationale:
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.g/majordomo-info.html
This module is starting to look kind of useful. Maybe its time for
a resubmission for review and possibly merging once these patches
are included.
That's nice to hear!
If we were to merge it, it would also be good to get some feedback
from the crypto guys about whether the chosen authentication scheme
meets its claims.
I agree. I've talked this through with some people, but it needs some
proper thought. The weaknesses that I've identified are these:
* The password can be recovered with an off-line dictionary attack.
This is mitigated by using a good salt: in my example in the man page I
use a 96 bit salt (dd bs=12 count=1 if=/dev/urandom) which makes a
pre-computed dictionary attack difficult without large resources.
However, a normal exhaustive search using the common password cracking
techniques will yield a poorly chosen password fairly quickly.
* The sha-1 hash is thought to be weak under some circumstances which
makes its use for new cryptographic applications inappropriate. The
weaknesses, however, seem to be that SHA-1 is not good for digital
signatures, but it would seem good enough for this purpose. On the
other hand, making the hash algorithm a module parameter so that it can
be swapped out should SHA-1 prove unsuitable is straightforward (and I
should probably do that).
* If two machines have the same password then the mechanism is subject
to a simple replay attack. An attacker simply needs to capture the
packet and send it to each of the possible target machines and see which
ones crash :-)
* A replay attack is possible on a single machine if the clock goes
backwards (for example, on a reboot if the hardware clock is not UTC and
the system time is not correctly set on boot).
* xt_SYSRQ spamming could cause a DoS attack: simply spewing an endless
stream of requests could tie up enough CPU resources to cause trouble.
All these attacks can be mitigated by good practices: using good, random
passwords; changing the password(s) after an usage episode; changing the
password(s) frequently anyway and so on. Of course, stopping access to
port 9 (or whatever) at a boundary and limiting the frequency of
xt_SYSRQ requests almost goes without saying.
jch
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
