Re: Emergency shutdown feature

Gordon Oliver (
Sun, 21 Dec 1997 10:55:21 -0300

... linux kernel account said ...
>A host and a userspace rebooter on another box share a 20 byte (160bit)

right. This is sensible.

>When a client wants to reboot a host it takes the unix time and drops the
>least signifiant 8bits and makes that byte=FF. Then it takes the first
>8chars of the hostname (padding with nulls if shorted). Then it adds on
>the 160bit secret. It then performs the SHA transform on the 32byte input
>and produces a 160bit magic value)

two comments:
1) use HMAC-SHA. which consists of SHA(Key, SHA(Key, data)).
this is _much_ less sensitive to weaknesses in SHA.
2) allowing a single packet to reboot the machine is a tad
hazardous. Yes, it is extremely unlikely that they can
guess the packet, but there is virtually no cost to spew
magical ping packets to see if you'll crash. It is much more
robust to use a challenge response.

e.g. Have the rebooter send a "magic" ping packet (or other protocol...)
asking for a challenge. The host to be rebooted then sends a rate limited
challenge packet (you can just have one packet, and send it every time a
request is made). The rebooter then has to sign this value, and then send
the value back to the host... For safety the rebooter should also add his
own random number to the packet - this partially prevents chosen-plaintext
type attacks.

So. Rebooter Host to Reboot
P(Rx) ->
<- P(Ry)
P(HMAC-SHA(Rx, Ry) ->

With this, in order to fake the packet they must
a) Use a legit address, and either be at that address, or on the routing
path to the address.
b) actually make the SHA calculation.

... you could also easily limit the set of hosts which can legally send the
Reboot packets. A cracker could impersonate the machine, but they'd have to
know which machine it was, and then would have to be in the route to that

>Providing no weakness in SHA the easiest cracking would involve sending
>2^160 ping packets. Assuming that the protocall used ping packets of a
>minimum size (20byte tcp 8 bytes icmp and 20 bytes payload) it would
>require sending 70152078591883340073776871970381584943484762062848 bytes
>of data for a brute force attempt. This is also assuming the compute
>clocks were exactly synced and that it took no time to produce the hashes
>and check them and such.

Problems with this:
- the cracker doesn't compute hashes... he just sends a 160 bit
- You must allow a window for the lack of synchronization between
the rebooter and the host to be rebooted. So you'll probably allow
a single packet to have a validity of about 8 minutes.
- A single valid packet can be replayed until it is no longer valid.
so your poor host will be rebooting until the packet expires... So
if you validly reboot the machine, anyone listening can reboot the
machine for a few minutes...


Gordon Oliver	(	Independent Consultant
	... Available for consulting on Linux  ...